bytes vs floats for color components

[TheNess]

Hi all, new SFML member here!

First let me say SFML is pretty sweet!
I worked in the past with glut, OpenGL, DirectX, tiny bit of XNA, SDL, Ogre3d, Irrlicht and ms gdi; and by far SFML has been the most intuitive, fun and friction-less to integrate with!

With that said, there is something that always puzzled me about rendering libs that also apply to SFML: why or why do you always use bytes instead of floats to represent colors??
Note that this is not a feature request nor a rant, its a genuine question I want to understand

I'll explain better:
Bytes are obviously the most memory-efficient way to represent colors, and thus efficient when copied around (like moving an int). but that efficiency is cancelled out by the need to convert from byte to float before setting the vertices, so the only real advantage of bytes is memory (as far as I see).
RAM is a very cheap asset nowadays and I think float have many advantages over byte that justify the extra memory consumption:

1. floats are much better for math operations, and without the fear of wraparound happening. for example, lets say I want to make a color 20% brighter. think for a moment how you would implement that with bytes? OK now here's how it goes with floats: "color * Color(1.2f, 1.2f, 1.2f, 1.0f)". and if color above 1.0f is a problem you can easily clip it right before using it.

2. speaking of clipping, using floats has another great advantage - you can pass the shaders values outside the range of 0.0f - 1.0f to create special effects. for example why not setting the color of a sprite to (2.0f, 1.0f, 1.0f, 1.0f) to actually empathize the red component of the texture, even beyond the texture original color?

3. this might be personal opinion, but I find floats far more intuitive then bytes for a color.

So what I'm basically asking is this: what are the main advantages of using bytes instead of floats? why did you chose bytes for SFML? is this just an industry standard? what is your personal take on the subject?

PS I found this old post:
http://en.sfml-dev.org/forums/index.php?topic=9056.0
So I'm not the only one

thanks!

[Laurent]

I'd say there's no strong reason. Either way works equally well, with, as you mentioned, some advantages for float components, and probably also for byte components. In the end it's just a choice.

[therocode]

I implemented a colour class similar to the sfml one in one of my projects and I had the same considerations. I almost decided to go with floats, but I decided against it for these reasons:

When dealing with colours in other contexts aside from rendering, they are commonly represented using bytes. I.e. colour pickers in applications, data in image files, etc. This means that when interacting with other libraries for example when loading/saving images, they are going to be in bytes. This means that your code might integrate more easily when using bytes.

For example, if the bytes are stored like so:

struct Color
{
   uint8_t r, g, b, a;
}

And an image loading function spits out a char* of bytes of RGBA data, you can simply do:

Color* color = (Color*) theImage;

And you can access the pixels directly due to binary compatibility.

Also by using bytes, there is no ambiguity. You know that if you have 223 red, you can directly compare it with the pixel of an external function. But if you store stuff in floats, maybe it would depend on arbitrary float maths if the values are exact or not. I am not sure how valid that case is, but for me it felt like a reason.

Finally, the conversions to float isn't a bottleneck in terms of performance in the very most of all cases.


Note: I don't know how much this applies to SFML's choice of using bytes, but that's my reasoning for a similar case.

[TheNess]

thanks for the answers.

therocode you bring some good points. I still think the advantages of floats are superior but that's just a matter of opinion I guess. anyway you did answer my question - these were the reasons I was looking for. if there are more I'd love to hear

[Hapax]

As good a time as any to say, "welcome!"

[Jesper Juhl]

Welcome.
My take; sure, there may be minor advantages/disadvantages to either choice. But conversions are cheap and trivial and the code to do so is the same. I suspect (I have not tested and measured) that once the code has been through a modern optimizing compiler any difference will be "in the noise" and never actually show up in any significant hot path and thus is fairly irrelevant.

[TheNess]

thanks 

about the byte-to-float conversion I mentioned it as a counter to the fast-copy claim, but both of them are kind of silly points anyway.   

[jill]

If you don't need it, byte is enough, then int, then float, then double. For computer colors, floating point value isn't needed.