Warp schrieb:
>   Btw, if I load a jpeg image as an image_map to an object with diffuse 0
> and ambient 1, the image will look way too bright and washed out, completely
> different than when I look at the image with any other program.
> 
>   If I write an "assumed_gamma 2.2" in the global_settings block, pov3.7
> will warn me, but now the image will look correct.
> 
>   So what is the *proper* way to tell pov3.7 how it should assume colors
> (eg. in image maps) to be gamma-corrected?

I just went back to this post, to find that I misunderstood.

Yes, POV-Ray /definitely/ has a problem with gamma of input files. PNG 
files with a gAMA chunk are allegedly safe, and HDR files as well from 
my experience (OpenEXR probably too), but just about everything else is 
currently bogus, due to POV-Ray not taking into account any color 
management metadata.

My suggestion would be to (A) fix the standard handling to respect at 
least standard color profiles, and (B) provide a means to override the 
assumed gamma pre-correction on a per-file basis.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> My suggestion would be to (A) fix the standard handling to respect at 
> least standard color profiles, and (B) provide a means to override the 
> assumed gamma pre-correction on a per-file basis.

  Also POV-Ray 3.7 displaying the image on screen with one gamma setting
(with Display_Gamma is set) and writing the file with a completely different
gamma setting is a problem.

  Btw, a Display_Gamma of 1.0 produces (on screen) an image which is
basically identical to what POV-Ray 3.6 produces, all image_maps look
correct, etc. Is there a reason why it cannot be the default?

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>   Also POV-Ray 3.7 displaying the image on screen with one gamma setting
> (with Display_Gamma is set) and writing the file with a completely different
> gamma setting is a problem.

It only is a problem if you set the Display_Gamma value wrong, or set 
the File_Gamma value to a nonstandard value with a file format not 
supporting embedded gamma information.

>   Btw, a Display_Gamma of 1.0 produces (on screen) an image which is
> basically identical to what POV-Ray 3.6 produces, all image_maps look
> correct, etc. Is there a reason why it cannot be the default?

Yes, there is: It's perfectly wrong for most systems.

Did you ever try it out with a scene to test your workflow for gamma issues?

Just set up a scene with a thin-horizontally striped (or, if you have an 
LCD display, checkered) black-and-white background and some rgb 0.5 
object for comparison, using ambient-only materials.

Such a scene /should/ look perfectly homogenous when you squint you 
eyes. If it doesn't, your workflow doesn't handle gamma properly.

