Extracting grayscale value from MAX image

[kellam]

You should see that the values from the camera are zero padded on the least significant bits, not the most significant.  This is equivalent to having the pixel value from the camera multiplied by 16.

This was done because the PNG spec provides for 8 and 16 bit images.  If the most significant bits were padded, then the pixel values would go from 0-4095.  Any image viewer, because it interprets the image as a 16 bit image, maps 0 to black and 65535 to white.  Therefore, if you looked at a left padded 12 bit image in a viewer, it would look almost completely black.  We felt it was important for customers to be able to see their images in standard viewers, so we right padded instead.

The actual bit depth, and information to restore the original values is encoded within the PNG, and the Vision libraries will read this tag and restore the image appropriately.

-Jeff

[nbf]

> This is equivalent to having the pixel value from the camera multiplied by 16.

Thanks. I looked at the pixels in the PNG file produced by MAX (attached) and for some reason it seems to contain values not divisible by 16, e.g.

1010000000001
1010100000001
1100110110001

...

Neil

[kellam]

Hi Neil,

Sorry for the delay in the reply.  I've been out of town.  My guess is that you are having an endianness issue.  PNG stores multibyte data in big endian format, and PCs use little endian.  If you can look at the first four pixels of the image you attached (i.e. row 0, pixels 0-3) here's what you should see.

(A) Correct 12 bit values (in decimal): 32, 29, 35, 33

(B) Values multiplied by 16 if endianness is correct (in decimal): 512, 464, 560, 528

(C) Values multiplied by 16 if endianness is incorrect (in decimal): 2, 53249, 12290, 4098

I'm betting that you are seeing the option C.  Is my assumption correct?

-Jeff

[nbf]

Thanks. I see the pixel values in option B. (I tried this on both Intel-based Mac, and PC.)

Neil

[kellam]

If you are seeing option B, then just dividing every pixel by 16 will get you back to the original pixel values.  I'm still a little concerned, because the bitpatterns you listed in message 12 should not be possible with option B.  If you can give me the x,y coordinates of those pixels, I can see what's going on.

Jeff

[nbf]

Jeff,

   When I hover the cursor over the bright central region of the image, I see many pixels with odd values, e.g.:

row 187, pixel 301: 1101110100111101 (decimal 56637)

row 187, pixel 303: 1101010000101101 (decimal 54317)

(There are many more in that neighborhood.)

Thanks,

Neil

[kellam]

Those values are definitely incorrect.  I'll file a defect report on it.

-Jeff