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

[Mattias Gärtner]

Zitat von Luiz Americo Pereira Camara <luizmed at oi.com.br>:

> 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?

It is defined as a RGBA format. AFAIK there is no definition how  
TFPCustomImage.Get/SetColor map this to 24bit RGB.


>>> 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.

The LCL uses the $101 to get full 16bit white/black, and full  
alpha/opaque, so you can use Colors[x,y]=colWhite and  
Colors[x,y].Alpha=alphaOpaque. This makes porting many algorithms  
easier.

About gray:
gray is the middle between black and white. But the middle between  
black (0) and white (255) is 127.5 which does not fit into 8bit. So a  
gray of $80 is somewhat to bright. The LCL converts $80 to $8080 which  
is also somewhat above the real gray in 16 bit: $7fff.8 (32767.5).


> 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.

IMO nothing is broken, just gray is a rounded value and converting a  
rounded value between various precisions creates rounding errors.

Mattias