(Similarly, the output of such a scene, used as input for another scene 
and heavily blurred by focal blur or anti-aliasing, should appear 
homogenous as well; this is where POV-Ray currently does a poor job.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >   Also POV-Ray 3.7 displaying the image on screen with one gamma setting
> > (with Display_Gamma is set) and writing the file with a completely different
> > gamma setting is a problem.

> It only is a problem if you set the Display_Gamma value wrong, or set 
> the File_Gamma value to a nonstandard value with a file format not 
> supporting embedded gamma information.

  It is a problem when POV-Ray ignores the File_Gamma setting, as seems to
be currently the case.

  Anyways, I don't really understand the reason to have a different gamma
setting for displaying the preview image on screen and another for writing
the image data to a file. If you specify different values, you will not get
what you see, but something different.

> >   Btw, a Display_Gamma of 1.0 produces (on screen) an image which is
> > basically identical to what POV-Ray 3.6 produces, all image_maps look
> > correct, etc. Is there a reason why it cannot be the default?

> Yes, there is: It's perfectly wrong for most systems.

  Then every single program out there which displays image is wrong, and
POV-Ray is the only program which is right?

  If I take a jpeg image and view it with Firefox, ImageMagick, The Gimp,
Konqueror or basically any software in existence which is able to read and
display jpeg images, they will all show the image in the same way. However,
if I use that same jpeg image as an image_map in POV-Ray 3.7 beta, using
default settings, eliminate all lighting effects and render an image like
that, the gamma setting for that jpeg image will be completely wrong: It
looks way too light and washed out. And not just a little, but quite
significantly. Basically the image is useless that way.

  However, when I tell POV-Ray to use a Display_Gamma of 1.0, then it will
start showing the image in the exact same way as all the other programs.

  If a Display_Gamma (and, I assume, File_Gamma when it's fixed) of 1.0
is not the proper way of fixing this problem, then please tell me what is.
Because as it is now, the default setting makes image_maps completely
unusable.

  If you don't believe me, I can show you examples.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>   It is a problem when POV-Ray ignores the File_Gamma setting, as seems to
> be currently the case.

No, it doesn't. It just affects file output in a way different from what 
you seem to expect.

>   Anyways, I don't really understand the reason to have a different gamma
> setting for displaying the preview image on screen and another for writing
> the image data to a file. If you specify different values, you will not get
> what you see, but something different.

Then don't do that.

But what if for instance your display has a gamma of 1.8, but you want 
to generate pictures to be displayed on the web with a targetted display 
gamma of 2.2?

>>>   Btw, a Display_Gamma of 1.0 produces (on screen) an image which is
>>> basically identical to what POV-Ray 3.6 produces, all image_maps look
>>> correct, etc. Is there a reason why it cannot be the default?
> 
>> Yes, there is: It's perfectly wrong for most systems.
> 
>   Then every single program out there which displays image is wrong, and
> POV-Ray is the only program which is right?

That's not what I said.

It's not an /output/ problem - it's an /input/ problem.

>   However, when I tell POV-Ray to use a Display_Gamma of 1.0, then it will
> start showing the image in the exact same way as all the other programs.

Even though this approach may /appear/ to be right at first glance, it 
is /not/, because you're then trying to apply POV-Ray's computations 
(which are designed to be done in linear color space) in the 
gamma-precorrected domain,

>   If a Display_Gamma (and, I assume, File_Gamma when it's fixed) of 1.0
> is not the proper way of fixing this problem, then please tell me what is.
> Because as it is now, the default setting makes image_maps completely
> unusable.

There are two answers to this:

(A) The correct /solution/ is to fix POV-Ray's input file gamma 
handling, which must currently be considered problematic at best.

(B) The correct /workaround/ until then is to convert your input files 
to a file format handled properly by POV-Ray; I got good results with 
using IC to convert JPEG files to PNG files (I'm told that IC adds a 
gAMA chunk, which POV-Ray can use to properly convert it to linear color 
space), and before that I used HDRShop to convert to HDR format.

And to repeat myself: No, File_Gamma is not broken and therefore needs 
no fixing. Output file gamma handling is right to all of my knowledge. 
(I'll stand corrected if you can provide a scene and settings 
unambiguously showing POV-Ray to mess up file output.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >   It is a problem when POV-Ray ignores the File_Gamma setting, as seems to
> > be currently the case.

> No, it doesn't. It just affects file output in a way different from what 
> you seem to expect.

  In fact, it seems that POV-Ray is not ignoring the File_Gamma setting,
as it apparently affects the pixels of the resulting PNG image. However,
it seems that the incorrect gamma metadata setting is written to the PNG
file so that when it's viewed with some program (which obeys that setting),
it looks different from what POV-Ray itself showed on screen (with
Display_Gamma being set to 1.0).

  If the gamma metadata is removed from the PNG file (eg. by converting it
to another format, ignoring that gamma setting), then it shows ok.

> It's not an /output/ problem - it's an /input/ problem.

  You didn't ask for the example, but I went ahead and created one anyways:

http://warp.povusers.org/pov_imagemap_test/

  Note that the page has a background color of #7F7F7F and the rendered
image a background color of 0.5.

  Please explain to me, once again, why the default output of POV-Ray 3.7
beta is the correct one and the others are incorrect.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>   In fact, it seems that POV-Ray is not ignoring the File_Gamma setting,
> as it apparently affects the pixels of the resulting PNG image. However,
> it seems that the incorrect gamma metadata setting is written to the PNG
> file so that when it's viewed with some program (which obeys that setting),
> it looks different from what POV-Ray itself showed on screen (with
> Display_Gamma being set to 1.0).

And that's *exactly* how it should work.

POV-Ray computes its scenes in linear color space. There is no ambiguity 
in the interpretation of the data until it is written to a file.

It is the job of the "Display_Gamma" setting to make sure that the 
linear color data is converted properly to /your/ display's color space 
for the sake of preview, so you can see what you get. It is /your/ job 
of course to set the Display_Gamma properly.

The job of the "File_Gamma" setting, on the other hand, depends on your 
output file format:

(1) If the file format is inherently ambiguous with respect to gamma, it 
is the job of the "File_Gamma" setting to make sure that the linear 
color data is converted properly to whatever the /next/ step in your 
workflow expects.

In this case it is /your/ job to determine your workflow's gamma 
requirements, and set "File_Gamma" accodingly. Note that this may or may 
not be the same as the Display_Gamma - in any case it's your 
responsibility to get it right, not POV-Ray's.

(2) If the file format is inherently unambiguous with respect to gamma 
(e.g. linear coding), the image /must/ be encoded in such a way that the 
linear color data computed by POV-Ray is preserved, e.g. that an output 
software properly handling the file format and properly tuned to the 
display hardware would render a 50% grey computed by POV-Ray indeed as a 
50% grey on the display.

(2a) If the file format is defined to use a fixed gamma for encoding 
(e.g. linear), then obviously this can only be achieved by ignoring the 
"File_Gamma" setting altogether, and using the prescribed file format gamma.

(2b) If the file format is defined to use a variable gamma for encoding, 
to be specified in the metadata, then it is the job of the "File_Gamma" 
setting to specify the gamma to use for encoding, but obviously this 
information must also be stored in the metadata. (This is what happens 
with PNG.)

Note however that in both cases (2a) and (2b), "File_Gamma" will 
obviously /not/ affect rendition of the output file, unless the display 
software fails to properly handle the file format.


Generally speaking, it is the job of the "File_Gamma" setting to specify 
the gamma to use in encoding of the pixel values, for file formats that 
do not prescribe a particular fixed gamma.

It is /not/ the job of either the "Display_Gamma" or "File_Gamma" 
settings to remedy artistic problems of the scene (e.g. it being overly 
bright or pale), technical flaws of legacy versions (e.g. them using no 
gamma correction by default), or technical issues of other parts of the 
software (e.g. input file gamma handling being bogus).


>   If the gamma metadata is removed from the PNG file (eg. by converting it
> to another format, ignoring that gamma setting), then it shows ok.

No, it does not. That's the definition of the metadata. If it looks 
crappy with the metadata, your scene is crappy.

>   You didn't ask for the example, but I went ahead and created one anyways:
> 
> http://warp.povusers.org/pov_imagemap_test/
> 
>   Note that the page has a background color of #7F7F7F and the rendered
> image a background color of 0.5.

Note that...

(1) HTML colors follow the tradition of specifying color values in a 
non-linear encoding subject to display gamma. #7F7F7F therefore does 
/not/ correspond to 50% of actual brightness, but to 50% of /voltage/ on 
the VGA connector, which on a typical 2.2 gamma display corresponds to a 
mere 22% of brightness. (Which in turn happens to roughly correspond to 
a grey /percieved/ to be halfway between black and white, but that's a 
different matter.)

(2) POV-Ray colors are genuine linear brightness values, so rgb 0.5 
/does/ correspond to a 50% of brightness. Which should obviously be 
brighter than 22% of brightness.

With these facts in mind, your experiment in fact proves POV-Ray /3.6.1/ 
output to be wrong (and Display_Gamma=1.0 preview of POV-Ray 3.7 as 
well, which comes as no surprise because your display will typically 
have a gamma of somewhere beteen 1.8 to 2.4).

The only other thing it shows is that the /combination/ of input and 
output gamma transformations are correct for both 3.6.1 as well as 3.7 
with Display_Gamma=1.0, but wrong for 3.7 with defaults. Now given that 
output gamma handling is obviously right for 3.7 defaults, but wrong for 
the others, it follows that input gamma handling must be broken for all 
three of them.

>   Please explain to me, once again, why the default output of POV-Ray 3.7
> beta is the correct one and the others are incorrect.

Done.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >   In fact, it seems that POV-Ray is not ignoring the File_Gamma setting,
> > as it apparently affects the pixels of the resulting PNG image. However,
> > it seems that the incorrect gamma metadata setting is written to the PNG
> > file so that when it's viewed with some program (which obeys that setting),
> > it looks different from what POV-Ray itself showed on screen (with
> > Display_Gamma being set to 1.0).

> And that's *exactly* how it should work.

  No, it isn't, because as far as I can tell, there's no way of specifying
what the gamma metadata value should be, and the image ends up wrong. It
doesn't correspond to the original image map, nor to what povray showed on
screen.

  How is doing something I *don't want* it to do "how it should work"?

> >   If the gamma metadata is removed from the PNG file (eg. by converting it
> > to another format, ignoring that gamma setting), then it shows ok.

> No, it does not. That's the definition of the metadata. If it looks 
> crappy with the metadata, your scene is crappy.

  Then tell me exactly how do I get the correct pixel values and metadata
so that the image map will look in the rendered image in the same way as
the original jpeg image.

> (1) HTML colors follow the tradition of specifying color values in a 
> non-linear encoding subject to display gamma. #7F7F7F therefore does 
> /not/ correspond to 50% of actual brightness, but to 50% of /voltage/ on 
> the VGA connector, which on a typical 2.2 gamma display corresponds to a 
> mere 22% of brightness. (Which in turn happens to roughly correspond to 
> a grey /percieved/ to be halfway between black and white, but that's a 
> different matter.)

  And exactly how is this useful to me? If I specify 7F as the brightness
of the background in HTML and 0.5 as the brightness of the background in
POV-Ray, the most useful thing for me is for those two values to match
each other. One being significantly brighter than the other is completely
useless for me.

  If I want to tell POV-Ray "I want (127, 127, 127) as the pixel for the
background, don't gamma-correct them", exactly how do I do that?

> (2) POV-Ray colors are genuine linear brightness values, so rgb 0.5 
> /does/ correspond to a 50% of brightness. Which should obviously be 
> brighter than 22% of brightness.

  Just to prove you wrong, I remade the web page:
http://warp.povusers.org/pov_imagemap_test/index.html

  Now the lower half of the rendered images is a checkerboard pattern of
alternating black and white pixels.

  Granted, the perceived brightness of this checkerboard pattern does not
match the 0.5 grey of the POV-Ray 3.6 image. However, neither does it match
the one rendered with POV-Ray 3.7. In fact, the latter deviates *more* from
that perceived brightness than the former. It's way too bright. At least on
my screen.

> With these facts in mind, your experiment in fact proves POV-Ray /3.6.1/ 
> output to be wrong (and Display_Gamma=1.0 preview of POV-Ray 3.7 as 
> well, which comes as no surprise because your display will typically 
> have a gamma of somewhere beteen 1.8 to 2.4).

  Please explain to me, once again, how a background which is way too
bright (even compared to a black/white checkerboard pattern), and especially
the *image map* being way too bright, is the correct behavior.

  Also explain to me how I would go matching HTML colors with POV-Ray
colors. As it is now, even if I do specify File_Gamma=1.0, POV-Ray 3.7
will nevertheless write a gamma metadata which will make the PNG to render
way too brightly. There's no way of matching the HTML colors nor the
original image map than to deliberately go and remove the gamma metadata
from the PNG file.

> Now given that 
> output gamma handling is obviously right for 3.7 defaults

  I have to disagree. "rgb 0.5" in 3.7 (with default settings) does *not*
match the half-brightness of a black/white checkerboard pattern.

  Granted, neither does the one in 3.6, but at least with 3.6 I get to
match colors with every other program in existence.

> >   Please explain to me, once again, why the default output of POV-Ray 3.7
> > beta is the correct one and the others are incorrect.

> Done.

  You didn't actually explain anything. You basically just said "it's
correct because I say so", without any true explanation. You even claimed
how my example images actually demonstrate that 3.7 is doing the right
thing, while to me it's glaringly obvious that this isn't so.

  I find it completely counter-productive to have to go and manually remove
the wrong gamma metadata in the PNG file produced by POV-Ray 3.7 if I want
it to match eg. HTML colors and the colors of image maps, even if I had
specified a File_Gamma of 1.0

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   Just to prove you wrong, I remade the web page:
> http://warp.povusers.org/pov_imagemap_test/index.html

  I also added two images showing 16 different shades of grey, at regular
rgb intervals. The first one is rendered with 3.6, the second with 3.7.

  I don't know about you, but at least in my system the first one looks a
lot more evenly distributed than the second one, which looks way too biased
towards the bright shades.

-- 
                                                          - Warp

Post a reply to this message

> Warp <war### [at] tagpovrayorg> wrote:
>>   Just to prove you wrong, I remade the web page:
>> http://warp.povusers.org/pov_imagemap_test/index.html
> 
>   I also added two images showing 16 different shades of grey, at regular
> rgb intervals. The first one is rendered with 3.6, the second with 3.7.
> 
>   I don't know about you, but at least in my system the first one looks a
> lot more evenly distributed than the second one, which looks way too biased
> towards the bright shades.
> 

On my system:
The top strip show almost no difference fot the first 5 shades, and to 
much contrast between the last 5.
The bottom strip do have a nice and regular gradient, with almost 
constant contrast.


Alain

Post a reply to this message