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