search

sphere-group / pegasus

The Pegasus API for Sphere 2.0
BSD 2-Clause "Simplified" License
1 stars 0 forks source link

Inconsistency in Color specification #19

Closed fatcerberus closed 8 years ago

fatcerberus commented 9 years ago

The current Color spec calls for RGB to be [0-255] while alpha is floating point [0.0-1.0]. This seems schizophrenic--shouldn't we pick one way or the other and have all components, alpha included, use the same range?

joskuijpers commented 9 years ago

An alpha of 0 to 1 is awful, really, in my opinion. So then all should values should be ranged 0 to 1.0. That is what I would opt for.

On Apr 24, 2015, at 11:49 PM, Bruce Pascoe notifications@github.com wrote:

The current Color spec calls for RGB to be [0-255] while alpha is floating point [0.0-1.0]. This seems schizophrenic--shouldn't we pick one way or the other and have all components, alpha included, use the same range?

— Reply to this email directly or view it on GitHub.

fatcerberus commented 9 years ago

Wait, I'm confused. You say 0-1 alpha is awful, but then opt for that over the alternative 8-bit range...

FlyingJester commented 9 years ago

I believe that the color components should be from 0-255. Even alpha.

fatcerberus commented 9 years ago

@FlyingJester: That's what I was thinking myself; we can't go to float colors and still keep the Color name without breaking backward compatibility with Sphere 1.x. We can always make a new (optional) object type for float colors if the need arises (HDR, say).

joskuijpers commented 9 years ago

I am confused too. I actually meant thst i find using 0-255 as alpha range awful :p. Oh well.

Somehow I feel like mixing floating colors is more precise than mixing bytecolors...

On Apr 24, 2015, at 11:58 PM, Bruce Pascoe notifications@github.com wrote:

@FlyingJester: That's what I was thinking myself; we can't go to float colors and still keep the Color name without breaking backward compatibility with Sphere 1.x. We can always make a new (optional) object type for float colors if the need arises (HDR, say).

— Reply to this email directly or view it on GitHub.

fatcerberus commented 9 years ago

Technically FP colors are more portable. 0-255 is an implementation detail from the fact that 32-bit images represent the components as bytes, and kept around because for a long time 2D rendering was done in software and integer math is a lot cheaper to do in a tight loop (blitting) than float math. Unfortunately we've been doing it so long that now it's what I think most people expect an RGBA color to be; anything else appears odd. Look up the "coconut effect" sometime.

So yeah, I think it might for the best to keep the component range as 0-255 for the default Color object to avoid any confusion.

FlyingJester commented 9 years ago

FP is technically more portable, in theory. You would then always have to do more conversions than simple byte-wise integer colors. In practice, 32/24 bit color is totally portable. You could also just think of 0-255 as literal representation of fixed-point numbers :)

fatcerberus commented 9 years ago

On the other hand, pixel shaders do tend to use FP natively. So no conversion in that case. But yes, bytewise colors can be thought of as a form of fixed-point--in fact, I vaguely remember integer-based alpha blending being described as a form of fixed-point math way back when I was first learning about it. I have a lot more background writing software renderers than I let on. :smile: