Hi all,

I rendered a very simple scene in both v3.62 and v3.7beta34:

camera{location <0,2,-2> look_at <0,0,0>}
light_source {<0,2,-2> color 1}
sphere{0,1 pigment{rgb<1,0,0>}}

If you render this scene in both versions, then it looks as if the sphere has
"flattened" in the new version.
Have certain default settings changed? Any ideas?

Thanks!
Cheers,
Frank

Post a reply to this message

On Sat, 22 Aug 2009 10:21:58 EDT, "Frank_C" <fra### [at] skynetbe> wrote:

>If you render this scene in both versions, then it looks as if the sphere has
>"flattened" in the new version.

Sorry but the only differences that I get in pigment which disappears when
adding  global_settings { assumed_gamma 1 } to the v3.62 scene.
-- 

Regards
     Stephen

Post a reply to this message

Stephen schrieb:
> On Sat, 22 Aug 2009 10:21:58 EDT, "Frank_C" <fra### [at] skynetbe> wrote:
> 
>> If you render this scene in both versions, then it looks as if the sphere has
>> "flattened" in the new version.
> 
> Sorry but the only differences that I get in pigment which disappears when
> adding  global_settings { assumed_gamma 1 } to the v3.62 scene.

Same here.

Frank, are you sure you used the same resolution with both renders?

Post a reply to this message

Stephen <mcavoysAT@aoldotcom> wrote:
> Sorry but the only differences that I get in pigment which disappears when
> adding  global_settings { assumed_gamma 1 } to the v3.62 scene.

  Btw, could someone explain, once again, why the default gamma settings
of povray 3.7 are different from the defaults in 3.6, making all scenes
without explicit gamma settings render differently? I never quite got the
reason for this.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>   Btw, could someone explain, once again, why the default gamma settings
> of povray 3.7 are different from the defaults in 3.6, making all scenes
> without explicit gamma settings render differently? I never quite got the
> reason for this.

Maybe because they actually /do/ render identically, provided you 
specify "#version 3.6" to enforce backward compatibility?

Things only get complicated when you explicitly use a flexible-gamma 
file format (such as .png or .hdr). Having these render identically as 
well would probably require different "#version 3.6" defaults for the 
parameters of 3.7's gamma-handling mechanism. Or a nasty hack of that 
mechanism.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >   Btw, could someone explain, once again, why the default gamma settings
> > of povray 3.7 are different from the defaults in 3.6, making all scenes
> > without explicit gamma settings render differently? I never quite got the
> > reason for this.

> Maybe because they actually /do/ render identically, provided you 
> specify "#version 3.6" to enforce backward compatibility?

  That didn't really answer my question.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>> Maybe because they actually /do/ render identically, provided you 
>> specify "#version 3.6" to enforce backward compatibility?
> 
>   That didn't really answer my question.

Of course it didn't - if the question is based on false observations and 
therefore moot, what point would there be in answering it?

That is, unless you are asking why the behavior is different when a 
#version statement is /not/ present. But in that case, there's no reason 
to favor compatibility over correctness: 3.6 default gamma handling was 
simply wrong (because it wasn't any gamma handling at all, thereby 
producing linear output where other software commonly expects 
gamma-precorrected files).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Stephen schrieb:
> > On Sat, 22 Aug 2009 10:21:58 EDT, "Frank_C" <fra### [at] skynetbe> wrote:
> >
> >> If you render this scene in both versions, then it looks as if the sphere has
> >> "flattened" in the new version.
> >
> > Sorry but the only differences that I get in pigment which disappears when
> > adding  global_settings { assumed_gamma 1 } to the v3.62 scene.
>
> Same here.
>
> Frank, are you sure you used the same resolution with both renders?


Hi!
I used indeed the same resolution settings for both renderings.
As Stephen indicated, the assumed_gamma keyword made both renders equal. However
I added an {assumed_gamma 2.2} in POV3.7 instead of an {assumed_gamma 1} in
POV3.62. This is because -on my PC- the latter setting had the effect of
"flattening" the sphere (or any other object).
Kind regards
Frank

Post a reply to this message

Frank_C schrieb:
> I used indeed the same resolution settings for both renderings.
> As Stephen indicated, the assumed_gamma keyword made both renders equal. However
> I added an {assumed_gamma 2.2} in POV3.7 instead of an {assumed_gamma 1} in
> POV3.62. This is because -on my PC- the latter setting had the effect of
> "flattening" the sphere (or any other object).

