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