So, if an image is loaded by explicitely specifying a file_gamma
for it of 1.0, a pixel value 128 would end up as color value 0.5?
Could be helpful for the non-obvious data containers ;)

>     color rgbt <0.5,0.5,0.5, 0.2> gamma 2.2

Or possibly

   color rgbtg <0.5,0.5,0.5,0.2,2.2>

Too bad green and gamma start with the same letter ;)

> Then again, maybe the best way to go would be to introduce a new syntax 
> for vectors/colors to be subject to some default gamma correction, as in:
> 
> default_settings {
>   color_gamma 2.2
> }

Or possibly #default color {gamma 2.2}, although that implies
that color supports a fully blown "block" syntax similar to

color
{
   rgb      <0.5,0.5,0.5>
   gamma    2.2
   transmit 0.5
}

However, when considering to add more color models
that might even make sense.

> #declare MyPigment = pigment { color rgbt #<0.5,0.5,0.5,0.2> }

Or possibly

   color rgbt! <0.5,0.5,0.5,0.2>

It looks slightly less cryptic to me and might better
work with data which is not literal but from some vector
variable or function.

> Maybe we can even go so far as to allow HTML colors in SDL code? Those 
> would automatically be subject to gamma correction.

I could live without HTML colors. New syntax for the
same thing but with with extra limitations in range?

> If we'd go for such a syntax, it might also be prudent to merge the 
> "file_gamma" and "color_gamma" into a single "gamma" statement.

Then "input_gamma" would probably be more distinct to avoid
confusion with display gamma.

Post a reply to this message