Ah, I see! I thought you meant geometric "flattening", but you're 
talking about colors.

Yes, gamma handling is significantly different between 3.6 and 3.7, and 
does lead to differences in color "intensity".

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Frank_C schrieb:
> > I used indeed the same resolution settings for both renderings.
> > As Stephen indicated, the assumed_gamma keyword made both renders equal. However
> > I added an {assumed_gamma 2.2} in POV3.7 instead of an {assumed_gamma 1} in
> > POV3.62. This is because -on my PC- the latter setting had the effect of
> > "flattening" the sphere (or any other object).
>
> Ah, I see! I thought you meant geometric "flattening", but you're
> talking about colors.
>
> Yes, gamma handling is significantly different between 3.6 and 3.7, and
> does lead to differences in color "intensity".

Just for the completeness, here's a comparison between the two spheres.
The sphere on the left was created with version 3.6 and the sphere on the right
was rendered in version 3.7. I didn't use the assumed_gamma keyword here.

http://img41.imageshack.us/img41/5444/testgjc.png

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >> Maybe because they actually /do/ render identically, provided you 
> >> specify "#version 3.6" to enforce backward compatibility?
> > 
> >   That didn't really answer my question.

> Of course it didn't - if the question is based on false observations and 
> therefore moot, what point would there be in answering it?

  How is it a false observation that I take a scene, render it in 3.6 and
3.7, and I get results which only differ in their gamma setting, and they
do so rather radically?

  Obviously the default gamma settings are different. What has never been
obvious to me is the reason for this.

> That is, unless you are asking why the behavior is different when a 
> #version statement is /not/ present. But in that case, there's no reason 
> to favor compatibility over correctness: 3.6 default gamma handling was 
> simply wrong (because it wasn't any gamma handling at all, thereby 
> producing linear output where other software commonly expects 
> gamma-precorrected files).

  Could you be more precise about this? I still don't understand the reason.
Maybe some concrete examples?

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>   Could you be more precise about this? I still don't understand the reason.
> Maybe some concrete examples?

Take any scene with (A) an object with a small-scale black-and-white 
checker pattern (if you're using a CRT display, use a large scale 
horizontally), and (B) some rgb 0.5 object. Render without AA.

Now if you render the whole smash and squint your eyes, you /should/ see 
just plain 50% grey for both objects.

Indeed the black-and-white object (A) /will/ look 50% grey (unless your 
display's black and/or white point are bogus), because POV-Ray will have 
output the perfectly unambiguous values 0 and 255 representing 0% and 
100% intensity respectively, in a 1:1 mix, and averaged no earlier than 
when passing between your eyelids.

In 3.6, however, the rgb 0.5 object (B) will look way darker: POV-Ray 
will have output "127", but your graphics card + display will interpret 
this as a meager 22% grey (0.5^2.2 - provided your display has indeed a 
gamma of 2.2).

3.7, on the other hand, will output "186" (255 * 0.5^(1/2.2)) for rgb 
0.5, which is just the right value for a 2.2-gamma display system to 
show 50% grey ((186/255)^2.2); even if your display gamma is somewhat 
off, like 2.0 or so, it will still be closer to the right thing than the 
3.6 output.

(Or, alternatively, POV-Ray will output "127", but store information in 
the output file that a display gamma of 1.0 has been assumed, leaving it 
  to the image viewer to perform gamma-correction; this will happen for 
instance if you choose PNG output and set File_Gamma=1.0.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> In 3.6, however, the rgb 0.5 object (B) will look way darker: POV-Ray 
> will have output "127"

  You mean that POV-Ray 3.6 didn't gamma-correct the output at all, while
POV-Ray 3.7 now does?

  Does that mean there's now a new option to set the gamma correction of
the created image (the actual pixels, not just some header data in the
image file format)? Is there a way to turn this off, if one so desires
(eg. if you really *want* the pixels to be exactly (127,127,127) and
nothing else)?

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
> clipka <ano### [at] anonymousorg> wrote:
>> In 3.6, however, the rgb 0.5 object (B) will look way darker: POV-Ray 
>> will have output "127"
> 
>   You mean that POV-Ray 3.6 didn't gamma-correct the output at all, while
> POV-Ray 3.7 now does?

I mean that 3.6 didn't do it /by default/ (which is what you've been 
asking about all the time).

>   Does that mean there's now a new option to set the gamma correction of
> the created image (the actual pixels, not just some header data in the
> image file format)? Is there a way to turn this off, if one so desires
> (eg. if you really *want* the pixels to be exactly (127,127,127) and
> nothing else)?

Yup. "File_Gamma" is the magic ini file option. Set it to 1.0 and you'll 
get linear pixel values, plus (for PNG and HDR) a header saying that the 
data is linear. Set it to 2.2 and you'll get gamma pre-corrected pixel 
values, plus a header saying that the data is pre-corrected for a gamma 
of 2.2. (The latter is highly recommended though, as not all viewers - 
browsers included - support linear image data.)

Note that this makes it impossible to deliberately mess with gamma for 
artistic effect in POV-Ray when you use PNG output and all your image 
processing software handles gAMA chunks properly: You can only affect 
the encoding of pixels - and thereby the dynamic ranges of highlights 
vs. shadows - but not their interpretation.

At least that's the theory as known to me. I never tested in detail 
whether it indeed works exactly as intended.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> > clipka <ano### [at] anonymousorg> wrote:
> >> In 3.6, however, the rgb 0.5 object (B) will look way darker: POV-Ray 
> >> will have output "127"
> > 
> >   You mean that POV-Ray 3.6 didn't gamma-correct the output at all, while
> > POV-Ray 3.7 now does?

> I mean that 3.6 didn't do it /by default/ (which is what you've been 
> asking about all the time).

