|
|
|
|
|
|
| |
| |
|
|
From: Warp
Subject: Re: Same scene renders different in v3.7beta34 versus v3.62
Date: 3 Sep 2009 14:09:27
Message: <4aa00657@news.povray.org>
|
|
|
| |
| |
|
|
Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> When used as input, the pixel with the (gamma-corrected) value <0.73,
> 0.73, 0.73> will be converted back to <0.5, 0.5, 0.5> *if you use a
> gamma-aware image format*.
If you are creating an image which will later be used to generate a
heightfield, why would you want the pixels to be gamma-corrected? That
will only destroy some of the information.
For example, if you have a linear gradient 0, 1, 2, 3, ..., 255, and
then you gamma-correct them, write them to a file, then later read the
file and gamma-uncorrect them, the resulting values will not be the same
as originally. Some of the values will have been changed. There will be
some repeated values and gaps.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 03 Sep 2009 20:09:27 +0200, Warp <war### [at] tagpovrayorg> wrote:
> Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
>> When used as input, the pixel with the (gamma-corrected) value <0.73,
>> 0.73, 0.73> will be converted back to <0.5, 0.5, 0.5> *if you use a
>> gamma-aware image format*.
>
> If you are creating an image which will later be used to generate a
> heightfield, why would you want the pixels to be gamma-corrected? That
> will only destroy some of the information.
>
> For example, if you have a linear gradient 0, 1, 2, 3, ..., 255, and
> then you gamma-correct them, write them to a file, then later read the
> file and gamma-uncorrect them, the resulting values will not be the same
> as originally. Some of the values will have been changed. There will be
> some repeated values and gaps.
Not if you set File_Gamma to 1.0.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: Same scene renders different in v3.7beta34 versus v3.62
Date: 3 Sep 2009 14:17:28
Message: <4aa00837@news.povray.org>
|
|
|
| |
| |
|
|
Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> On Thu, 03 Sep 2009 18:02:46 +0200, Warp <war### [at] tagpovrayorg> wrote:
> > 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.
> One could argue that using "#version 3.6" should completely mimic the
> behaviour of v.3.6, but that does not mean v3.7 should behave the same by
> default.
I agree, but my point is that at least the current 3.7 beta doesn't fully
emulate 3.6 in the way it creates the PNG file. (It does work when rendering
to other image formats.)
> The whole point of using a gamma-aware image format is that you do not
> need to counter the gamma correction; it is handled correctly by default.
> The problems arise only when using gamma-unaware formats.
It can be a problem if rgb 0.5 does not write (127,127,127) to the file
but something else. The problem is that if you really need a linear
relationship between colors and pixel values, doing any kind of gamma
transformation is going to destroy some of that information.
In other words, if you were creating a linear gradient from left to right
on a 256-pixel wide image, what you want is
(0,0,0)(1,1,1)(2,2,2)(3,3,3)(4,4,4)(5,5,5)...(255,255,255)
to be written to the file. What you *don't* want is that after a gamma
correction and uncorrection process you end up having something like
(0,0,0)(2,2,2)(2,2,2)(3,3,3)(5,5,5)(5,5,5)...(255,255,255)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
From: clipka
Subject: Re: Same scene renders different in v3.7beta34 versus v3.62
Date: 3 Sep 2009 14:57:36
Message: <4aa011a0@news.povray.org>
|
|
|
| |
| |
|
|
Warp schrieb:
>> Which is exactly what you should get if you use a gamma-aware image
>> format, regardless of what you set File_Gamma to.
>
> No, because gamma correction will change the actual values of the
> pixels before they are used/displayed. Thus, for example, a pixel which
> in the image file has values <0.5, 0.5, 0.5> will be converted to
> <0.73, 0.73, 0.73> before being displayed on screen, for a gamma correction
> value of 2.2.
And here's where you're getting the gamma correction concept wrong:
With PNG (in the presence of a gAMA chunk), it is up to the /displaying/
software to apply a gamma correction, for the /sole/ purpose of showing
it on a system with an inherent display gamma.
Hence, if the image is used for anything other than immediate display
(i.e. writing it to the framebuffer of a graphics card), gamma
correction will /not/ be applied, and the image data is left in the
linear domain.
> However, when you are using an image to generate a heightfield, you are
> not *displaying* the pixels. It's actually not an image supposed to be
> shown on screen. It's just an image file being used to represent height
> values. (One could say that an image file is being "abused" for a different
> purpose than it was originally intended.) However. this is a very common
> technique because image files are both very common with a lot of support,
> and a practical way of storing height information.
>
> In this situation gamma correction makes no sense because the image file
> does not actually contain an image.
... which is exactly why in such a situation gamma correction will
indeed not be performed.
The trick here is that in contrast to older file formats, PNG contains
all information to reconstruct the original linear data, whether an
encoding gamma has been applied or not - which allows the /reading/
application to decide whether a gamma correciton is to be performed or not.
This is a stunt that older file formats cannot achieve.
There is /one/ use case though where it /might/ make sense to tamper
with output file gamma - and that is if the output file would be
intended to be used as a heightfield (or similar) in a program that does
/not/ use linear (= brightness) values, /nor/ the actual encoded pixel
values stored in the file, but rather categorically expects height to be
proportional to "framebuffer colors" [*] (which are /not/ linear, but
gamma pre-corrected for a typical display with a gamma of 2.2),
regardless of the image file format used.
[* i.e. the values typically ending up in the graphics hardware
framebuffer, on which not only the HTML colors are based, but also the
Windows color picker, and the values dispayed in most image editing tools.]
However, POV-Ray itself is not of this kind; furthermore, I would
consider such software broken, and recommend deliberately feeding it
input files in a format that is /not/ gamma-aware, so that the software
is not bothered with ambiguities about whether heights are properly
encoded based on brightness, "framebuffer colors", or whatever.
Note that with respect to use for height fields, the PNG file format
with a gAMA chunk is /always/ inherently ambiguous regarding the
representation if heights: The brightness will /never/ match the
"framebuffer colors" (except for values 0.0 and 1.0), and there is
nothing that POV-Ray could possibly do to avoid this mismatch: It's
rooted in the definition of the "framebuffer colors", which equal the
brightness values raised to the power of 1/gamma, to compensate for the
hardware gamma. So a PNG file that works for a program interpreting
height to be proportional to brightness will never work for a program
interpreting height to be proportional to "framebuffer colors".
With non-gamma-aware file formats, this ambiguity is more easily
resolved, as the values can mean just about /everything/, so chances are
a software interpreting the file as a height field will use the values
stored in the file, without paying a single thought about whether they
would normally denote brightness, "framebuffer colors" or
what-have-you-nots.
Post a reply to this message
|
|
| |
| |
|
|
From: clipka
Subject: Re: Same scene renders different in v3.7beta34 versus v3.62
Date: 3 Sep 2009 15:15:28
Message: <4aa015d0@news.povray.org>
|
|
|
| |
| |
|
|
Warp schrieb:
> 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.
No, the answer is "that depends on the software reading the heightfield".
> 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.
What you expect is a color of 0.5 being halfway between 0% height and
100% height of the height field - and that the absolute vertical
resolution is independent of the absolute height.
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.)
(b) A "framebuffer value" of 127? (That would appear to me the most
stupid way to handle PNG files for height fields, and leave you with a
problem indeed.)
(c) An encoded value of 127? (That would appear to me the most
/reasonable/ way to handle PNG files for height fields, and leave you
with the option of setting File_Gamma=1.0 to get the desired result,
even though you might not be aware that it would make a difference.)
Note that in cases (a) and (c) you'd be fine with File_Gamma=1.0, which
would also ensure a uniform vertical resolution across all heights.
In case (b) however you'd be better off with a different file format,
because such an encoding would run contrary to the way the PNG file
format tries to handle gamma.
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: Same scene renders different in v3.7beta34 versus v3.62
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 03 Sep 2009 21:34:11 +0200, Warp <war### [at] tagpovrayorg> wrote:
> 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.
Then specify a File_Gamma of 1.0.
> 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?
Every image must be adjusted for gamma, regardless of how it is displayed.
A height-field is really just another form of display; the linear response
means it has a gamma of 1.0.
Note that if you consistently use a gamma-aware format (like PNG), the
whole thing "just works". File_Gamma then only affects the distribution of
precision throughout the tonal range. Matching the gamma value of the
intended display means that one less gamma-adjustment is needed, thus
improving both precision and performance.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: Same scene renders different in v3.7beta34 versus v3.62
Date: 3 Sep 2009 16:47:43
Message: <4aa02b6f@news.povray.org>
|
|
|
| |
| |
|
|
Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> > 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?
> Every image must be adjusted for gamma, regardless of how it is displayed.
But that's the point. This is not an image. We are simply using an image
file format to store height data. We could just use some raw file format
for the same purpose. (Existing image formats are more useful because they
have more software support and are often compressed, conserving disk space.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 03 Sep 2009 22:47:43 +0200, Warp <war### [at] tagpovrayorg> wrote:
> Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
>> Every image must be adjusted for gamma, regardless of how it is
>> displayed.
>
> But that's the point. This is not an image. We are simply using an
> image file format to store height data. We could just use some raw
> file format for the same purpose. (Existing image formats are more
> useful because they have more software support and are often
> compressed, conserving disk space.)
Then use a File_Gamma of 1.0, thus specifying your intent to later
interpret the values linearly.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
From: clipka
Subject: Re: Same scene renders different in v3.7beta34 versus v3.62
Date: 3 Sep 2009 17:06:05
Message: <4aa02fbd@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|