clipka wrote:

> - POV-Ray shall always operate in a linear RGB color space based on 
> light intensity (as opposed to perceived brightness), to properly 
> compute physical effects. (In the long run, this should also include a 
> clear definition of the RGB primaries and white point, but at present 
> this definition is limited to gamma issues.)
> 
> - In General, all image-format input files sall be converted to 
> POV-Ray's operating color space before any further processing. (In the 
> long run, this should include full color profile handling; however, at 
> present it is limited to gamma correction.)
> 

So meanwhile you do agree with me that POV-Ray should have "in the long 
run" a well defined RGB color space while I do remember a few months ago 
we had some struggle about this issue ;)


> - For file formats with an official specification...
 > [SNIP (a lot)]

Sounds all very good to me.


> * Implementation
 > [SNIP]
> - Non-paletted integer images are kept in "native" format without 
> applying gamma adjustment, in order to save memory. Gamma correction is 
> instead applied at render time, using a pre-computed lookup table in 
> hope of gaining a bit of a speed advantage. (Lookup tables are shared 
> between images with the same gamma curve of course.)
> 

I already wanted to ask you about this - as at some point it seemed to 
me you intend to store all data in floating point format - but then I 
did completely forget about it.
While I think it is a very good idea to use lut's for 8 bps I do believe 
it should not be done for 16 bps as they are meant to apply things like 
inverse gamma correction without *any* visual impact. But this is not an 
important issue.


And BTW I've rewritten tiff.cpp from scratch and the most simple and 
basic cases is already working: RGB data that is ordered interleaved 
(and not in separate color planes) arranged in strips (and not tiles) 
and uses unsigned 8 or 16 bit integers (not signed ones).
The nice thing is that full floating point HDR TIFF support for 16bit 
(the same 'half' format as used by OpenEXR), 24bit (yes, such a thing 
exists) and 32bit (the 'normal' float) is already working.
And I intend to implement TIFF *output* for 32bit floats as I think it 
would be nice to have this feature available especially within an 
already well defined image file format.
So sooner or later I need to know more details about your implementation 
of the file gamma correction but most probably I will not finish the new 
TIFF implementation befor the next beta is out...


-Ive

Post a reply to this message