POV-Ray : Newsgroups : povray.beta-test : POV-Ray 3.7 gamma - status : Re: POV-Ray 3.7 gamma - status Server Time
7 Jul 2024 06:48:51 EDT (-0400)
  Re: POV-Ray 3.7 gamma - status  
From: clipka
Date: 17 Sep 2009 15:12:14
Message: <4ab28a0e@news.povray.org>
Ive schrieb:
> 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 ;)

Ah yes? Did we?

If you're thinking of statements from me like "what's the point in 
having perfect ICC profile handling if POV-Ray gets the gamma wrong" 
(about a workaround I had described for the gamma issues with POV-Ray, 
involving an external tool that according to you doesn't do proper ICC 
handling), and consider those an argument about ICC profiles, then yes, 
in that case I guess we did :-)


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

Indeed it isn't: The framework has been set up now, and adjustments to 
the handling should be quite easy. Including stuff like, checking for 
the file size and depending on that choosing whether to convert directly 
to float or use lookup.

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

Great to hear those things!

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

It's actually quite easy as far as the image reading code is concerned. 
Nothing that would require a dramatic change in image reading code.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.