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

clipka <ano### [at] anonymousorg> wrote:
> 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...

  Then why have any such crippled "HTML colors" at all?

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

  Except when they don't. If you are rendering to a 48-bit image, you
might want to use 48-bit colors for the input as well.

  As I said, your suggestion is rigid and inflexible. It cannot be easily
expanded.

  And as I said, what's the point in having "HTML-style colors" if you are
going to use a very limited and crippled subset of them? What's the point?

  I don't understand what is it that you oppose in the idea of defining a
color with a string. What's so bad about that?

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

  To me that sounds more like a kludge than a solution to anything.
(What is the *problem* you are trying to solve with this "solution"?)

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

  I don't want color names. I want a *flexible* and *expandable* system for
defining colors. You missed my point entirely. The color names were just an
*example*, not the core of the suggestion.

> the rigidity and limitations is something I see as a benefit

  Then we'll just have to disagree.

  It makes no sense to make the parser more complicated for the sake of
adding a crippled, rigid feature which cannot be expanded and is mostly
useless. Better leave it out completely.

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

  And not adding any such kludge at all would avoid even more problems.

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

  I think it's only you who is making a fuss about it. You are the one who
is actually opposing HTML-style color syntax, not me.

-- 
                                                          - Warp

Post a reply to this message

clipka wrote:
> I've spent some time on digging through the gamma handling as currently 
> done by POV-Ray 3.7, as well as examining how exactly POV-Ray 3.6 
> handles things.
> 
> This is what I found how 3.6 apparently does behave, and how I think 
> POV-Ray theoretically should behave.
> 
> 
> Depending on whether assumed_gamma is specified or not, two operational 
> modes can be distinguished in 3.6, which I will call "Assumed Gamma 
> Mode" and "Screwed-Up Mode".
> 
> 
> (A) "Assumed Gamma Mode":
> 
> If an assumed_gamma is specified, POV-Ray 3.6 presumes that all "raw" 
> colors - whether literal color values in the SDL file, encoded color 
> data in input files or the encoded output image - are gamma 
> pre-corrected for the specified gamma value, unless noted otherwise. It 
> further assumes that computations should be performed on these raw color 
> values, without converting them to linear values first.
> 
> Therefore, gamma correction is only performed on the preview display, 
> taking into account both the assumed_gamma as well as the Display_Gamma 
> setting.
> 
> PNG files with a gAMA chunk make an exception:
> 
> PNG output data undergoes the very same gamma transformation as the 
> preview output, i.e. the encoded data will be pre-corrected for the 
> specified Display_Gamma. In addition, a gAMA chunk is written matching 
> the Display_Gamma, so that the image displays as previewed (provided 
> Display_Gamma was set properly) on any computer, provided the viewing 
> software respects the gAMA chunk and knows about its own display gamma.
> 
> For PNG input files coming with a gAMA chunk, the encoding gamma 
> information stored in the chunk is honored, and full gamma correction is 
> performed to account for (a) the encoding gamma as per the gAMA chunk, 
> and (b) the assumed_gamma.
> 
> (Input files used in situations where the image is obviously(!) used as 
> a mere data container, such as with height fields, are exempt from this 
> rule: They never undergo gamma adjustment, even if they are stored as 
> PNG files with a gAMA chunk.)
> 
> 
> (B) "Screwed-Up Mode":
> 
> If no assumed_gamma is specified, POV-Ray 3.6 presumes that all "raw" 
> colors - whether literal color values in the SDL file, encoded color 
> data in input files or the encoded output image - are gamma 
> pre-corrected to match whatever Display_Gamma happens to be set to.
> 
> Therefore, no gamma correction is performed whatsoever... in general.
> 
> Indeed, no gamma correction or -encoding is performed on PNG output 
> files; however, a gAMA chunk is written matching the Display_Gamma, so 
> that the image again displays as previewed.
> 
> As for PNG input files coming with a gAMA chunk, these *are* 
> gamma-adjusted, for rather obscure reasons, in a rather obscure way: 
> Aside from taking into account both the encoding gamma as per the gAMA 
> chunk, as well as the Display_Gamma, an additional constant gamma of 2.2 
> seems to have been mixed in.
> 
> (Again, input files obviously used as a mere data container are exempt 
> from this gamma adjustment.)
> 
> 
> Neither mode is really any good, for the following reasons:
> 
> (A) with a gamma of 2.2 (or anything other than 1.0, for that matter) 
> will produce physically incorrect results, because the computations are 
> designed to work on linear values, not gamma pre-corrected data 
> (although the latter is how they had been typically used for decades, 
> but that's a different story).
> 
> (A) with a gamma of 1.0 (or anything other than 2.2, for that matter) is 
> unable to properly handle any non-PNG input images that use gamma 
> pre-correction (which is virtually all material out in the wild). In 
> addition, it will require image post-processing (format conversion or 
> gamma adjustment) if any format other than PNG, HDR or OpenEXR is 
> required with gamma pre-correction applied; output will also be 
> percieved to exhibit a loss of precision, due to using linear instead of 
> gamma encoding, unless a high color depth or a high dynamic range file 
> format is used for output. (The current implementation also suffers from 
> PNG input quality being degraded due to the gamma transformation.)
> 
> (B) suffers from the same problems as (A), except that it perfectly 
> screws up on PNG input files.
> 
> 
> This is exactly the reason why 3.7 is moving towards yet another gamma 
> handling mode, which I'll call "Proper Gamma Mode":
> 
> 
> (C) "Proper Gamma Mode":
> 
> The proper way of handling gamma is to perform all computations on 
> proper linear color values, while allowing for both input and output 
> files to use gamma encoding or pre-correction.
> 
> Therefore, gamma adjustment must be performed (or at least considered) 
> on *all* output (both files and preview), as well as any input files 
> (unless obviously used as a mere data container). The same should go for 
> colors explicitly specified in the scene file.
> 
> For output, this gamma correction is governed by Display_Gamma, 
> specifying the gamma pre-correction to be used for preview, as well as 
> File_Gamma, governing the gamma encoding or pre-correction to be used.
> 
> Furthermore, for file formats defining a standard way to handle gamma, 
> the standard should be adhered to, ignoring File_Gamma if necessary. 
> This allows for one and the same File_Gamma setting to give good results 
>  with all output file formats, whether they are typically expected to be 
> gamma pre-corrected due to lack of explicit specification (e.g. BMP or 
> JPEG), explicitly specified to use a variable encoding gamma (e.g. PNG 
> with gAMA chunk), or explicitly specified to use linear encoding (e.g. 
> OpenEXR). This allows a casual user to define a sane File_Gamma in his 
> global povray.ini, and not worry about the setting regardless of output 
> file format.
> 
> For input files, there is no proper handling implemented yet. However, I 
> propose the following solution:
> 
> - A global SDL setting "file_gamma", to specify the gamma pre-correction 
> to assume for input files.
> 
> - File format specifications take precedence over the global 
> "file_gamma" setting, e.g. PNG files with a gAMA chunk are 
> gamma-adjusted according to the gAMA information alone, and OpenEXR and 
> Radiance HDR files are not subject to any gamma-adjustment as they are 
> defined to carry linear data. This is consistent with handling of the 
> File_Gamma INI setting.
> 
> (Again, as in (A) and (B), input files obviously used as a mere data 
> container will be exempt from this gamma adjustment.)
> 
> - An optional per-file SDL setting "file_gamma", to specify the gamma to 
> apply to the raw encoded data, irregardless of the global setting or 
> file format specifications. This allows for using files that do not 
> follow the specification for some reason or another.
> 
> (If an individual file_gamma is specified for an input file, it *will* 
> be subject to the appropriate gamma conversion even if it is obviously 
> used as a mere data container: It is expected that the user knows what 
> he's doing when overriding gamma.)
> 
> - As for colors explicitly specified in the scene file, I do not have a 
> concrete proposal for now, but I'm thinking along the lines of a 
> color/vector function, as in:
> 
>     color gamma( rgbt <0.5,0.5,0.5, 0.2>, 2.2 )
> 
> (note that this would leave the transmit component unchanged) or 
> possibly an infix operator, as in:
> 
>     color rgbt <0.5,0.5,0.5, 0.2> gamma 2.2
> 
> Not sure about it yet; the former is pretty unambiguous, but seems a bit 
> cumbersome to me, while the latter looks much nicer but may provide some 
> pitfalls.
> 
> 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
> }
> ...
> #declare MyPigment = pigment { color rgbt #<0.5,0.5,0.5,0.2> }
> 
> Any distinctive syntax would do; I just happened to pick this one as an 
> example because of its similarity with the current color syntax while 
> alluding to the HTML color syntax. Note that the "#" could actually be 
> defined as a prefix operator, and in that case could also be used in 
> "color red #0.5" or "color rgb #(<0.2,0,2,0,2>*0.3)".
> 
> Maybe we can even go so far as to allow HTML colors in SDL code? Those 
> would automatically be subject to gamma correction.
> 
> Then again, ambiguities would arise whether for instance "#version" 
> would be the version statement, or the version variable subject to gamma 
> correction, so maybe "#" would not be ideal to be used for that purpose. 
> There are other symbols though which are not used at present, such as 
> the caret (^, used in various languages as an infix operator for the 
> pow() function, which would allude to the mathematical background of 
> gamma adjustment), dollar ($), at (@), percent (%, though that's 
> typically associated with the modulus function) or tilde (~, used in 
> some languages to denote binary inverse). Grave (`) is also still 
> available (though it's possibly too easy to mix up with single quote), 
> as well as the backslash (\). (If unicode characters were an option, I 
> would suggest \u0393 for obvious reasons - but only because I don't 
> intend to use gamma pre-corrected colors frequently :-))
> 
> Then again, it could be simply ruled that the "#" as an operator must 
> either be followed by a number literal, vector literal ("<...>"), or 
> parenthesized expression ("(...)")... or possibly a 6-digit hexadecimal 
> value :-).
> 
> (The more I think about this, the more I like this particular way of 
> handling gamma-pre-corrected colors. The only true caveat I see so far 
> would be the use in include files, which might want their own gamma 
> setting.)
> 
> 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.
> 
> 
> So, having said all that: Any comments / corrections / further suggestions?



I completely agree with all of your points and I also think your 
proposed solution is the right way to go.
A minor issue would be that I do not see the need for a global SDL 
"file_gamma" setting but I guess it will not hurt either.
I have nothing to say about the SDL color definitions as I do always 
define colors in a linear way and do never use "colors.inc" and that 
like. So my only concern would be that (as I'm a bit lazy) no additional 
typing on my side would be required.


What I have to add are a few notes about file-format gamma handling:

PNG
there is also a sRGB chunk that has even higher priority than the gAMA 
chunk. So if an sRGB chunk is present the gAMA chunk (and its content) 
should be ignored and the sRGB transfer function (close to 2.2) should 
be used to transform the data into linear color space.
If no gAMA chunk and no sRGB chunk is present the PNG/W3C recommendation 
  says to handle the file in the same way is if a sRGB chunk were present.
It would be nice to actually use the sRGB transfer function - when 
approbate - instead of the simple 2.2 exponent but currently libpng has 
no support for this (it is on the libpng TODO list since quite a while).

BMP
since almost 15 years there is a "BITMAPV4HEADER" defined in WinGDI.h 
and the usage of it would make BMP files 'gamma-aware' in the same way 
as PNG. Later MS did even define a "BITMAPV5HEADER" that has full 
support for colorimetric information including ICC profiles.
I have tried very hard to find any such BMP file or any application 
(including all from Microsoft itself I could get my hands on) that would 
write such a file and did not find a single one.
The recommendation from Microsoft is to assume that all BMP's are in 
sRGB color space.

JPG
per W3C recommendation in sRGB color space in case no ICC profile is 
present.

TGA
there is a 'newer' TGA specification 2.0 (from 1989!) that defines a 
'footer' with additional metadata including gamma information. Such a 
TGA file would also be 'gamma-aware' like PNG.
But I'm not aware of any contemporary application that writes or 
recognizes such a footer. I was also unable to find such a file anywhere 
- and I really tried hard.
Most (but not all) TGA files you'll find 'in the wild' are 2.2 gamma 
pre-corrected.

PGM/PBM/PPM/PNM
no gamma information at all and the commonly used gamma correction (or 
its absence) is a matter of wild guessing.

OpenEXR/Radiance HDR
per definition in linear color space.
Just a side note: Radiance files in the xyz(e) format and OpenEXR can 
also store 'out of gamut' colors (i.e. one or two color components with 
negative values) and this seems to be fully supported by POV-Ray.


did I forget something, GIF? not much to say there but usually gamma 
corrected in between 1.4 and 2.4 - its a matter of guessing again.

-Ive

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> If no gAMA chunk and no sRGB chunk is present the PNG/W3C recommendation 
>   says to handle the file in the same way is if a sRGB chunk were present.

  There should be a way for the user to specify an assumed gamma for input
images, so for PNGs with no gamma information at all, the user-defined
assumed gamma should be used.

  Of course if the user has not specified an assumed gamma for the input
image either, then the default should probably be Display_gamma (ie. so that
the image will look in POV-Ray the same it looks when viewed with some
image viewing program).

-- 
                                                          - Warp

Post a reply to this message

Le_Forgeron schrieb:
>> 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.

I object to the notion of this to "suck", as you put it. Granted, it may 
have its drawbacks in that particular case. Still, as long as includes 
are only included (instead of manually merged), and can have their own 
local default gamma, this is a non-issue.

Also note that when manually merging includes, you're opening a can of 
worms anyway, like differing #version settings, potential variable name 
clashes, total dimensions, media densities, and other some such, so I 
see no great harm in adding one single more thing to take care of in 
this case.

On the other hand I see a significant benefit of not having to type the 
gamma value all the time.

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

How do you associate ! with logic negation, or | with logical and? How 
do you associate <..,..,..> with vectors?

Why, by convention of course.

Not to mention that at present, I'm considering the @ sign to be just a 
working draft.

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

Oh Hell, two fingers on keyboard! What a catastrophe!

Hey, get real: You need to press the "shift" key for quite a host of 
things, I guess. As a German, for instance, I need to press "shift" to 
get a multiplication asterisk, dividing slash, opening or closing 
parentheses, quotes etc, and "altGr" to get curly braces or square brackets.

With your proposed solution, you need to type the gamma value over and 
over again - which obviously does not require to press multiple keys 
simultaneously, but only a one-fingered man would find that easier than 
having to type a single character - even if it would involve a 
three-finger move.

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

that would be all the same to me.

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

Arghhh... Even more cryptic!

With the @[GAMMA]<...> syntax, at least it's clear at first glance that 
gamma correction is performed (provided of course the reader is familiar 
with the "@" sign being used for that purpose).

With the srgb <GAMMA,...> syntax, you have the following issues:

- While there is indeed no "natural" association of the "@" symbol with 
gamma correction, neither is this the case for the "s" prefix. The user 
would have to know that the sRGB color space includes some gamma 
adjustment - and would then be all confused why he should specify a 
gamma, because sRGB does not allow for choosing a gamma at will. So no 
bonus for the srgb syntax as being more "natural".

- At a quick glance, "srgb" might be mixed up with all the other "rgb" 
things, which already make it difficult to quickly identify the blue 
component (is this rgb, so that blue is the rightmost component? is this 
rgbt or rgbf, so that blue is the second to right? Or is this even 
rgbtf, so that blue is the third to right?); your proposal adds to this 
the problem of quickly identifying color components by starting from the 
left of the vector.

- The syntax you propose might also have users think that gamma would be 
a component of a color vector - when in fact it is just some math 
applied to the color.

- As already mentioned, it would prevent performing gamma-correction as 
early as possible on colors not explicitly specified as such, but as a 
standard 3D vector instead. For instance, it would absolutely prevent 
the use of gamma-corrected colors in a macro that would expect the 
colors to be passed as pure 3D vectors or as individual components.

No, I really don't see your proposed syntax as any less cryptic - rather 
to the contrary.


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

A bit problematic - not only due to the change in semantics (which would 
be easily addressed by promoting "transmit" to an RGB color vector 
instead, and dropping "filter" altogether). Still, this would create 
problems with some legacy syntax variants, such as:

     color rgb <R,G,B> transmit T filter F
     color filter F red R green G blue B

Additional problems would arise of the poor separation of vectors and 
colors in POV-Ray, so various scripts may rely on the 4th and/or 5th 
fields of 5D vectors to be accessible via the .filter and .transmit 
keywords, respectively, and others may rely on certain vector math 
operations working on colors in a particular way.

Still, there may be ways to overcome even these obstacles, and indeed 
this has been lurking at the back of my head for quite some time now. 
There are actually a few uglies in the tracing code due to not having 
full-color transparency, and those keep nagging at me.

Post a reply to this message

clipka wrote:

>>   color rgbt! <0.5,0.5,0.5,0.2>
> 
> That would be ambiguous in cases like
> 
>     #declare MyBoolVariable = false;
>     color rgbt!MyBoolVariable

Hmm, I hope it reports an error either way ;)

> Having the gamma adjustment tied to the color keywords also has its 
> drawbacks

Yes, but gamma is inherently related to defining a color and
not a vector. I find it confusing to add the gamma correction
prefix to the "vector part" of the syntax (not sure how the
parser views it technically but to the user it looks like
color rgb takes a vector argument).

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

Well, I was thinking from the renderers point of view. Among other
things it gets parsed pigments as input some of which may stem from
image_maps and some with actual color definitions. How about
"pigment_gamma" or similar? I assume an image which is used
for texture maps or normals should not be gamma corrected.

Post a reply to this message