I use POV for graphics work, so I often rely on it to match rgb values
irrespective of lighting conditions. For example, in 3.6 a 50% gray with no
light source and ambient 1 is always accurately rendered as RGB 128, 128, 128,
as long as Display_Gamma in povray.ini is the same as assumed_gamma in
global_settings or if no assumed_gamma is declared. This is true of image-mapped
pigments or declared colors.

In 3.7, however, with the suggested Display_Gamma and File_Gamma set to 2.2, a
50% gray (rgb 0.5) with no light source and ambient 1 comes out as RGB
186,186,186 or a gray of about 0.73, much lighter. This does not make sense to
me. I would expect that if ambient is set to 1 with nothing else affecting the
color, that the rendered output would match the value called for.

This can be corrected. I know, by modifying the pigment with "gamma 2.2" but
shouldn't this be done internally? What a pain! With Display_Gamma and
File_Gamma set to 1 and no pigment gamma correction, however, gray 50 comes out
gray 50. But this doesn't seem to be the accepted wisdom nor does it match the
gamma of my system. The gAMA chunk in the PNG is written as 1.00 rather than the
usual 0.45454.

There is also a discrepancy in the beta between declared color values and color
values taken from image maps. With Display_Gamma & File_Gamma = 2.2 and no color
correction, an image map of RGB 128 comes out as RGB 128, as expected, but a
square box with pigment {rgb 0.5} finish {ambient 1} comes out as RGB 186.

What am I missing here? I've read the relevant posts and wikis and do not really
want to get into the debate over what's "realistic" versus what "looks good" but
I'm having considerable trouble converting all the years of pigments and
textures and materials into something close to what they were originally meant
to look like. Running everything as #version 3.6 doesn't really seem feasible
and without some simple conversion solution there's a lot of experimentation and
techniques that will be broken.

(Using Window 7 64-bit with Photoshop to test file output, ColorPix to test
display, and pngcheck to test the PNG files.)

Post a reply to this message

More on the bigger issue:
I hope I'm not over-reacting here but here goes:

Like most who have used POV for many years, we rely on past examples rather than
having to reinvent the wheel each time from scratch. This is particularly true
since POV has evolved into a much more complex SDL - radiosity and photons and
media and other envelope-pushing features - that, while they expand the horizon
of possibilities, have also made it much more difficult to efficiently use.
There seems to be an almost infinite fiddling with parameters and tweaks and
coefficients to the point that it is all the more necessary, when trying to just
get something done, to merely borrow on some successful solution others have
found that just works. It is little wonder that beginners and accomplished
graphic artists like Gilles Tran have lost interest in POV as a workable,
practical tool. The addition of macros has helped some but it's gotten so
cumbersome even long-time users aren't sure what to do to get what they expect.
Does anyone else still miss "halo, for example, or MegaPov's "glow". Not
"technically realistic" perhaps but they got the job done.

But as it is now with 3.7, that's all out the window. I tried for example to
test Steve Gowers' famous "Bucket of Shells", which was originally created in
3.0 but still renders the same in 3.6. No matter what I tried, setting #version
3.0, #version 3.6, #version 3.7 with any and every possible Display_Gamma or
File_Gamma or assumed_gamma or gamma whatever, the results in 3.7 came out
dramatically different. There is in effect no practical backward compatibility
with the whole tradition of POV. And as for trying to tweak the lighting and
ambient and diffuse ad infinitum of every light source and color and finish
etc., etc., one might as well start from scratch. So while a good case has be
made that POV in the past was technically "wrong", is this more important than
how it is actually used. Whatever the technical issues, POV worked fine. It
played well with others. Images came out as expected on the web, in Photoshop,
on Macs and PCs and Linux. To just say that we were just doing it "wrong" all
those years for using assumed_gamma for artistic effect misses the point. Who
cares how we got there as long as we made it and it didn't take a week of
futzing around. I sometimes think, with all due respect for the enormous and
wonderful work the developers have freely put into it, that POV has lost sight
of the end-user who's out there not just to play with the dials and controls but
just to get something off the ground.

