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

Alain <aze### [at] qwertyorg> wrote:
> The top strip show almost no difference fot the first 5 shades, and to 
> much contrast between the last 5.

  Your monitor is probably calibrated to be really, really dark.

  Sometimes people post really dark images in p.b.images and I have hard
time distinguishing anything in those images, even though others say that
they can see it just fine. That's probably because my monitor is calibrated
to be a bit too dark. I assume with your monitor you would only see black
and nothing else.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:

> http://warp.povusers.org/pov_imagemap_test/index.html

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

The 3.7 shot looks /perfect/ on my display, no matter whether I display 
it in Internet Explorer, Windows Explorer preview, or Photoshop 6.0. 
Given that I did invest some time into calibrating my primary display, 
this tells me that yours/ must be /way/ off.

Now, that isn't generally a problem: You can work with a display system 
gamma of 1.0 if you like. But in that case make sure your image viewing 
software supports non-standard display gammas, and is actually 
configured to do so.

So stop your griping, disengage "demand mode", calibrate your image 
viewing pipeline properly, and /then/ come back with any residual problems.


As for entering gamma-pre-corrected colors into POV-Ray, you might use 
something like this:

   #macro UnGamma(C)
     #local G = 1/2.2;
     <pow(C.red,G),pow(C.green,G),pow(C.blue,G),C.filter,C.transmit>
   #end

   #declare MyGrey = UnGamma(rgb <127,127,127>/255);


Now go and do your homework please.

Post a reply to this message

Warp schrieb:
>   Sometimes people post really dark images in p.b.images and I have hard
> time distinguishing anything in those images, even though others say that
> they can see it just fine. That's probably because my monitor is calibrated
> to be a bit too dark.

Your image viewing pipeline must be really, really badly calibrated; 
from the shots you put on the 'net, I would instead expect you to 
experience most images as way too bright.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >   Sometimes people post really dark images in p.b.images and I have hard
> > time distinguishing anything in those images, even though others say that
> > they can see it just fine. That's probably because my monitor is calibrated
> > to be a bit too dark.

> Your image viewing pipeline must be really, really badly calibrated; 
> from the shots you put on the 'net, I would instead expect you to 
> experience most images as way too bright.

  My experience is the exact opposite: Often images which others report are
fine (even if a bit dark) look almost completely black in my monitor.

  Search my posts in p.b.images about this subject if you like.

-- 
                                                          - Warp

Post a reply to this message