Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


On Mon, Dec 05, 2011 at 05:26:00PM +0530, Muthu Subramanian K wrote:

During the code digging for one of the bugs, I came across GetXPixel()
function in vcl. Which seems to be implemented wrong - not sure why it
is multiplied by 257 - the idea, I believe, is to convert 8bit to 16bit
values for X11, but I may be wrong.

I think that is the idea, too. But your patch means we will never
output pure white. Let me explain.

Each component in 8 bit is from 0 to 255 (0xFF). In 16 bits, from 0 to
65535 (0xFFFF). When converting, we want to map 00 to 0, and the
maximum value to the maximum value. But your patch maps 255 to 65280
(0xFF00). So it maps pure white (RGB8 0xFF 0xFF 0xFF) to light grey
(RGB16 0xFF00 0xFF00 0xFF00).

OTOH, 255*257 is exactly 65535 :)

Multiplying by 257 maps:

 0x00 to 0x0000
 0x01 to 0x0101
 0x02 to 0x0202
 ..
 0xB3 to 0xB3B3
 ..
 0xFF to 0xFFF

Giving a nice constant 16-bit difference between two consecutive 8-bit
values.

Maybe that code would be more clear if instead of "*257", it did
something like "r<<8  + r" or "r<<8 | r"?

Thanks for raising the question, tough.

-- 
Lionel

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.