> >   Does that mean there's now a new option to set the gamma correction of
> > the created image (the actual pixels, not just some header data in the
> > image file format)? Is there a way to turn this off, if one so desires
> > (eg. if you really *want* the pixels to be exactly (127,127,127) and
> > nothing else)?

> Yup. "File_Gamma" is the magic ini file option. Set it to 1.0 and you'll 
> get linear pixel values, plus (for PNG and HDR) a header saying that the 
> data is linear. Set it to 2.2 and you'll get gamma pre-corrected pixel 
> values, plus a header saying that the data is pre-corrected for a gamma 
> of 2.2. (The latter is highly recommended though, as not all viewers - 
> browsers included - support linear image data.)

> Note that this makes it impossible to deliberately mess with gamma for 
> artistic effect in POV-Ray when you use PNG output and all your image 
> processing software handles gAMA chunks properly: You can only affect 
> the encoding of pixels - and thereby the dynamic ranges of highlights 
> vs. shadows - but not their interpretation.

> At least that's the theory as known to me. I never tested in detail 
> whether it indeed works exactly as intended.

  Well, this clears things up a bit. I'm still not 100% happy that old
scenes will render differently by default, but I suppose it's an acceptable
change.

  I highly recommend writing a concise and clear explanation of this in the
"what's new in POV-Ray 3.7" section when the final version is published.
Else it's only going to cause a lot of confusion.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>   Well, this clears things up a bit. I'm still not 100% happy that old
> scenes will render differently by default, but I suppose it's an acceptable
> change.

/That/, as I mentioned as well, is only the case if they don't have a 
"#version" directive, or when you're rendering to a "gamma-aware" file 
format.

>   I highly recommend writing a concise and clear explanation of this in the
> "what's new in POV-Ray 3.7" section when the final version is published.
> Else it's only going to cause a lot of confusion.

Boy, how /I/ long for a concise and clear explanation of gamma! Output 
gamma is only the tip of the iceberg.

Try feeding POV-Ray output into POV-Ray again as a texture image - 
that's where things appear to get /really/ hairy!

Post a reply to this message

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?

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   So what is the *proper* way to tell pov3.7 how it should assume colors
> (eg. in image maps) to be gamma-corrected?

  Btw, if I put "Display_Gamma=1.0" in povray.ini, then the *display* shows
the proper gamma. However, the generated png file has the wrong gamma.

  I thought that I could fix that by adding "File_Gamma=1.0", but that had
no effect on anything. Neither does "File_Gamma=2.2" or anything else.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>   Btw, if I put "Display_Gamma=1.0" in povray.ini, then the *display* shows
> the proper gamma. However, the generated png file has the wrong gamma.
> 
>   I thought that I could fix that by adding "File_Gamma=1.0", but that had
> no effect on anything. Neither does "File_Gamma=2.2" or anything else.

