[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
More information about the fpc-devel
mailing list