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