Le_Forgeron schrieb:
> If you want pre-gamma correct value, maybe its time for a
> "srgb"/srgbf/...  additional color code, specifying color in the silly
> sRGB space (and then parser will gamma correct it to linear space on the
> fly)

That's indeed an intriguing idea.

Would we also have sred, sgreen, sblue then for consistency?

One drawback, however, would be that the gamma should then be fixed to a 
gamma of 2.2 for consistency (or actually even more complex processing 
should be performed).


Another alternative might be to support "gamma X" as a prefix for any 
color statement, as in:

     ... color gamma 2.2 rgb <0.3,0.4,0.2> ...
     ... color gamma 1.8 red 0.3 green 0.7 ...


 > BTW, would you gamma-correct F or T ??? why ?

Of course not. Why should anyone?

Post a reply to this message

Warp schrieb:
>   The quotes allow putting there more than just a hex value prepended
> with a #. You can put color names and everything else HTML supports,
> plus more.

Rather not. I'd pretty much consider that overkill. Unless you want to 
extend POV-Ray's capabilities to rendering HTML documents of course...

>> A hash sign (#) followed by six uppercase(!) hex digits could denote a 
>> HTML color.
> 
>   "HTML color" can be more than just hex values. By making it a non-string
> you are removing the possibility of other color definitions being used
> (such as named colors).

... which is what I'd prefer to do, actually: Straightforward 24-bit 
colors should suffice. So rather than specifying a generic way how to 
specify HTML colors, I'd rather specify that "a hash sign followed by 
six uppercase hex digits is interpreted as a HTML color".

If you want color names, go ahead and define them as genuine POV-Ray 
variables in some .ini file.

> having a # followed by something exceptional is only going to cause severe
> problems, besides being awkard, rigid and limited.

I don't see any severe problems, nor do I consider it awkward, and the 
rigidity and limitations is something I see as a benefit, because it 
will stop users from complaining that some particular HTML color syntax 
they happen to have tried hasn't been implemented yet. Or someone 
complaining 7 years later that POV-Ray crashes when using 30-digit hex 
color. Or someone complaining 7 years later that POV-Ray hasn't been 
updated to support some new HTML 8.0 colors syntax. Or the new color 
names introduced with HTML 7.0.

Supporting only a very limited, rigid subset of HTML color syntax would 
perfectly avoid this can of worms.

But given what fuss people seem capable of making about this, maybe the 
best idea would be to not support any HTML-style color syntax in the 
first place, and stick to POV-Ray's traditional way of specifying colors.

Post a reply to this message

clipka wrote:
> Rather not. I'd pretty much consider that overkill. Unless you want to 
> extend POV-Ray's capabilities to rendering HTML documents of course...

<script type="text/sdl">
   ...
</script>

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

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

Christian Froeschlin schrieb:
> 
> 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.

That might indeed be a way to go. But maybe that's better left to a 
new-generation SDL.

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

That would be ambiguous in cases like

     #declare MyBoolVariable = false;
     color rgbt!MyBoolVariable

Having the gamma adjustment tied to the color keywords also has its 
drawbacks, because...:

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

I perfectly disagree on this one: If you take a color from anywhere 
outside linear color range, you should *immediately* gamma-adjust it to 
linear, before you store it anywhere. If you just want to store it, it 
doesn't make much of a difference, but in case you want to perform any 
math on it, it is more likely to give the correct results when you do 
those computations on linear values.

Besides from that, a dedicated operator would give us the freedom to to 
either, at the user's discretion: Gamma-adjust the very literal color 
value right away, gamma-adjust in the middle of some computations, or 
gamma-adjust when it comes to actually using it as a color.

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

I'm not happy with that term, as to me it would apply only to files. 
 From the perspective of an SDL script, literal colors are not input, 
but part of the program. (You wouldn't consider constants in a C program 
to be input of that program, would you?)

As for "gamma" possibly being mistaken to indicate display gamma, I 
think if gamma handling is properly explained in the documentation, and 
made clear enough that SDL gamma settings will *not* affect the 
gamma-adjustment applied to the preview or output file, this should 
actually be a non-issue.

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> Or possibly
>
>    color rgbtg <0.5,0.5,0.5,0.2,2.2>
>
> Too bad green and gamma start with the same letter ;)

Why not use "y" for gamma?  It looks enough like a lower-case gamma...

Post a reply to this message

MDenham schrieb:
> Christian Froeschlin <chr### [at] chrfrde> wrote:
>> Or possibly
>>
>>    color rgbtg <0.5,0.5,0.5,0.2,2.2>
>>
>> Too bad green and gamma start with the same letter ;)
> 
> Why not use "y" for gamma?  It looks enough like a lower-case gamma...

I think due to the poor distinction between colors and vectors in 
POV-Ray, this might result in confusion with the y coordinate.

Post a reply to this message

Le 12/09/2009 10:25, MDenham nous fit lire :
> Christian Froeschlin <chr### [at] chrfrde> wrote:
>> Or possibly
>>
>>    color rgbtg <0.5,0.5,0.5,0.2,2.2>
>>
>> Too bad green and gamma start with the same letter ;)
> 
> Why not use "y" for gamma?  It looks enough like a lower-case gamma...
> 
> 
why not go utf-8 and use a real gamma γ or Γ ? (aaos)

I stand by my idea of a s- prefix to rgb/rgbt/rgbf/.../red/green/blue
If it is need to be able to set the gamma factor, a prefix is better:

color srgb <2.2,1.0,0.5,0.25>

Only issue, we would end up with 6D vectors (srgbtf)... a bit long,
isn't it ?

'S' prefix, for similarity to current sRGB model, and S is available letter.

