POV-Ray : Newsgroups : povray.beta-test : Same scene renders different in v3.7beta34 versus v3.62 : Re: Same scene renders different in v3.7beta34 versus v3.62 Server Time
5 Oct 2024 15:32:08 EDT (-0400)
  Re: Same scene renders different in v3.7beta34 versus v3.62  
From: Warp
Date: 3 Sep 2009 15:34:11
Message: <4aa01a33@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> The question, however, is what the software reading the height field 
> interprets as 50%:

> (a) A brightnes of 50%? (That would appear to me the most "official" way 
> to handle PNG files for height fields, and leave you with the option of 
> setting File_Gamma any way you like.)

  You seem to assume that all programs which can create heightfields from
image files are actually creating heightfields from *images*, not from the
raw values stored in the image file. In other words, that they are not
considering the image file to be just a storage format for the height
values, but that it is really an image which should be "interpreted"
somehow.

  Granted, if the image in question is RGB rather than grayscale, and the
pixels have different values for R, G and B, then the program must indeed
handle it as an image rather than a height data storage file, and decide
what to do with those RGB values. I suppose one common technique is to
convert the RGB values to grayscale, ie. get the luminance component of
the image, and create the heightfield from that. In that case gamma
correction might make sense.

  However, I am talking about a situation where the image file is *not*
considered to contain an image, but "abused" as a storage format for raw
height data. Optimally it would thus be a 1-channel (ie. "grayscale") image,
where each pixel represents directly and linearly the height at that point.
(It could be an 8bpp or 16bpp "grayscale" image.)

  Especially if using 8 bits per pixel, you really don't want the pixels
to be gamma-corrected when written to the file, because that would lose
significant information. You want completely linear values. 0.5 should
mean a pixel value of 127 and nothing else.

  Even if using 16 bits per pixel it still wouldn't make much sense to
gamma-correct the pixels before writing them to the file. There would still
be loss of information (even though less significant), for no good reason.

  Unless I'm mistaken, if you specify in a POV-Ray heightfield a grayscale
image as input, POV-Ray will interpret the values as they are in the file,
without any modification. I think that's the way it should be.

  (Maybe alongside the assumed gamma correction of image maps, it could be
a good idea to be able to specify such an assumed gamma correction with
heightfields created from an image as well.)

  Of course an interesting question is what happens if the input file is
a PNG and its gamma metadata is saying that the pixels should be
gamma-corrected before usage. We are not displaying the image in this
case, so there's no need to gamma-correct the pixels for proper display. We
are using the pixels to create heights. Should they still be gamma-corrected
or not?

-- 
                                                          - Warp


Post a reply to this message

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