Apparently POV-Ray fails to properly read the gamma information from its 
own generated PNG files. There has been some discusson about this in thread:
news://news.povray.org:119/web.4a398f2555c7683545339cfa0@news.povray.org

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Apparently POV-Ray fails to properly read the gamma information from its 
> own generated PNG files.

  In this case it's not a problem of POV-Ray itself reading its own PNG files.
It's a problem of POV-Ray always creating image files with the same (and to
my understanding wrong) gamma value, regardless of what the File_Gamma ini
setting is.

-- 
                                                          - Warp

Post a reply to this message

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 a écrit :
> 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

clipka wrote:

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

I need to run my colorimeter on my display again, but the 3.6 grayscale 
looks better than the 3.7 grayscale on my screen. The 3.7 grayscale does 
look too bright to me. I'll have to make sure my display at home is 
calibrated to see how it looks...

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

See? this is the whole problem with gamma correction, if everyone 
doesn't have a properly calibrated screen, and doesn't properly embed a 
color profile in the image, or the viewing app does not handle the 
embedded profile correctly, then you get all sorts of different results.

-- 
~Mike

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> 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.

  You are seriously claiming that my display is way, way too bright.
That really makes me laugh out loud.

  If anything, my display is too dark. Often images posted by people in
p.b.images look almost black. When I complain about it, others say they
can see it just fine.

  Now you are telling me that I have to calibrate my monitor to be something
like 25% darker than it already is. Everything in the darker 20% or so
darkest color space would become completely black and invisible.

  Are you also seriously claiming that the starfield image in the pov3.7
rendered image looks just fine? Does that mean that the original looks like
a black square with some tiny white pixels here and there in your monitor?

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

  I don't appreciate your condescending tone of voice. I'm trying to discuss
about an issue here.

> 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);

  I don't get it. The image POV-Ray 3.7 is producing by default is way too
bright, and you want me to brighten the colors even further? (For example
rgb 0.1 becomes rgb 0.35, rgb 0.5 becomes rgb 0.73.)

  Yeah, that will look marvelous. After your UnGamma converts the original
rgb 0.1 to rgb 0.35, POV-Ray will render the image with a further gamma
correction, making the final pixel have an rgb of 0.62. That will really
fix all problems.

-- 
                                                          - Warp

Post a reply to this message

Mike Raiford schrieb:
> See? this is the whole problem with gamma correction, if everyone 
> doesn't have a properly calibrated screen, and doesn't properly embed a 
> color profile in the image, or the viewing app does not handle the 
> embedded profile correctly, then you get all sorts of different results.

So, what's the alternative?

Note that working with linear colors is not a solution: Things being as 
they are, it just adds to the many nonstandard display gammas (1.0 in 
this case), opens up more cans of worms than going for the standard 
gamma of whatever OS you happen to be using (which would be 2.2 for 
Windows), and is therefore prone to being part of the problem instead.

Post a reply to this message

clipka wrote:
> 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.

Last time I tried to "calibrate my display" to show gamma correctly (that
is, to show 0.5 and {0.0, 1.0} checkerboard the same), *everything* looked
too washed out, not only pictures but mainly GUI elements.

Post a reply to this message

clipka wrote:
> Mike Raiford schrieb:
>> See? this is the whole problem with gamma correction, if everyone 
>> doesn't have a properly calibrated screen, and doesn't properly embed 
>> a color profile in the image, or the viewing app does not handle the 
>> embedded profile correctly, then you get all sorts of different results.
> 
> So, what's the alternative?

How do other applications deal with color?

Embed the sRGB profile with 2.2 gamma, perhaps, would be an alternative. 
Just make sure the image is displaying as intended in the sRGB space, 
with an app that properly handles color correction.

> Note that working with linear colors is not a solution: Things being as 
> they are, it just adds to the many nonstandard display gammas (1.0 in 
> this case), opens up more cans of worms than going for the standard 
> gamma of whatever OS you happen to be using (which would be 2.2 for 
> Windows), and is therefore prone to being part of the problem instead.

Agreed. Like I stated, the whole thing is a terrible mess. I think 
there's some transform to the color values from the renderer output to 
the color space (As suggested above) that would be needed in order to 
get a proper image. Then, it simply isn't just gamma, but also how the 
red, green, and blue values relate to each other. Getting color 
management right is a freaking mess.

