Different Quantum levels after writing/reading image

[Qs8Y27ozL6xXk6SYoC2m]

I'm using a pixel cache to modify PixelPacket struct for each pixel in a Bitmap which is synced before writing. The image I'm editing has a color depth of 8 and my version of Magick++ is using a MagicQuantumDepth of 16. I open the image and in the first 10 pixels I modify the RGB color values. It first wasn't working because my modifications were << 1/2^8. I therefore now shift everything right 8 bits, edit the RGB values and then shift back 8 bits. This works however some values aren't saved correctly.

After saving the image the RGB Quantum's of the first 10 pixels are saved like this:

Code: Select all

R         G        B
0x6500  0xB500  0x6C00 
0x6F00  0xBF00  0x6F00
0x7D00  0xCD00  0x7D00
0x8D00  0xDD00  0x8D00
0x9C00  0xD800  0x9000
0x7800  0xBE00  0x7B00
0x6E00  0xA800  0x6400
0x9000  0xC600  0x8A00
0x9A00  0xCC00  0xA300
0x9191  0xBDBD  0x9C9C
0x9090  0xB7B7  0x9A9A
0x9595  0xBCBC  0x9F9F
0x9898  0xBDBD  0x9C9C

Below is the output when reopening the image, you can see the RGB Quantum values first byte is copied to the second however sometimes it differs by 1. e.g.

before after
0x6500 => 0x6565, ok but strange
0xB500 -> 0xB4B4, why when i saved as 0xB500 does it change to 0xB4B4?

Code: Select all

0x6565  0xB4B4  0x6C6C
0x6F6F  0xBEBE  0x6F6F
0x7D7D  0xCCCC  0x7D7D
0x8C8C  0xDCDC  0x8C8C
0x9B9B  0xD7D7  0x8F8F
0x7878  0xBDBD  0x7B7B
0x6E6E  0xA7A7  0x6464
0x8F8F  0xC5C5  0x8989
0x9999  0xCBCB  0xA2A2
0x9191  0xBDBD  0x9C9C
0x9090  0xB7B7  0x9A9A
0x9595  0xBCBC  0x9F9F
0x9898  0xBDBD  0x9C9C

Code is here (expires in 10 days)


I guess my question is, could Image Magick++ be normalizing color values or modifying them in any other way considering this is a BMP file?

[snibgo]

I'm not quite sure what you are asking, but the following might answer it.

When Q16 (or Q32 or Q64) IM reads an 8-bit/channel/pixel image, values are expanded to fit the Q. Ths is NOT done by simply shifting bits, because we want 0->0 and 255->65535. It is done by replicating bytes, so an input 8-bit (hex) 0x56 becomes the 16 bits 0x5656. Going in the opposite direction, reducing the bit depth, bits are not merely dropped. The algorithm is chosen to be reversible, so 0xB4B4->0xB4 and 0xB5B5->0xB5. As 0xB500 is closer to 0xB4B4 than it is to 0xB5B5, it becomes 0xB4.

[Qs8Y27ozL6xXk6SYoC2m]

I'm not quite sure what you are asking, but the following might answer it.

When Q16 (or Q32 or Q64) IM reads an 8-bit/channel/pixel image, values are expanded to fit the Q. Ths is NOT done by simply shifting bits, because we want 0->0 and 255->65535. It is done by replicating bytes, so an input 8-bit (hex) 0x56 becomes the 16 bits 0x5656. Going in the opposite direction, reducing the bit depth, bits are not merely dropped. The algorithm is chosen to be reversible, so 0xB4B4->0xB4 and 0xB5B5->0xB5. As 0xB500 is closer to 0xB4B4 than it is to 0xB5B5, it becomes 0xB4.

Thank you. Where did you find this information?

[snibgo]

I don't know. The back of my memory somewhere. It is probably explained somewhere in IM documentation.

http://www.imagemagick.org/Usage/basics/
http://www.imagemagick.org/Usage/reference.html
http://www.imagemagick.org/script/architecture.php