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?

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

or

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

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

Luiz

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

It does.
See below.

The bug is not about converting to RGB. See the attached example in bugreport.

  SetCol := colGray;
  Img.Colors[0,0] := SetCol;
  GetCol := Img.Colors[0,0];
  SetCol  GetCol

Luiz

That's exactly what my long response explained.
Why do you expect that the 48bit color constants can be assigned to 24bit images without loss? Is this somewhere wrongly documented?

Mattias

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.

The point is that the TFPColor constants are inconsistently defined.

Luiz

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

The point is that the TFPColor constants are inconsistently defined.

$8000 is exactly the middle. It is the right value for gray.

Your comparison is wrong. It is as wrong as:

ASingle := ADouble;
if ASingleADouble then ...

Mattias

Luiz Americo Pereira Camara wrote

The point is that the TFPColor constants are inconsistently defined.

I see your point and agree. Some colors have both high and low byte set, some other colors do not.

@Mattias
What is the 48bit value for Maroon (#800000)? R = $8000 or R = $8080 and assuming all the other values are $0000

As defined by fpImage unit.

  colMaroon     : TFPColor = (Red: $8000; Green: $0000; Blue: $0000; Alpha:
alphaOpaque);

This is *incorrect*. It should be:

  colMaroon     : TFPColor = (Red: $8080; Green: $0000; Blue: $0000; Alpha:
alphaOpaque);

128/255 = 32896/65536 = red channel $80 (in RGB 24-bit) or $8080 (in 48-bit) color.

I think this is the point Luiz is trying to make.

Regards,
- Graeme -

Within 256-bit precision, you cannot say which one is correct.

You MUST provide a 48 bit definition of Maroon, only then you can decide which one is correct.

This is what Mattias is trying to say. Normal 256-bit colors correspond to a single type. 48-bit colors correspond to double type.

You cannot say anything sensible about double values if your initial definition is based on a single value.

This is not so.

Both definitions are - within the 256-bit color plane - 100% equivalent. Even the following would be maroon in the 256-bit color plane.

   colMaroon     : TFPColor = (Red: $80FF; Green: $0000; Blue: $0000; Alpha: alphaOpaque);

Compare:
1.2 and 1.0 are, when considered with 0 decimal precision, the same value.

Michael.

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

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

I'm no color expert (maybe that shows), but I based the calculation on ratio information only. Maroon has a red channel value in 24-bit color set to $80. That's 128/256 giving you a 0.5 ratio. Using that ratio and the max value per 48-bit color channel (65536) I calculated the same 48-bit red channel color. 65536 * 0.5 = 32768 = in hex $8080.

128/255 = 32896/65536 = red channel $80 (in RGB 24-bit) or $8080 (in 48-bit) color.

So using the same ratio for both 24-bit and 48-bit color, colMaroon is incorrectly defined in fpImage.

Now lets apply the same ratio math to colDkGray.

  colDkGray     : TFPColor = (Red: $4000; Green: $4000; Blue: $4000; Alpha:
alphaOpaque);

I know the RGB (24-bit color) of DarkGray is $40 for the Red channel. So lets calculate the ratio or the Red channel and upscale it to 48-bit color.

$40 hex = 64 decimal.
64/256 = 0.25 ratio
0.25 * 65536 max color per 48-bit channel = 16384 decimal 16384 dec = $4000 hex.

So based on the definition of colDkGray, the ratio of the red channel is equivalent to the known 24-bit color ratio. So colDrGray is correctly defined in fpImage, but colMaroon is not.

I worked with values I know. I only know the hex values of Maroon and DarkGray in 24-bit color. I tried to use Google to find the exact hex values in 48-bit color, but couldn't find any clear information. Hence the reason I upscaled the 24-bit color channel ratios to 48-bit. So having the same color channel ratios in both 24-bit and 48-bit should equate to the same color.

Even the following would be maroon in the 256-bit color plane. colMaroon : TFPColor = (Red: $80FF; Green: $0000; Blue: $0000; Alpha: alphaOpaque);

Yes, but I'm not limiting my calculation based 24-bit color only. I'm working with the ratio of red in 24-bit color and applying that same ration to 48-bit color. That should mean the two colors are the same. Now using such a ratio with the known 24-bit colors does not equate in all cases to the 48-bit color definitions in fpImage. They are close, but not equal.

Regards,
- Graeme -

Exactly! :) Using the same ratio of each color channel defined in a known 24-bit range and upscaling it to 48-bit (keeping the same ratio), not all definitions in fpImage are correct. They are close, but not 100% correct.

Regards,
- Graeme -

But this ratio is not *the* definition of maroon.

You happen choose to use the ratio as the basis of your definition. Someone else may decide on some other definition. Who is right ?

Like I said, you must have a 48-bit definition of Maroon. Only then you can correctly define maroon in TFPColor.

I was once asked to define a metric for colors.
There are many metrics available, more than I imagined.

Michael.

The ratio is just one of many possible color metrics.

Michael.

Graeme Geldenhuys wrote

value per 48-bit color channel (65536) I calculated the same 48-bit red channel color. 65536 * 0.5 = 32768 = in hex $8080.