I could suggest render linearly, create a color profile for that, load 
the image in PS, convert to the sRGB profile, the save as a JPEG or PNG, 
but that would be a major PITA ;)

Note that I suggest sRGB here, because it's the profile that should be 
"right" for the majority of the web users. Most computer equipment these 
days operates in that color space.

-- 
~Mike

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   Now the lower half of the rendered images is a checkerboard pattern of
> alternating black and white pixels.

  There was a warning somewhere that a checkerboard patter should *not* be
used for this kind of test because it doesn't work properly with CRT monitors.
Instead, alternating horizontal lines should be used instead.

  I changed the images to use horizontal lines. Now the POV-Ray 3.7 image
background looks equal in brightness, while there's a remarkable difference
in the POV-Ray 3.6 image.

  It was not, after all, a problem with my monitor gamma. It was a problem
with the test being skewed by how CRT works.

  So yes: I now see how the gamma correction of 2.2 changes the rgb 0.5 to
a shade which closely matches half brightness emulated with alternating
black and white lines. (The gray stripe at the bottom still looks to me
like biased too bright, but maybe it's a question of getting used to it.)

  There's still the problem of the image map incorrectly brightening, though.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> (The gray stripe at the bottom still looks to me
> like biased too bright, but maybe it's a question of getting used to it.)

  Btw, I asked a friend in IRC (completely without any kind of leading),
and he too thought that the bottom stripe was too biased towards the bright
side. I don't know what causes this perception.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>   You are seriously claiming that my display is way, way too bright.
> That really makes me laugh out loud.

Do so if that makes you feel any better.

All I see from my side is that it looks perfect, and I'm quite confident 
that my display calibration goes beautifully well with my operating 
system as well as my image viewing and manipulation software.

>   If anything, my display is too dark. Often images posted by people in
> p.b.images look almost black. When I complain about it, others say they
> can see it just fine.
> 
>   Now you are telling me that I have to calibrate my monitor to be something
> like 25% darker than it already is. Everything in the darker 20% or so
> darkest color space would become completely black and invisible.

Calibration isn't just about turning a monitor brighter or darker. It's 
about adjusting (A) the black point, (B) the white point, (C) the gamma, 
and if your display is particularly bad or you need particularly good 
calibration, even (D) the exact display curve for the individual color 
components.

I don't know what's wrong with your display. Go check it out, use the 
display adjustment tools that came with your graphics card, or google 
for some tools on the net, or whatever. But stop griping about POV-Ray 
being wrong when really you got your image viewing pipeline gamma 
crapped up.

>   Are you also seriously claiming that the starfield image in the pov3.7
> rendered image looks just fine? Does that mean that the original looks like
> a black square with some tiny white pixels here and there in your monitor?

No, I'm not claiming that. You may have noticed that I already mentioned 
that the /input/ file gamma of POV-Ray (both 3.6 and 3.7) is bogus at 
least for some file formats (JPEG is among those). That's where /that/ 
comes from

>> So stop your griping, disengage "demand mode", calibrate your image 
>> viewing pipeline properly, and /then/ come back with any residual problems.
> 
>   I don't appreciate your condescending tone of voice. I'm trying to discuss
> about an issue here.

If you were trying to discuss, then you should be less demaning. All I 
hear is "Please explain this again, please tell me that, please give me 
advice about yonder thing", and griping about me allegedly not 
explaining anything, which I'm trying my best to do though.

>> 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);
> 
>   I don't get it. The image POV-Ray 3.7 is producing by default is way too
> bright, and you want me to brighten the colors even further? (For example
> rgb 0.1 becomes rgb 0.35, rgb 0.5 becomes rgb 0.73.)

Maybe I just got the math wrong way round, huh? Now STFU and do some 
thinking for yourself. If you understand enough about gamma to be so 
sure that POV-Ray 3.7 does it wrong, then you shouldn't have any 
difficulties to figure out how to straighten up the math and turn that 
macro into something useful. I owe you no support on this one, as I'm 
not even remotely responsible for you being unhappy with POV-Ray's gamma 
handling. If you honestly request information and have any hope of me 
being able to provide it, please switch into a different mode showing at 
least a /bit/ of appreciation for me taking time to answer, and a /bit/ 
of willingness to listen and understand, or otherwise don't bother to 
continue asking me about it if you deem my answers worthless.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Maybe I just got the math wrong way round, huh? Now STFU and do some 
> thinking for yourself. If you understand enough about gamma to be so 
> sure that POV-Ray 3.7 does it wrong, then you shouldn't have any 
> difficulties to figure out how to straighten up the math and turn that 
> macro into something useful.

  I find it a bit hypocritical for you to criticize me and tell me to shut
