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?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Maybe we can even go so far as to allow HTML colors in SDL code? Those 
> would automatically be subject to gamma correction.

  If a color is expected but a string is found instead, then that string
could be interpreted as a color definition in HTML (or other similar)
syntax.

  In other words, where you would normally write eg:

    rgb <.5, .75, 1>

you can write instead:

    "#7FBFFF"

  As for a special shortcut syntax to gamma-precorrect regular color
definitions, I don't have many good ideas. Perhaps @ as a prefix could
work.

-- 
                                                          - Warp

Post a reply to this message

Le 11/09/2009 23:02, Warp nous fit lire :
> clipka <ano### [at] anonymousorg> wrote:
>> Maybe we can even go so far as to allow HTML colors in SDL code? Those 
>> would automatically be subject to gamma correction.
> 
>   If a color is expected but a string is found instead, then that string
> could be interpreted as a color definition in HTML (or other similar)
> syntax.
> 
>   In other words, where you would normally write eg:
> 
>     rgb <.5, .75, 1>
> 
> you can write instead:
> 
>     "#7FBFFF"
> 
>   As for a special shortcut syntax to gamma-precorrect regular color
> definitions, I don't have many good ideas. Perhaps @ as a prefix could
> work.
> 
I hate srgb, but using html code is worst for povray. Within html, you
are limited to 0-1 range... whereas <..> notation is not. I like
"negative colours". And hdri like big ones!

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) BTW, would you gamma-correct F or T ??? why ?

Beware, valid html code could be #fff, #ffffff or even bigger (never
seen, but possible, any multiple of 3 symbols is ok; worse, a multiple
of 4 symbol might be rgba space... guess what happened for a 16
bit-component rgba vs 12 bit rgba : you cannot be right) but who cares
with today 5/6 bits LCD screens!

If you want #7FBFFF ... might I suggest a macro for that ? or just go
for it, but srgb seems cleaner to me.

Post a reply to this message

Warp schrieb:
>   If a color is expected but a string is found instead, then that string
> could be interpreted as a color definition in HTML (or other similar)
> syntax.
> 
>   In other words, where you would normally write eg:
> 
>     rgb <.5, .75, 1>
> 
> you can write instead:
> 
>     "#7FBFFF"

I don't like this one, because it adds some stuff (the quotes) which 
shouldn't be necessary in an ideal world. (In addition, it might make 
people try to use other strings there, which would open up the problem 
of how to deal with unrecognized ones, and whether only string literals 
would be allowed or also string variables.)

How about this - it should be perfectly safe:

