# Converting between colours

This topic is 3853 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi. I was curious as to the proper way to convert between different colours (e.g from colours that use 0-255 values to colours that use 0.0 - 1.0 values). This is the way I'm doing it at the moment:
private static final double GAMMA = 2.2;

public static Colour Convert(Color color)
{
return new Colour(
(double)color.getRed() / 255.0,
(double)color.getGreen() / 255.0,
(double)color.getBlue() / 255.0,
(double)color.getAlpha() / 255.0);
}

public static Color Convert(Colour colour)
{
double redCorrected = Math.pow(colour.r, 1/GAMMA);
double greenCorrected = Math.pow(colour.g, 1/GAMMA);
double blueCorrected = Math.pow(colour.b, 1/GAMMA);
double alphaCorrected = Math.pow(colour.a, 1/GAMMA);

return new Color
(
(int)Math.round(255*redCorrected),
(int)Math.round(255*greenCorrected),
(int)Math.round(255*blueCorrected),
(int)Math.round(255*alphaCorrected)
);
}

Is this correct? Cheers.

##### Share on other sites
without scrutinizing much it looks about right to me...... u want to range your colour from 0 to 1, then yes you divide the byte value by 255 to return a float in the range 0 to 1. win

the gamma bit seems to follow how i remember it being in Quake, where 0.5 gamma was brighter than a gamma of 1.

but now the question is how do you intend to represent colours that are greater than 1 (greater than 255 by the end)? will they get clamped back to 1 (255) and therefore cause the colours to blend into a whitewash?

##### Share on other sites
Quote:
 Original post by nbbut now the question is how do you intend to represent colours that are greater than 1 (greater than 255 by the end)? will they get clamped back to 1 (255) and therefore cause the colours to blend into a whitewash?
I hadn't planned on doing that to be honest. This code will never be used again 5 hours from now and until then I'll be the only one using it. ;)

Cheers.

##### Share on other sites
just look into opensource code which is already doing it - e.g. QT's QColor-class

##### Share on other sites
Quote:
 Original post by hydroojust look into opensource code which is already doing it - e.g. QT's QColor-class
I searched the documentation for it but couldn't see anything that explains it.

##### Share on other sites
The conversion looks correct, but why do you pow it with 1/gamma when converting to floating point space? That's not how I believe gamma correction is supposed to be used. Real gamma correction is applied to normalize the color space of a texture to linear before entering the pipeline, then at the end of the pipeline done again to correct it back to make up for problems in the monitor color space. Just because you switch between floating point and uchar representation you shouldn't divide by gamma, that has nothing to do with conversion; it's a separate process. As far as I know, at least...

Btw about conversion and losing precision, a better idea may be to have one class for uchar colors and one for floating point colors. Converting to uchar color should be expected to be a lossy operation and converting back will never restore too high values. Converting down then, I think, requires a clamping operation before casting in order to work. Otherwise it would be similar to the code above.

1. 1
2. 2
3. 3
Rutin
14
4. 4
5. 5

• 9
• 9
• 11
• 11
• 23
• ### Forum Statistics

• Total Topics
633674
• Total Posts
3013277
×