Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> >   As it is now, there's no "official" way of making 3.7 to create a PNG
> > file which is the same as what 3.6 creates. Even "#version 3.6" won't do
> > that (because 3.7 will still write the gamma info to the PNG file, making
> > it look different). The only way to achieve that is to "abuse"  
> > side-effects of other file formats not having support for gamma
> > information.

> I would argue that v3.6 did it wrong, and the only way to get that result  
> then was to "abuse" the system.

  Saying that v3.6 did it wrong is not very helpful for someone who is
trying to render a 3.6 scene using POV-Ray 3.7.

> >   I do understand the motivation of making the image always look the
> > same regardless of what were the gamma settings of the system where the
> > image was rendered and the gamma settings of the system where the image
> > is displayed.
> >
> >   However, there are situations where you precisely *don't want* that.
> > You want raw pixel values, and nothing else, as I exemplified above.

> In which case the colours must be corrected on input. Rendering in a  
> non-linear colour space gives the wrong *colours*, not just the wrong  
> brightness.

  What kind of color correction do I need when I'm rendering an image to
be later used to generate a heightfield?

  The answer is: None. When I specify a color of 0.5, I expect a value
which is exactly half of the pixel component value range to be written
to the image file so that when the image is later used to create a
heightfield, that pixel will produce a height which is exactly half of
the maximum height.

  Having to "pre-correct" the value 0.5 in order to counter the gamma
correction in order to get what I want is unfeasible and doesn't make
too much sense. It's much more reasonable to be able to turn all gamma
corrections off.

-- 
                                                          - Warp

Post a reply to this message