How can I get the point from psd file - java

I have read the but I still did not understand this paragraph:
All points used in defining a path are stored in eight bytes as a pair
of 32-bit components, vertical component first. The two components are
signed, fixed point numbers with 8 bits before the binary point and 24
bits after the binary point. Three guard bits are reserved in the
points to eliminate most concerns over arithmetic overflow. Hence, the
range for each component is 0xF0000000 to 0x0FFFFFFF representing a
range of -16 to 16. The lower bound is included, but not the upper
bound. This limited range is used because the points are expressed
relative to the image size. The vertical component is given with
respect to the image height, and the horizontal component is given
with respect to the image width. [ 0,0 ] represents the top-left
corner of the image; [ 1,1 ] ([ 0x01000000,0x01000000 ]) represents
the bottom-right. In Windows, the byte order of the path point
components are reversed; you should swap the bytes when accessing each
32-bit value.
I have done a test of that: link
and get the point of that:
x1:7e0e42 y1:0
x2:7e0e42 y2:0
x3:7e0e42 y3:0
x1:1000000 y1:0
x2:1000000 y2:0
x3:1000000 y3:0
the fisrt is at the top left of red rect;
the second is at the top
right of red rect;
the canvas width is 790px
the top left is at 389px
How can I get the number of 389 from 7e0e42?
I just can not understand the meaning of that paragraph.
Thanks a lot

A little late, but:
Your first x value is 0x007e0e42 in the fixed point representation mentioned in the text. That means 0 + 0x7e0e42 / 0xffffff, or 0.49240505695343 (approximately) in floating point.
Remember, the coordinates are given "relative to the image size". If you multiply this with the the image width of 790, you get 388.999994993209839, which should round nicely to 389, which is what you expected.
Mystery solved. :-)

Related

How to create a disparity map?

Okay so I have implemented a stereo correspondence algorithm which takes a stereo image pair, matches a point on the left image with a point on the right image, and finds the disparity between the points. I need to write this to a disparity map.
The disparity maps I have found are grayscale images, with lighter grays meaning less depth and darker grays meaning more depth. How do I translate my set of disparities into a grayscale image like this? My disparities are very small, ie only a distance of two between pixels, how does this translate into a grayscale pixel value?
There must be a standard way of compiling disparity maps but all my searching has yielded nothing thus far.
A simple solution when creating a disparity map the largest distance becomes black ie rgb(0,0,0) and the smallest distance - which is 0 - becomes white ie rgb(255,255,255). If you divide 255 by the largest distance then you find the increment value. Finally just go through all the disparities and set each rgb value to 255 minus the disparity times the increment value. Viola, you have your disparity map.
So in your example it sounds like your largest distance is only 2 pixals (which unfortunately means your map isn't going to have a lot of detail). Anyways 255 / 2 = 127.5. This means that 127.5 is the increment value. So everywhere that the disparity is 0, the rgb value is 255 - (0 * 127.5) or rgb(255,255,255), anywhere the disparity is 1 the rgb value is 255 - (1 * 127.5), we'll round to 128 so rgb(128,128,128) and anywhere the disparity is 2 the rgb value is 255 - (2 * 127.5) or rgb(0,0,0).
Here are some more resources:
How MathWorks does it
Jay Rambhia has a good blog explaining how to program one
Hope that helps!

What happens when converting double (or floats) to ints?

I'm practicing some simple 2D game programming, and came up with a theory that during animation (the actual change in a image position is best calculated with floating point numbers). I have a feeling that if you move an image around with ints the animation won't be as smooth.
In Java it seems you can't draw an image with floating point numbers to give an image a position. But apparently when you initially declare your x and y 's, you can declare them as Double, or Float, and when it comes to actually drawing the image you have to cast them to ints. Like I find HERE :
/**
* Draw this entity to the graphics context provided
*
* #param g The graphics context on which to draw
*/
public void draw(Graphics g) {
sprite.draw(g,(int) x,(int) y);
}
My question is about how Java handles the conversion?
If the code casts these doubles at the last minute, why have them as doubles in the first place?
Does Java hide the numbers after the decimal?
I know in C and C++ the numbers after the decimal get cut off and you only see whats before it. How does Java handle this casting?
Pixels on a display are discrete and limited in number; therefore display coordinates need to be integer numbers - floating point numbers make no sense, as you do not physically have a pixel at e.g. (341.4, 234,7).
That said, integers should only be used at the final drawing stage. When you calculate object movement, speeds etc, you need to use floating point numbers. Integers will cause an amazing number of precision problems. Consider the following snippet:
a = 1;
x = (a / 2) * 2;
If a and x are floating point numbers, x will finally have the expected number of 1. If they are integers, you will get 0.
Baseline: use floating point types for physics computations and convert to int at drawing time. That will allow you to perform the physics calculations with as much precision as required.
EDIT:
As far as the conversion from FP numbers to integers is concerned, while FP numbers have a greater range, the values produced by your physics calculation after normalization to your drawing area size should not normally overflow an int type.
That said, Java truncates the floating point numbers when converting to an integer type, which can create artifacts (e.g. an animation with no pixels at the rightmost pixel column, due to e.g. 639.9 being converted to 639 rather than 640). You might want to have a look at Math.round() or some of the other rounding methods provided by Java for more reasonable results.
Java truncates the decimals. Eg:
(int) 2.34 == 2
(int) 2.90 == 2
The reason for not being able to draw at a floating position is simply that there's no half pixels etc :)
Java casts floats to int by dropping the decimal. But I don't think having x and y coordinates in floats make any sense. You have pixel on the screen which cannot be presented in anything less than one pixel. For example you can't draw a pixel .5px x .5px because on the screen it will just be 1px x 1px pixel. I am not a computer game programmer but I have written one animation engine in Java and it was very smooth. I can share this if you'd like.
Note that you should draw using ints but do all your calculation using doubles. For things like rotating or anything that relies on a mathematical formula should be done in decimal.
The reason x and y need to be doubles is for when they need to be computed mathematically, for example:
x += (delta * dx) / 1000;
You want to avoid overflows and loss of precision up until you paint the pixel.

scaling operations on a 2D graph, size of output sequence must not be the same as input

I am looking for an open source package (preferably Java but R or other languages would be ok too) that provides these 2 functions
1) points output_seq[] SCALE(points input_seq[], double factor)
In other words a sequence of doubles (x1,y1), (x2,y2)... is given as input that represents a graph (each point is connected to the next by a straight line) and a scaling factor is given. Then it returns a similar sequence as output. The catch is that the output sequence may have fewer or more elements than the input. For example, if I request magnification by a factor of 2.012 then the output sequence may have twice as many elements as the input. The scaling factor should be a double, not an integer.
Lastly, it's important to return the output sequence as points (doubles), I have very little interest in the actual drawing on a screen beyond proving that it does the right thing.
2) points output_seq[] ROTATE(points input_seq[], double angle)
same as above, except there is no scaling but just rotation, the angle is from 0 to 359.9999 and is given in radians.
The size of the output is always the same as the size of the input.
Again the emphasis is on getting the output sequence as doubles, not so much on the actual drawing on a screen.
If you know the right terminology I should have used then let me know.
Thank you so much.
In Java, Path2D is suitable for 2D floating point coordinates. The lineTo() method will add straight lines to the path. Because Path2D implements the Shape interface, rotate and scale are possible via createTransformedShape(). One approach to interpolation, using PathIterator, is shown here.