Post a reply to this message

Am 28.11.2010 15:46, schrieb Stephen Klebs:
> But as it is now with 3.7, that's all out the window. I tried for example to
> test Steve Gowers' famous "Bucket of Shells", which was originally created in
> 3.0 but still renders the same in 3.6. No matter what I tried, setting #version
> 3.0, #version 3.6, #version 3.7 with any and every possible Display_Gamma or
> File_Gamma or assumed_gamma or gamma whatever, the results in 3.7 came out
> dramatically different. There is in effect no practical backward compatibility
> with the whole tradition of POV. And as for trying to tweak the lighting and
> ambient and diffuse ad infinitum of every light source and color and finish
> etc., etc., one might as well start from scratch. So while a good case has be
> made that POV in the past was technically "wrong", is this more important than
> how it is actually used. Whatever the technical issues, POV worked fine. It
> played well with others. Images came out as expected on the web, in Photoshop,
> on Macs and PCs and Linux. To just say that we were just doing it "wrong" all
> those years for using assumed_gamma for artistic effect misses the point. Who
> cares how we got there as long as we made it and it didn't take a week of
> futzing around. I sometimes think, with all due respect for the enormous and
> wonderful work the developers have freely put into it, that POV has lost sight
> of the end-user who's out there not just to play with the dials and controls but
> just to get something off the ground.

There are two sides of the medal.

For me, who has some background knowledge about physics, and values 
photo-realism in raytracing, and who is comparatively new to 3D 
rendering, a realistic lighting model is a KEY to easy modelling of 
textures.

The world of 3D rendering is full of tools taking the "tweak it until it 
looks good" approach - all that shader based stuff, essentially - so I 
see no need for POV-Ray to join those. To the contrary, I see a need for 
tools that allow you to model textures that look equally convincing in a 
broad range of illumination situations, and you just can't get that by 
tweaking an unrealistic shader model. This is the only way you can 
really build a library of textures you can rely on. At least that's my 
experience.

Personally, I'm convinced that once people get used to the new gamma 
handling, they'll find it much easier to work with than the old approach.

Post a reply to this message

On 28/11/2010 4:51 PM, clipka wrote:
>
> Personally, I'm convinced that once people get used to the new gamma
> handling, they'll find it much easier to work with than the old approach.


compatibility. Could we not have a switch that forces the use the old 

all the Moray users who model in Moray but render the scene using Ver 
3.7. I assume that Bishop3D will update its image map handling as it is 
still being developed.

-- 
Regards
     Stephen

Post a reply to this message

Am 28.11.2010 18:59, schrieb Stephen:
> On 28/11/2010 4:51 PM, clipka wrote:
>>
>> Personally, I'm convinced that once people get used to the new gamma
>> handling, they'll find it much easier to work with than the old approach.
>

> compatibility. Could we not have a switch that forces the use the old
> method or for #version 3.6 to use it?

I've been pretty busy this weekend working on exactly that.

Post a reply to this message

On 28/11/2010 6:06 PM, clipka wrote:
> Am 28.11.2010 18:59, schrieb Stephen:
>> On 28/11/2010 4:51 PM, clipka wrote:
>>>
>>> Personally, I'm convinced that once people get used to the new gamma
>>> handling, they'll find it much easier to work with than the old
>>> approach.
>>

>> compatibility. Could we not have a switch that forces the use the old
>> method or for #version 3.6 to use it?
>
> I've been pretty busy this weekend working on exactly that.

Well done that man! :-D

Hows the new (ish) job going?

-- 
Regards
     Stephen

Post a reply to this message

Am 28.11.2010 19:55, schrieb Stephen:

>> I've been pretty busy this weekend working on exactly that.
>
> Well done that man! :-D
>
> Hows the new (ish) job going?

Busy as hell :-)
But it seems like we're getting the projects out the door in time.

Post a reply to this message

