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

JoshyFun joshyfun at gmail.com
Wed Feb 17 14:25:35 CET 2010

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

--
Best regards,
JoshyFun

```