# [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)

Luiz Americo Pereira Camara luizmed at oi.com.br
Wed Feb 17 12:13:25 CET 2010

```Mattias Gaertner escreveu:
> On Wed, 17 Feb 2010 06:52:25 -0300
> Luiz Americo Pereira Camara <luizmed at oi.com.br> wrote:
>
>>
>> fpimage is not documented at all AFAIK.
>>
>> It's not loosing bits if your information, in previous mail, about
>> TFPColor format is correct.
>>
>> Defining colGray, and related, as TFPColor = (Red: \$8080; Green: \$8080;
>> Blue: \$8080; Alpha: alphaOpaque) would make it work.
>>
>
> ... would make it work with a 24bit color image that uses one pixel
> color conversion *\$101, div \$100.
> It won't work on a 24bit color image that uses color conversion *\$100,
> div \$100 or on any other format.
>

Are you saying that TFPColor is just a container for any 48bit format
and has not a defined format?

>
>
>> The point is that the TFPColor constants are inconsistently defined.
>>
>
> \$8000 is exactly the middle. It is the right value for gray.

OK.

If i understand correctly, you are saying that in TFPColor format  \$0000
means black (no color in the channel) \$FFFF means white (full color in
the channel) and between them you get the remaining intensity.

Assuming that, giving a color in 24bit RGB (one byte per channel) where
\$00 means no color \$FF full color, if a channel is on the middle (\$80 =
128) it would be equivalent to \$8000 in the 48bit format, right?
LazIntfImage is returning \$8080.

If channel is \$40 (=64) in 24bit, it should not map to \$4000 in 48bit?
LazIntfImage is returning \$4040
If channel is \$2 (=2) in 24bit, it should not map to \$0200 in 48bit?
LazIntfImage is returning \$2020
If channel is \$1 (=1) in 24bit, it should not map to \$0100 in 48bit?
LazIntfImage is returning \$1010

AFAIK, it should not be difficult to fix that (assuming is broken).

All in all, this is not an issue for me and i won't take any longer if
other agree that there's nothing broken.

Luiz

```