|
 |
Warp schrieb:
> clipka <ano### [at] anonymous org> wrote:
>> http://bugs.povray.org/task/10
>
> I suppose something like that could work. One question is, however,
> whether the gamma assumption will be done when reading the image file
> (ie. the pixel colors will be changed immediately when reading them
> from the file), or only when they are needed to calculate a color (ie.
> when evaluating the pigment).
Because it would be impractical to distinguish between different /use/
of the image data (e.g. what about an image used to create a pigment,
which is then in turn to define a function?) from a logical point of
view values would have to be converted when reading the file. From an
algorithmic point of view, however, the encoding used in the file could
be preserved, and gamma computations performed whenever the pixel data
is actually evaluated (for whatever purpose).
For high-resolution texture images, on-the-fly evaluation would be the
ideal way to go (saves memory, and the number of queries per pixel are
smaller, maybe even <1 per pixel, in which case the computational
overhead would even be lower than with (A)), while for low-res an
on-load computation would obviously better.
A lossy transformation is definitely /not/ the way I'd want to go, so in
case of an on-load transformation, an 8-bit image would have to be
converted to 16-bit (which is about sufficient for gamma values around
2.0) or single-precision floating point on that occasion (half-precision
float would theoretically be an alternative, but I wouldn't want to go
for that due to lack of hardware support on most systems).
> I actually don't know if POV-Ray internally stores images in memory as
> bytes (like in the input image itself) or as floats.
Various. I haven't found the time to look at it in detail, but the image
container provides support for 8-bit, 16-bit, and single-precision float
data.
Post a reply to this message
|
|