Post a reply to this message

Le_Forgeron schrieb:

> why not go utf-8 and use a real gamma γ or Γ ? (aaos)

Cumbersome to input on most machines (as I already mentioned, I 
personally wouldn't mind, because I'd intend to stick mostly to linear 
colors anyway, but I'd expect some people to think otherwise :-)), let 
alone that POV-Ray's support for utf-8 is rather... well, let's call it 
"marginal" ;-)

(BTW, I need to correct my initial tongue-in-cheek suggestion of \u393 
in favor of \u3B3, as the uppercase Gamma would be inappropriate, being 
reserved for other mathematical purposes...)

> I stand by my idea of a s- prefix to rgb/rgbt/rgbf/.../red/green/blue
> If it is need to be able to set the gamma factor, a prefix is better:
> 
> color srgb <2.2,1.0,0.5,0.25>
> 
> Only issue, we would end up with 6D vectors (srgbtf)... a bit long,
> isn't it ?
> 
> 'S' prefix, for similarity to current sRGB model, and S is available letter.

I thought about it again, and I come to the conclusion that a prefix 
operator would be much more flexible, allowing to use it on scalars and 
vectors that happen to need some (linear) math to be applied to them way 
before being "promoted" to actual colors, while also retaining the 
ability to use it no sooner than when the value is actually used.

It would even allow for uses such as (using the symbol "@" as the gamma 
operator here):

     #declare MyColor = color rgb <0.5,0.5,0.5>;
     ...
     pigment { @MyColor }

As most colors will be from the same "gamma space", a 
global_settings{...} or - possibly better - default{...} parameter 
should be enough to specify the gamma to be used for that operator. This 
will reduce redundant typing effort, and will also improve legibility 
("duh, is that a 5D or 6D vector??"). Note that it could be changed 
anytime if needed (though I guess it would have to be local to any 
include file to avoid trouble). For exceptional cases, an explicit 
"gamma(COLOR,g)" function might be provided.

Or, maybe an extended syntax can be used for the operator, such as in:

     default { gamma 2.2 }

     color rgb @<0.5,0.5,0.5>     // for default gamma
     color rgb @[1.8]<0.5,0.5,0.5> // for explicit gamma

(note that a square brackets block by itself is no valid expression, so 
there would be no ambiguity with the other uses of square brackets), or:

     color rgb @1.8:<0.5,0.5,0.5>

Post a reply to this message

Le 12/09/2009 11:42, clipka nous fit lire :
> Le_Forgeron schrieb:
> 
>> why not go utf-8 and use a real gamma γ or Γ ? (aaos)
> 
> Cumbersome to input on most machines (as I already mentioned, I
> personally wouldn't mind, because I'd intend to stick mostly to linear
> colors anyway, but I'd expect some people to think otherwise :-)), let
> alone that POV-Ray's support for utf-8 is rather... well, let's call it
> "marginal" ;-)
> 
> (BTW, I need to correct my initial tongue-in-cheek suggestion of \u393
> in favor of \u3B3, as the uppercase Gamma would be inappropriate, being
> reserved for other mathematical purposes...)
> 

yes... all greek letters have already been used for one purpose or
another, according to the field of sciences.
Same for some hebrew letter (aleph anyone ?)

>     #declare MyColor = color rgb <0.5,0.5,0.5>;
>     ...
>     pigment { @MyColor }
> 
> As most colors will be from the same "gamma space", a
> global_settings{...} or - possibly better - default{...} parameter
> should be enough to specify the gamma to be used for that operator.

This sucks! a global/default would generate more issue when merging
includes from different authors.

At worst, I can envision a default setting (of 2.2, due to sRGB curve)
when providing only a 3D vector to a 4D expecting "srgb" (the "s" would
be optional, defaulting to

> This
> will reduce redundant typing effort, and will also improve legibility

Legibility ? with an opaque glyph like @ ? How do you associate that
with a gamma correction ?

typing effort... @ requires me to use 2 fingers at the same time, that's
not an easy typing. Only APL-geek would find that easier.

I still recommend using a plain classical letter(or name).

> ("duh, is that a 5D or 6D vector??"). Note that it could be changed
> anytime if needed (though I guess it would have to be local to any
> include file to avoid trouble). For exceptional cases, an explicit
> "gamma(COLOR,g)" function might be provided.

I'm still thinking that the correct order should be gamma(g,COLOR)

The issue with 6D vector is that current code might not have support for
it yet (5D is the maximum I have seen)

> 
> Or, maybe an extended syntax can be used for the operator, such as in:
> 
>     default { gamma 2.2 }
> 
>     color rgb @<0.5,0.5,0.5>     // for default gamma
>     color rgb @[1.8]<0.5,0.5,0.5> // for explicit gamma

Arghhh... So cryptic!

color srgb <1.8,0.5,0.5,0.5>


Wondering nevertheless about the "s"... maybe another letter ? c for
corrected ?

color srgb <0.5,0.5,0.5> // for classical srgb 2.2 gamma correction
color crgb <1.8,0.5,0.5,0.5> // for custom correction of 1.8

Do we really need srgbtf ? could we not just use
"color srgb<...> filter 0.4 transmit 0.3" ?

BTW... what about separating filtering color from reflecting color ?
(allowing a rgb (or whatever 3D) for filter )(backward compatible, as
plain number get promoted to vector when needed, so filter 0.4 stay
valid (but get a change of behaviour, as previously rgbf<1,0,0,.5> would
have filtered only 50% of red, no green, no blue; filter 0.4 would be a
grey 40%... even with a red reflecting surface; back to old behavior
with filter <0.5,0,0>)

Post a reply to this message