Sorry, I'm talking bull here! :-/ No idea how I got to $8080. 32768 is $8000 in hex.

128/255 = 32896/65536 = red channel $80 (in RGB 24-bit) or $8080 (in 48-bit) color.

I see my problem! I used 255 as the max value per channel (24-bit color), when it should have been 256. :-(

Regards,
- Graeme -

Michael, didn't you write fpImage (as far as I know)? So what color metric did you use? :-)

NOTE:
SubVersion history only goes back to 2005 when it was imported from CVS, so I do not have a full history of fpimage.pp unit and can't tell who the original author was.

Regards,
- Graeme -

Luk Vandelaer, my collega and friend, implemented it under my supervision. My responses are based on my discussions with him.

fpImage by itself does not use presuppose any metric. There are various conversion mechanisms implemented, that is all.

Michael.

Zitat von Luiz Americo Pereira Camara :

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

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

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

Mattias

Hello Graeme,

Wednesday, February 17, 2010, 1:27:30 PM, you wrote:

GG> Yes, but I'm not limiting my calculation based 24-bit color only. I'm GG> working with the ratio of red in 24-bit color and applying that same ration GG> to 48-bit color. That should mean the two colors are the same. Now using GG> such a ratio with the known 24-bit colors does not equate in all cases to GG> the 48-bit color definitions in fpImage. They are close, but not equal.

Instead using the known equivalences, reduce the conversion to an absurd situation. You are using 24 bits as your base, but thats an arbitrary base, so change it to 1 bit base and you get that half of color wheel is white and the other half is black.

To base change colors you must change from high resolution to lower resolution, not the inverse, you should not define colors in 48 bits based in their values of 24 bits, but the inverse.

Some values in any base are clear to be calculated, like black, white and all gray tones (in any color primitive) as in example gray is white/2 which is in 48 bits $8080 and $80 in 24.

A different case is maroon, if you define maroon as a 50% red you get a 48 bits $8080, but maroon has not such definition as it is a subjetive perception so both $8080 and $8000 are completly valid and both renders to the same value in 24 bits.

If you transcode up from 24 to 48 bits the right values is $8080 but you are doing a bad transcode for color definition, because you are upscaling a values instead downscaling it.

That's why things like Pantone exists as they provide a clear definition of each color.

In example, pantone define a (one of them) 24 bit maroon as $844A5A in 24 bits space, to me it is a bit of pink, but for Pantone it is maroon.

JoshyFun wrote

To base change colors you must change from high resolution to lower resolution, not the inverse, you should not define colors in 48 bits based in their values of 24 bits, but the inverse.

Yes, that is always ideal, but I can only work with what I know and what I can find on the internet. If you have a link on the internet that defines color values in 48bit, then please do post it here. I have search for the last 30 minutes and haven't found a single link.

All colors I could find are defined as 24-bit RGB values (certified values and color names created by companies like Microsoft, HP, Adobe, W3C, Exif etc.), so that is what I based my calculations on. Using ratios to do the upscaling calculation seems to be the most common conversion method too - as per the links I found on the internet (wikipedia and many websites like Adobe or other photographic websites).

But yes I understand the most accurate would be to only downscale - but I can't find color name definitions in 48-bit color.

That's why things like Pantone exists as they provide a clear definition of each color.

I'll read some more on Pantone - I don't really know much about it. :)

Regards,
- Graeme -

Hello Graeme,

Wednesday, February 17, 2010, 2:57:07 PM, you wrote:

GG> Yes, that is always ideal, but I can only work with what I know and what I GG> can find on the internet. If you have a link on the internet that defines GG> color values in 48bit, then please do post it here. I have search for the GG> last 30 minutes and haven't found a single link.

You will not find nothing quite sure as 24 bits is quite closer to our color perception capability.

GG> All colors I could find are defined as 24-bit RGB values (certified values GG> and color names created by companies like Microsoft, HP, Adobe, W3C, Exif GG> etc.), so that is what I based my calculations on. Using ratios to do the GG> upscaling calculation seems to be the most common conversion method too - GG> as per the links I found on the internet (wikipedia and many websites like GG> Adobe or other photographic websites).

The problem is that for each 24 bit colors there are 16.1 million equivalent colors in 48 bits so any test like:

Pixel[x,y]=clMaroon;
if Pixel[x,y]=clMaroon then blah, blah...

will only be true 1/16000000 times, so that compare is not logical due different bases.

Any other discussion about the low byte of 48 bit colors is useless because:

$8001 is in 24 bits the same as $80FF in 24 bits, and there is not proper upscaling, as clMaroon is not $8080 nor $8000, nor $80FF. It is a 48 bits value defined by somebody using any upscaling or downscaling technique.

Colorimetric is a "dangerous" field for programmers. We are used to think in RGB values, but once you work a bit with temperature or different codifications like YUV, YUY, CMYK or any other you end knowing that 2+2=2.12321+-2*pi when the wind blows from the north :)

GG> But yes I understand the most accurate would be to only downscale - but I GG> can't find color name definitions in 48-bit color.

As 24 bit versions of clXXXX colors are compatible with Delphi any 48 bit definition is valid from my point of view.