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

[Mattias Gaertner]

On Tue, 16 Feb 2010 17:15:37 -0300
Luiz Americo Pereira Camara <luizmed at oi.com.br> wrote:

> While trying to get the RGB values (bytes) of a TFPColor i got confused 
> about the format of TFPColor
> 
> Some hardcoded colors (unit FPImage) like colGray, colTea sets the high 
> byte value of Red, Green, Blue fields with the corresponding byte value 
> of RGB and leaves the low byte with 0.
> 
> Other colors like colWhite or colFuchsia sets both low and high byte of 
> the fields with the corresponding  RGB values.
> 
> So whats the correlation of RGB byte values and TFPColor?

RGB, TColor uses range of 0-$ff and TFPColor uses Word so range is
0-$ffff, so you can multiple each by $101. Another way is to copy the
byte (c shl 8+c).
Note: The reverse is *not* to divide by $101. (e.g. $fffe div $101 =
$fe, but it should be mapped to $ff). The reverse is to divide by $100
(or "shr 8").
And note that this is a "per pixel" conversion, which might not be the
best way.

 
> Should colWhite be redefined as colWhite      : TFPColor = (Red: $ff00; 
> Green: $ff00; Blue: $ff00; Alpha: alphaOpaque)

No. That's not fully white. 
$ff*$101 = $ffff


> or
> 
> colGray be redefined as colGray       : TFPColor = (Red: $8080; Green: 
> $8080; Blue: $8080; Alpha: alphaOpaque) ??

Yes, although this rarely makes a difference.

 
> This info will help to fix http://bugs.freepascal.org/view.php?id=15793

IMO the bug report is misleading. Converting a TFPColor to RGB looses
bits. You should not assume that the 48bit FPColor constants
support 24 bit RGB. The FPColor constants don't support other RGB
formats like 5-6-5 neither and there are many different algorithms to
scale picture resolutions. 


Mattias