Constructing an IndexColourModel

I was wondering about constructing an IndexColourModel. I don't understand the 'bits' parameter argument. Is this what is used to index into a colour map, i.e. the number of least-significant-bits to use from the pixel to index into the map? The docs simply state
bits - the number of bits each pixel occupies
I'm not satisfied with this and was wondering if someone could elucidate what exactly this parameter is and how it is used. Must this be correlated with the other 'size' parameter?
The bits parameter is the color depth.
From the IndexColourModel javadoc at the top of the class:
The values used to index into the colormap are taken from the least
significant n bits of pixel representations where n is based on the
pixel size specified in the constructor. For pixel sizes smaller than
8 bits, n is rounded up to a power of two (3 becomes 4 and 5,6,7
become 8). For pixel sizes between 8 and 16 bits, n is equal to the
pixel size. Pixel sizes larger than 16 bits are not supported by this
class. Higher order bits beyond n are ignored in pixel
representations. Index values greater than or equal to the map size,
but less than 2n, are undefined and return 0 for all color and alpha
components.

GrayScale (8bit per pixel) Image Pixel Manipulation in Java

I've heard that the data in gray-scale images with 8-bits color depth is stored in the first 7 bits of a byte of each pixel and the last bit keep intact! So we can store some information using the last bit of all pixels, is it true?
If so, how the data could be interpreted in individual pixels? I mean there is no Red, Blue and Green! so what do those bits mean?
And How can I calculate the average value of all pixels of an image?
I prefer to use pure java classes not JAI or other third parties.
Update 1
BufferedImage image = ...; // loading image
image.getRGB(i, j);
getRGB method always return an int which is bigger than one byte!!!
What should I do?
My understanding is that 8-bits colour depth means there is 8-bits per pixel (i.e. one byte) and that Red, Gren and Blue are all this value. e.g. greyscale=192 means Red=192, Green=192, Blue=192. There is no 7 bits plus another 1 bit.
AFAIK, you can just use a normal average. However I would use long for the sum and make sure each byte is unsigned i.e. `b & 0xff
EDIT: If the grey scale is say 128 (or 0x80), I would expect the RGB to be 128,128,128 or 0x808080.

Categories

Resources