 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
|
|