A hash sign (#) followed by six uppercase(!) hex digits could denote a 
HTML color.

With POV-Ray's reserved words being all-lowercase, and purely numerical 
values after a hash not being used at present, this should be perfectly 
unambiguous.

(At present, six lowercase hex digits should also be safe: Unless I'm 
mistaken, the only token that could be interpreted as a hex value is 
"df3", which isn't used after a hash sign, nor is it six characters 
long. However, that isn't guaranteed to stay this way.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >   If a color is expected but a string is found instead, then that string
> > could be interpreted as a color definition in HTML (or other similar)
> > syntax.
> > 
> >   In other words, where you would normally write eg:
> > 
> >     rgb <.5, .75, 1>
> > 
> > you can write instead:
> > 
> >     "#7FBFFF"

> I don't like this one, because it adds some stuff (the quotes) which 
> shouldn't be necessary in an ideal world.

  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.

> (In addition, it might make 
> people try to use other strings there, which would open up the problem 
> of how to deal with unrecognized ones

  What kind of problem? Just give a parsing error.

> and whether only string literals 
> would be allowed or also string variables.)

  Why shouldn't variables be allowed?

> How about this - it should be perfectly safe:

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

  Besides, from an implementation point of view the string is just perfect
because there's no ambiguity: When a color is expected, if a string
expression is found instead, the string is parsed as the color. However,
having a # followed by something exceptional is only going to cause severe
problems, besides being awkard, rigid and limited.

-- 
                                                          - Warp

Post a reply to this message

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

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

Christian Froeschlin schrieb:

> 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

I'd actually disagree (though I see your point): Raytracing is quite a 
lot about physics, and therefore POV-Ray tends to use physical 
parameters. For colors, this means that the defining coefficients are 
luminance values. If you want to define colors based on any other set of 
parameters (e.g. gamma pre-corrected RGB coefficients), you must convert 
it to luminance values *first*.

 > (not sure how the
> parser views it technically but to the user it looks like
> color rgb takes a vector argument).

That's something I find particularly confusing about POV-Ray's color 
syntax, and I hope a next generation SDL will do away with that by 
constructing a clear "language barrier" between vectors and colors, 
allowing conversion from one to the other only via helper functions or 
some such.

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

You're trying to move the gamma correction away from the file, and to 
its use in an actual "real-life" pigment instead, but this opens up a 
can of worms.

What if an image is used in a pigment, which is subsequently converted 
to a function, which in turn is then used in a height field, or in a 
texture or normal map?

You cannot carry gamma as a sideband information across functions, as 
those may apply some math to it, which may in turn require a particular 
gamma (typically linear).

The only "sane" solution to this dilemma I see is to warn users that 
gamma adjustment *will* be applied to *all* images, unless used in the 
following language constructs: ...(tbd)..., and that if they want to 
change the behavior for a particular file, they *must* explicitly 
specify a "gamma" parameter for this one.

The name of the default parameter should reflect this perspective.

Post a reply to this message

Ive schrieb:

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

That's very helpful information indeed.

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

As far as I see, leaving the job of gamma-correction (let alone sRGB 
transfer function) to the libpng also comes with the drawback of losing 
precision, as the interface stays 8 bit, right? (At least that's how it 
appears the way POV-Ray currently uses the interface.)

This is actually a problem I see with most of POV-Ray's file input code, 
as data is typically stored no wider than 8 bits per channel unless the 
encoded data is wider already.

Post a reply to this message

Warp schrieb:

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

Ah... yes, indeed. You might want to read my OP on this topic :-P.

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

I had thought about a gamma of 2.2 (to closely match sRGB), or the 
File_Gammma INI setting (so that previously rendered images will be read 
in properly). But you're making a point there, too.

Thinking about it, I'd suggest to go for File_Gamma: Usually the user 
will not only expect the input files to look in the render preview as 
they did in his image viewer, but he will also expect the output file to 
look in his image viewer as it did in the preview, so he will typically 
set both Display_Gamma and File_Gamma to the same value anyway. However, 
in case the user is viewing files on a different machine (having a 
different gamma) that he is running POV-Ray on, or if his display 
hardware and OS have an awkward gamma but his viewing software is well 
calibrated, the user would set the two parameters differently, and in 
this case File_Gamma would be the better bet for input files.

Post a reply to this message

clipka wrote:

> Thinking about it, I'd suggest to go for File_Gamma: Usually the user 
> will not only expect the input files to look in the render preview as 
> they did in his image viewer, but he will also expect the output file to 
> look in his image viewer as it did in the preview, so he will typically 
> set both Display_Gamma and File_Gamma to the same value anyway. However, 
> in case the user is viewing files on a different machine (having a 
> different gamma) that he is running POV-Ray on, or if his display 
> hardware and OS have an awkward gamma but his viewing software is well 
> calibrated, the user would set the two parameters differently, and in 
> this case File_Gamma would be the better bet for input files.

I really do not see why not simply respecting the W3C/PNG recommendation 
as every contemporary browser (meanwhile even including IE) and every 
not totally brain-dead image viewer does.

-Ive

Post a reply to this message

clipka wrote:
> As far as I see, leaving the job of gamma-correction (let alone sRGB 
> transfer function) to the libpng also comes with the drawback of losing 
> precision, as the interface stays 8 bit, right? 

Absolutely.


> This is actually a problem I see with most of POV-Ray's file input code, 
> as data is typically stored no wider than 8 bits per channel unless the 
> encoded data is wider already.

I completely agree and actually for exactly this reason I did recommend 
the conversion from JPEG to 16-bps PNG files to overcome the current 
problems with image maps.


-Ive

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> I had thought about a gamma of 2.2 (to closely match sRGB), or the 
> File_Gammma INI setting (so that previously rendered images will be read 
> in properly). But you're making a point there, too.

  It would also automatically fix the current problem with image maps
without the user having to specify anything in the scene file itself.

-- 
                                                          - Warp

Post a reply to this message

To make life easier that's the libpng call for getting the
sRGB chunk information. For the sole purpose of gamma correction you can 
safely ignore the value that is returned as sRGB_intent.


int sRGB_intent;

if (png_get_sRGB(png_ptr, png_inf, &sRGB_intent) != 0)
{
	/* sRGB chunk is present, so we can ignore any gAMA chunk */

	[,,,]

}



-Ive

Post a reply to this message

Ive schrieb:
> I really do not see why not simply respecting the W3C/PNG recommendation 
> as every contemporary browser (meanwhile even including IE) and every 
> not totally brain-dead image viewer does.

Um - misunderstanding here:

The default gamma for input files would be intended to kick in *only* 
for files where no gamma information is to be had (or where 
sophisticated gamma / color profile handling hasn't been implemented yet).

For PNG files, the gAMA chunk information would still take precedence. 
(And as for sRGB chunks, if I'm asked the only legitimate reason to 
continue ignoring them is lack of the manpower needed to implement the 
proper handling; the same goes for full-fledged color profiles, by the way.)

To override the decoding gamma for files with explicit gamma information 
or a fixed gamma, the user would have to explicitly specify a decoding 
gamma on a per-file basis.

Post a reply to this message

Warp schrieb:
>   It would also automatically fix the current problem with image maps
> without the user having to specify anything in the scene file itself.

What current problem?

Post a reply to this message

Ive schrieb:
>> This is actually a problem I see with most of POV-Ray's file input 
>> code, as data is typically stored no wider than 8 bits per channel 
>> unless the encoded data is wider already.
> 
> I completely agree and actually for exactly this reason I did recommend 
> the conversion from JPEG to 16-bps PNG files to overcome the current 
> problems with image maps.

BTW, does the jpeglib provide a way to get the raw YCrCb data out of JPG 
files and do all the color math on floats?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >   It would also automatically fix the current problem with image maps
> > without the user having to specify anything in the scene file itself.

> What current problem?

  I can't believe you have already forgotten the superlong thread about
the subject. Are you honestly saying that you can't remember what the
problem with input images in POV-Ray 3.7 currently are? Really?

  Anyways, in short, if the input image has no gamma information, and the
user has not specified any assumed gamma for that particular input image,
then if POV-Ray used an assumed gamma equivalent to File_Gamma (or perhaps
Display_Gamma), there would be no need for this:
http://bugs.povray.org/task/10

-- 
                                                          - Warp

Post a reply to this message

clipka wrote:
> BTW, does the jpeglib provide a way to get the raw YCrCb data out of JPG 
> files and do all the color math on floats?

Code fragment:

FILE	*File;
struct	jpeg_decompress_struct cinfo;

jpeg_create_decompress(&cinfo);
jpeg_stdio_src(&cinfo, File);


if (jpeg_read_header(&cinfo, TRUE) == 1)
{

	/*
	thats it, this will force jpeglib to return
	unconverted YCbCr (or only Y for JCS_GRAYSCALE):
	*/

	cinfo.out_color_space = cinfo.jpeg_color_space;

	/*
	now the decompression stuff
	*/	

	[...]
}



But note, the jpeg_color_space is defined as

typedef enum {
	JCS_UNKNOWN,		/* error/unspecified */
	JCS_GRAYSCALE,		/* monochrome */
	JCS_RGB,		/* red/green/blue */
	JCS_YCbCr,		/* Y/Cb/Cr (also known as YUV) */
	JCS_CMYK,		/* C/M/Y/K */
	JCS_YCCK		/* Y/Cb/Cr/K */
} J_COLOR_SPACE;


where JCS_RGB, JCS_CMYK are only used for the transformation and will 
*never* appear within cinfo.jpeg_color_space.

If cinfo.jpeg_color_space is JCS_UNKNOWN reject the file, could be anything.

If cinfo.jpeg_color_space is JCS_GRAYSCALE only one component (Y) is 
used and stored, the most simple case.

The most common case is off course cinfo.jpeg_color_space is JCS_YCbCr.

And my recommendation would be to reject JCS_CMYK because without color 
management and the usage of the ICC profile that usually accompanies 
such a file there is NO transformation to rgb possible.

To see how the YCbCr -> RGB transformation is done within jpeglib have a 
look at jdcolor.c"

-Ive

Post a reply to this message

Ive wrote:

> And my recommendation would be to reject JCS_CMYK because...

Err, this should be "...reject JCS_YCCK..."

-Ive

Post a reply to this message

clipka wrote:

> Um - misunderstanding here:
> 
> The default gamma for input files would be intended to kick in *only* 
> for files where no gamma information is to be had (or where 
> sophisticated gamma / color profile handling hasn't been implemented yet).
> 

to cite myself:

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

So for PNG the gamma is always defined!
Or did I miss something else in the discussion?

-Ive

Post a reply to this message

Ive wrote:
> 
> 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.
> 

Oops. it seems I'm a bit biased against GIF so to be fair there is also 
the usual W3C recommendation to assume GIF to be in sRGB but I have an 
old GIF collection since good old Compuserve days that are obviously not.


-Ive

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> Ive wrote:
>
> > And my recommendation would be to reject JCS_CMYK because...
>
> Err, this should be "...reject JCS_YCCK..."
>
> -Ive
From what I'm reading elsewhere, Y/Cr/Cb/K can be folded down to Y/Cr/Cb by just
subtracting K from Y.  (Yes, this means you'd need to potentially support a
negative luma component in the process of generating the colors at any given
spot...  but shouldn't the internal calculation not have an issue with that
anyway, given that negative channel values can crop up in OpenEXR files
already?)

Am I reading stuff from people who are grossly misinformed?

Post a reply to this message

Ive schrieb:
> Or did I miss something else in the discussion?

No, I did - I had only skimmed over the information you provided, and 
missed that detail then.

Post a reply to this message

Warp schrieb:
>>>   It would also automatically fix the current problem with image maps
>>> without the user having to specify anything in the scene file itself.
> 
>> What current problem?
> 
>   I can't believe you have already forgotten the superlong thread about
> the subject. Are you honestly saying that you can't remember what the
> problem with input images in POV-Ray 3.7 currently are? Really?

Sorry, I misread your message to read "height fields" instead of "image 
maps".

Looks like I seriously needed to get some sleep...

(Speaking of height fields: After having dug through the code, I can 
state with confidence that for height fields, even PNG files are always 
read in as encoded, without taking the gAMA chunk into account, so at 
least for those you don't need to "amputate" the gAMA chunk.)

Post a reply to this message

MDenham schrieb:
> Ive <"ive### [at] lilysoftorg"> wrote:
>> Ive wrote:
>>
>>> And my recommendation would be to reject JCS_CMYK because...
>> Err, this should be "...reject JCS_YCCK..."
>>
>> -Ive
> From what I'm reading elsewhere, Y/Cr/Cb/K can be folded down to Y/Cr/Cb by just
> subtracting K from Y.  (Yes, this means you'd need to potentially support a
> negative luma component in the process of generating the colors at any given
> spot...  but shouldn't the internal calculation not have an issue with that
> anyway, given that negative channel values can crop up in OpenEXR files
> already?)
> 
> Am I reading stuff from people who are grossly misinformed?

Don't know, but the first google result I found on "YCCK" gave this 
information:

"There are a number of issues here. The K channel is an extension of the
Y channel. The question is what is the nature of the the CMYK data?
Is it linear in percent dot? If that is the case, the image you see
should be negative. If the CODEC unfolded the data and reversed it you
have to check if it has also applied gamma correction. If it has, then
you need to apply a gamma 2.2 to the Y and K channels, sum them, and
then apply a gamma .45 to the resultant sum. This is only an
approximation."

So apparently the YCCK color space is to CMYK what YCbCr is to RGB. 
Given that CMYK has something to do with how much ink should be printed 
of which color, which is subject to various conditions such as how much 
bleeding occurs in the paper and all such things, I guess this "just 
subtract K from Y" is more of a kludge than a proper handling.

BTW, I presume that out_color_space will default to JCS_CMYK for such 
files; in that case, POV-Ray will reject those files anyway at present.


Ive, would it be a solution for such cases (but only those) to override 
the out_color_space with JCS_RGB, and have the library do the whole job 
(at the cost of precision)?


As for negative color components, POV-Ray does appear to handle these in 
some sane fashion in *most* cases, but - as it appears to me - not all. 
In particular, I recently saw some indication that shadows cast by 
semi-transparent stuff needs to be revisited on this issue.

Post a reply to this message

Ive, do you happen to know anything about IFF?

(Maybe "not worth bothering about because it is definitely long obsolete 
by now"?)

Post a reply to this message

MDenham wrote:

> From what I'm reading elsewhere, Y/Cr/Cb/K can be folded down to Y/Cr/Cb by just
> subtracting K from Y.  (Yes, this means you'd need to potentially support a
> negative luma component in the process of generating the colors at any given
> spot...  but shouldn't the internal calculation not have an issue with that
> anyway, given that negative channel values can crop up in OpenEXR files
> already?)
> 

You are confusing things here. Negative luminance is just impossible 
while having one or two negative RGB components (with at least one 
positive) is perfectly valid and is indeed needed to describe colors out 
of the gamut of the current RGB color system. In practice this means 
e.g. colors that are not displayable on your CRT/LCD monitor but do 
exist in the real world. Usually such colors are highly saturated 
'neon'-colors.

The transformation from YCCK to RGB would require 2 steps.
First transform from Y/Cb/Cr to CMY in the same way as the YCbCr -> RGB 
conversion is done (but actually you will get CMY values if 
jpeg_color_space is JCS_YCCK ) either by using a set of pre-build lookup 
tables like libjpeg does for speed reasons or by actually calculating 
the transformation in place.
Leave the K untouched and you get CMYK.
But the transformation from CMYK (being a color separation) to RGB is 
impossible without also knowing the used CMYK color space definition as 
defined e.g. within an ICC profile. POV-Ray does currently not support 
such color profiles.
And I know that there exists this simple 'formula' for converting CMYK 
to RGB but believe me, this 'formula' should have never existed in the 
first place. It once even found its way into the wikipedia article about 
CMYK that was a mess at this time anyway and it was quite some fighting 
involved to remove it. This happened a few years ago and meanwhile the 
article is a quite good one. So if you are interested you may want to 
look at the CMYK to RGB conversion section there for more details.


> Am I reading stuff from people who are grossly misinformed?

Might be ;)

-Ive

Post a reply to this message

clipka wrote:
> Ive, do you happen to know anything about IFF?
> 
> (Maybe "not worth bothering about because it is definitely long obsolete 
> by now"?)

Besides some sweet memories, an Amigo 500 was the fist machine I did use 
POV-Ray with, I do also remember that I have a format specification 
somewhere but as this might even be on some old 3.5" disk chances are 
not very good that I will ever find it again.
But I do remember that the IFF/ILBM format was tailored to tightly fit 
the Amiga hardware so I would be surprised if there was anything else 
used as the actual system gamma of an Amiga. But I do not remember what 
this might have been.
But while thinking about it, as the format was later even used on Atari 
and Mac systems I might even be mistaken in this respect.

-Ive

Post a reply to this message

clipka wrote:
> Ive, would it be a solution for such cases (but only those) to override 
> the out_color_space with JCS_RGB, and have the library do the whole job 
> (at the cost of precision)?
> 

No. Libjpeg does not support a YCCK -> RGB transformation and it does 
not support CMYK -> RGB transformation. So if the jpeg_color_space is
JCS_YCCK you can either get JCS_YCCK or JCS_CMYK from the library and 
have to deal with color separations for yourself anyway.

-Ive

Post a reply to this message

Ive schrieb:
> No. Libjpeg does not support a YCCK -> RGB transformation and it does 
> not support CMYK -> RGB transformation. So if the jpeg_color_space is
> JCS_YCCK you can either get JCS_YCCK or JCS_CMYK from the library and 
> have to deal with color separations for yourself anyway.

No thanks - not for starters at least :-)

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> MDenham wrote:
>
> > From what I'm reading elsewhere, Y/Cr/Cb/K can be folded down to Y/Cr/Cb by just
> > subtracting K from Y.  (Yes, this means you'd need to potentially support a
> > negative luma component in the process of generating the colors at any given
> > spot...  but shouldn't the internal calculation not have an issue with that
> > anyway, given that negative channel values can crop up in OpenEXR files
> > already?)
> >
>
> You are confusing things here. Negative luminance is just impossible
> while having one or two negative RGB components (with at least one
> positive) is perfectly valid and is indeed needed to describe colors out
> of the gamut of the current RGB color system.

Eh, negative luminance + positive Cr/Cb = <+,-,+> potentially (forgive the
massively bastardized variation on standard color syntax ;-D) - and negatives
on green are, from looking at normal "RGB vs. real coloring" gamut diagrams,
probably the most common colors that exist but aren't displayable.  Also, the
engine already handles "impossible" colors (components all negative,
hypersaturated colors that extend outside the gamut in the opposite direction,
&c.) so it's not like that's necessarily an issue other than the obvious "it'll
look weird and may not behave entirely correctly".

> In practice this means
> e.g. colors that are not displayable on your CRT/LCD monitor but do
> exist in the real world. Usually such colors are highly saturated
> 'neon'-colors.
>
> The transformation from YCCK to RGB would require 2 steps.
> First transform from Y/Cb/Cr to CMY in the same way as the YCbCr -> RGB
> conversion is done (but actually you will get CMY values if
> jpeg_color_space is JCS_YCCK ) either by using a set of pre-build lookup
> tables like libjpeg does for speed reasons or by actually calculating
> the transformation in place.
> Leave the K untouched and you get CMYK.
> But the transformation from CMYK (being a color separation) to RGB is
> impossible without also knowing the used CMYK color space definition as
> defined e.g. within an ICC profile. POV-Ray does currently not support
> such color profiles.
> And I know that there exists this simple 'formula' for converting CMYK
> to RGB but believe me, this 'formula' should have never existed in the
> first place. It once even found its way into the wikipedia article about
> CMYK that was a mess at this time anyway and it was quite some fighting
> involved to remove it. This happened a few years ago and meanwhile the
> article is a quite good one. So if you are interested you may want to
> look at the CMYK to RGB conversion section there for more details.
Isn't the "formula" for CMYK->RGB essentially specific to an "ideal" ICC
profile?  If so...  *goes off to figure out a good syntax for true spectral
lighting and pigmenting, which is probably more in the realm of additions to
4.0 or later but would allow for "true" conversions both ways as well as other,
odder effects*

Post a reply to this message

MDenham schrieb:
> *goes off to figure out a good syntax for true spectral
> lighting and pigmenting, which is probably more in the realm of additions to
> 4.0 or later but would allow for "true" conversions both ways as well as other,
> odder effects*

Yeah, that would be something nice to have.

Including fluorescence, please :-)

Post a reply to this message

MDenham wrote:
> Eh, negative luminance + positive Cr/Cb = <+,-,+> potentially (forgive the
> massively bastardized variation on standard color syntax ;-D) - and negatives
> on green are, from looking at normal "RGB vs. real coloring" gamut diagrams,
> probably the most common colors that exist but aren't displayable.  Also, the
> engine already handles "impossible" colors (components all negative,
> hypersaturated colors that extend outside the gamut in the opposite direction,
> &c.) so it's not like that's necessarily an issue other than the obvious "it'll
> look weird and may not behave entirely correctly".
> 

Jpeg's YCbCr is a 1:1 adaption of the European standard tv signal 
encoding (CCIR/ITU Rec. 601 IIRC) with the advantage that you can just 
drop the CbCr part. This did make people happy who couldn't afford a 
color tv. Sending a signal with negative Y would have made people quite 
unhappy 'cause you just imploded their brand new tv set ;)
Seriously, jpeglib uses a strict range checking anyway (to avoid such 
issues as the DCT compression might introduce some noise) and YCbCr is 
just not *designed* to represent anything outside the gamut of a tv 
monitor from this time. Thats not as bad as it sounds because, if I'm 
not mistaken, this gamut was even defined wider than the currently 
accepted sRGB gamut.


> Isn't the "formula" for CMYK->RGB essentially specific to an "ideal" ICC
> profile?

An "ideal" CMYK ICC profile is somehow meaningless and does not exist.
Therefor such a 'formula' cannot exist and this was from the very 
beginning my point ;)
What we have is a bunch of numerous international standards within the 
printing business and an ICC profile is used to make clear to what 
standard the CMYK separation does refer, tells something about the 
intended ink set, raster...  and *a lot* more things.


> *goes off to figure out a good syntax for true spectral
> lighting and pigmenting, which is probably more in the realm of additions to
> 4.0 or later but would allow for "true" conversions both ways as well as other,
> odder effects*
> 

This is of course also something I would like to have, but as I'm not so 
patient I'll wait with such things until computing power evolves much 
more...


-Ive

Post a reply to this message

Ive wrote:

> I do also remember that I have a format specification 
> somewhere but as this might even be on some old 3.5" disk chances are 
> not very good that I will ever find it again.

http://www.wotsit.org/list.asp?al=I

Post a reply to this message

Ive schrieb:
> To make life easier that's the libpng call for getting the
> sRGB chunk information. For the sole purpose of gamma correction you can 
> safely ignore the value that is returned as sRGB_intent.

How about just checking for "png_inf->valid & PNG_INFO_sRGB"? Shouldn't 
that do the same job?

Another thing: The sRGB spec speaks of aiming to achieve an overall 
viewing gamma of 1.125; am I however correct in assuming that decoding 
sRGB-encoded material according to the sRGB decoding function will 
nonetheless reconstruct the /linear/ data?

Otherwise, if sRGB-encoded data was expected to already account for that 
desired viewing gamma, for raytracing purposes it would theoretically 
have to be compensated for, both when decoding and encoding.

Post a reply to this message

clipka wrote:

> How about just checking for "png_inf->valid & PNG_INFO_sRGB"? Shouldn't 
> that do the same job?
>

You are aware that you are breaking the poor mans idea of encapsulation 
by directly accessing the fields from png_inf ;)

And it's by no means time critical, so why not just use the API call?


> Another thing: The sRGB spec speaks of aiming to achieve an overall 
> viewing gamma of 1.125; am I however correct in assuming that decoding 
> sRGB-encoded material according to the sRGB decoding function will 
> nonetheless reconstruct the /linear/ data?
>

The sRGB viewing gamma of 1.125 is just another (poor mans) attempt of 
taking the environment illumination of some typical pc user into 
account. There are much more complicated attemps from the ICC and I 
really think we do not need to care about this.


-Ive

Post a reply to this message