On 28/11/2010 7:11 PM, clipka wrote:
>>
>> Hows the new (ish) job going?
>
> Busy as hell :-)
> But it seems like we're getting the projects out the door in time.

That's good. I started a new project myself, about the same time but 
I've just jumped ship. Busy as hell but getting nowhere. Bloody 
government projects.

-- 
Regards
     Stephen

Post a reply to this message

Stephen Klebs <skl### [at] gmailcom> wrote:
> I use POV for graphics work, so I often rely on it to match rgb values
> irrespective of lighting conditions. For example, in 3.6 a 50% gray with no
> light source and ambient 1 is always accurately rendered as RGB 128, 128, 128,
> as long as Display_Gamma in povray.ini is the same as assumed_gamma in
> global_settings or if no assumed_gamma is declared. This is true of image-mapped
> pigments or declared colors.

> In 3.7, however, with the suggested Display_Gamma and File_Gamma set to 2.2, a
> 50% gray (rgb 0.5) with no light source and ambient 1 comes out as RGB
> 186,186,186 or a gray of about 0.73, much lighter. This does not make sense to
> me. I would expect that if ambient is set to 1 with nothing else affecting the
> color, that the rendered output would match the value called for.

  The problem is that RGB 128,128,128 is *not* 50% gray, in other words,
exactly half-way between black and white, in any display system (except
perhaps very exotic ones). RGB does not map linearly to brightness in
most displays.

  If your monitor has a gamma of 2.2, then RGB 186,186,186 ought to be
pretty close to 50% brightness. If it's not, then you should use a gamma
which matches your display system.

  Moreover, RGB 186,186,186 may look exactly 50% bright in your display
system but not somebody else's. For example, there are systems where
display gamma is 1.8 instead of 2.2. In this case the gamma meta-information
in a PNG file exists to display such an image properly in such a system with
a different display gamma. It helps the system make the proper corrections
to make the 50% bright pixels look 50% bright on the target system.

  If you are dealing with literal pixel values rather than how they look
on screen, eg. because you are using these pixel values as data for some
purpose, then setting gamma to 1.0 is the proper way of achieving that,
as it stops gamma correction from being made.

  Currently if you specify #version 3.6 in your scene, it should make the
current beta to assume 3.6's way of handling gamma (IIRC), but this is still
under discussion and development to make backwards compatibility work better.

-- 
                                                          - Warp

Post a reply to this message

Bluntly put. You're making this much too complicated. It's certainly less
complicated than dealing with color management for print. You make a picture
that looks good on your computer. It doesn't matter how you do it. (The beauty
of POV, for me at least, is that you have almost complete control to do almost
anything you want. From photo-realism to fractals, from cartoons to caustics.)
If it looks right, it IS right. So you set the gAMA chunk in the PNG to say that
this picture was made on a system with gamma 2.2 or 1.8 or whatever so that
other systems and programs will know how to compensate. If someone's display
gamma is off, then that's a problem with their system display, not with the
picture or how it was made. If another program doesn't read it properly, that's
a problem with how it's understood not how it was written. What you are doing is
pre-correcting the correction. An example: I want to create a simple continuous
gradient from white to black so I tell POV I want a simple series of boxes or
whatever from rgb 1 to rgb 0 in, say, 10% increments. Since POV is a programming
language and not a GUI, I have to blindly tell it what I want it to do. I have
to say something like:

#local i = 0;
#while (i <= 10)
  object {box {0 1}
    pigment {rgb 1-(i/10)}
    finish {ambient 1}
    translate (i-5.5)*x
  }
  #local i = i + 1;
#end


Now what do I get? Not a straight, smooth, gradual gradient from light to dark
but a parabolic curve of values from light to slightly darker but still light to
abruptly skewed to black. It's the relative relation of values not the
brightness that's off. This is not what I asked it to do and if this is how it
will be then you have to change the language to say it differently. As if you
can make something smaller by measuring it with a ruler made longer.

Post a reply to this message