the fuck up when even you can't get the math right.

  Normally criticizing how someone is wrong, correcting them, and then
making yourself a blunder in the precise subject you are lecturing about
should be a lesson in humility, but I assume that would be too much to hope.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   So yes: I now see how the gamma correction of 2.2 changes the rgb 0.5 to
> a shade which closely matches half brightness emulated with alternating
> black and white lines.

  (Btw, IMO there still should be a way of telling POV-Ray to not gamma
correct anything if that's what the user wishes. Currently it seems to
be difficult, as POV-Ray seems to be writing a gamma value of 2.2 to the
output PNG file regardless of what File_Gamma is. I don't even understand
where it's getting that 2.2 value from.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>>   Now the lower half of the rendered images is a checkerboard pattern of
>> alternating black and white pixels.
> 
>   There was a warning somewhere that a checkerboard patter should *not* be
> used for this kind of test because it doesn't work properly with CRT
> monitors. Instead, alternating horizontal lines should be used instead.

I have an LCD monitor, and the checkerboard looked *green*. Quite strange.

Now with the horizontal stripes. POV3.6 looks too dark and POV3.7 looks too
light.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Now with the horizontal stripes. POV3.6 looks too dark and POV3.7 looks too
> light.

  As I already wrote, now that I'm using the proper test (at least for CRT
monitors, which is what I have), I must admit that the 3.7 image background
looks very even with my monitor. I suppose that my monitor does indeed
require a gamma correction of almost exactly 2.2 for proper brightness,
and that my system settings were correct to begin with.

  On the other hand, I'm wondering how precise this test really is.
Bright white lines stand out a lot more than black lines, and the brighter
the white lines are, the more they tend to glow to the human eye. A bit
like color bleeding. This would mean that if your monitor is set very
bright, then the white lines will overwhelm the black ones, requiring
a different gamma correction value than if your monitor was set to a
very dim setting, in which case the white lines won't stand out that much
compared to the black lines.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> This would mean that if your monitor is set very
> bright, then the white lines will overwhelm the black ones, requiring
> a different gamma correction value 

Isn't this kind of the point, tho? Unless you turn up both the black level 
and the white level in a controlled way, I'd think increasing the brightness 
of one or the other is going to mean you have to correct your images 
differently for them to "look right".

-- 
   Darren New, San Diego CA, USA (PST)
   Understanding the structure of the universe
    via religion is like understanding the
     structure of computers via Tron.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > This would mean that if your monitor is set very
> > bright, then the white lines will overwhelm the black ones, requiring
> > a different gamma correction value 

> Isn't this kind of the point, tho? Unless you turn up both the black level 
> and the white level in a controlled way, I'd think increasing the brightness 
> of one or the other is going to mean you have to correct your images 
> differently for them to "look right".

  What I meant is that, at least it seems to me, this phenomenon would be
exclusive to this precise test (in other words, alternating black/white
horizontal lines) and might not correspond to what is intended to be a
"50% gray" in an image would really look like on your monitor.

  Or if I try to express myself more clearly: Could it be that this
precise test (the horizontal lines) gives you the wrong impression of
what the proper gamma setting for your monitor would really be, this
visual impression being biased by the brightness setting of the monitor?

  If you used a completely different test, eg. physical pieces of paper
colored appropriately, would you end up with the same gamma setting?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   What I meant is that, at least it seems to me, this phenomenon would be
> exclusive to this precise test 

I see. That makes more sense, yes.

-- 
   Darren New, San Diego CA, USA (PST)
   Understanding the structure of the universe
    via religion is like understanding the
     structure of computers via Tron.

Post a reply to this message

Warp schrieb:
>   I find it a bit hypocritical for you to criticize me and tell me to shut
> the fuck up when even you can't get the math right.

That's what happens when one gets annoyed by the other one not 
listening, alleging that one is "explaining nothing at all", and being 
extraordinarily demanding: It drastically reduces the motivation to 
invest time into it.

Besides it would be more humiliating for me if I didn't know already 
that I keep getting the exponent wrong way round.

Post a reply to this message