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