Warp schrieb:
>> 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.

Warp, this is a point where I must again ask you: Are you really reading 
my postings? Or do you just read them up to the first point that you 
deem worth arguing against?

If you did read my whole posting, then you will have noticed that I 
mentioned /all three/ possible ways of interpreting the content of a PNG 
file with gAMA chunk. Hence the (a), (b) and (c). That's actually the 
opposite of assuming any particular way of doing it.

What you refer to as creating height fields from "raw values stored in 
the image file" appears to be exactly what I described as (c), which 
happens to be what I would find most reasonable, too.

Note however that...

(1) The PNG file format was designed to store /images/, not arbitrary 
data over 2D space, and therefore the variant (a) would appear the "more 
official" way to do it, even if I'd agree that it is less reasonable.

(2) While a program creating heightfields may evaluate the raw values in 
the file, an image viewing program would still have to interpret the 
data as an image. So if there is a gAMA chunk present saying "this is 
all linear brightness data, no gamma correction has been performed 
whatsoever", the viewing program would be mandated to perform gamma 
correction to compensate for display gamma - something that the 
heightfield-generating program may refrain to do. So two files that look 
  identical in an image-viewing program - one generated with 
File_Gamma=1.0 and the other with File_Gamma=2.0 - may still result in 
different height fields.

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

That's a matter of definition. Unless I'm perfectly mistaken, the PNG 
specification makes no statements about how to interpret the data when 
it is misused for storing height fields.

I'd say pop a warning if gAMA is present and says something different 
than 1.0, and then just do /something/ (which should of course be 
documented), with the option to override whatever the gAMA chunk claims, 
by specifying "gama 1.0" (to get the raw data) or "gamma 2.2" (to get 
the linear brightness represented by the data in the file) for that 
particular file.

Post a reply to this message