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:26:51 EDT (-0400)
  Re: POV-Ray 3.7 gamma - status  
From: clipka
Date: 17 Sep 2009 09:43:04
Message: <4ab23ce8@news.povray.org>
Christoph Hormann schrieb:

>> - Image-format input files used immediately in certain language 
>> constructs obviously indicating that they are mere data containers 
>> (e.g. height fields) shall be exempt from the aforementioned 
>> conversion, and the raw encoded values used instead. (Note however 
>> that this does not apply to indirect use of input image files.)
> 
> It would OTOH be nice if POV-Ray would treat images the same way 
> everywhere (it does not in 3.6 either but that's a different story).

Well, I think there's some reason to both sides; with the per-file gamma 
setting it becomes less of a problem at any rate.


>> - 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.)
> 
> A dynamic caching scheme for converted values would be an alternative - 
> significantly more complex to implement of course.

... and quite definitely more overhead than gain for an 8-bit/channel 
image, and possibly so as well for a 16-bit/channel image (except for 
images so small that it would become worthwhile to convert them to float 
right away at load time). It might also be questionable whether it would 
be faster than just recomputing the value.

> As long as this is only about gamma correction this is probably 
> unnecessary but with color space conversions on-the-fly conversion might 
> be too expensive.

For some "norm" color spaces, I think the per-color lookup table 
approach might still be both possible and worthwhile - especially for 
8-bit/channel images - if separate lookup tables are used for each color 
channel, and each entry would store an RGB color instead of a scalar; 
those would then be just added - sort of a shortcat halfway through the 
matrix transformation found in various color space transformations.

Of course for full-fledged device color profiles this wouldn't be 
sufficient.


Post a reply to this message

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