Okay, I wasn't clear enough : when I meant the preview and the file being
identical, I meant the preview and how the file was supposed to be displayed...
Then, they should be identical, right ?...

I'm trying to use the no-parameters-yet-still-pretty-bright-for-me way, but...
Daah, it really does look bright (transitions from light to dark are much much
more violent)... :-/

Post a reply to this message

And, in the previous post, I was also only talking about PNG file ; I understand
the deal with the others.

Post a reply to this message

Am 26.06.2010 22:06, schrieb Gyscos:
> Okay, I wasn't clear enough : when I meant the preview and the file being
> identical, I meant the preview and how the file was supposed to be displayed...
> Then, they should be identical, right ?...

How /is/ the file supposed to be displayed?

I think there can be no doubt that, technically speaking, it is supposed 
to be displayed the way POV-Ray computed it.

But if the /preview/ doesn't display the image the way POV-Ray computed 
it, how can the preview look identical to a file that does?

And PNG files always do look the way they were computed, provided you're 
using a gamma-aware viewer (like, say, Firefox).


> I'm trying to use the no-parameters-yet-still-pretty-bright-for-me way, but...
> Daah, it really does look bright (transitions from light to dark are much much
> more violent)... :-/

You care to show an example? Maybe we can help you out with ideas how to 
fix what's bugging you.

Post a reply to this message

Sure !

Here is a simple scene I use to test some scattering :


// ----------------------------------------

camera {
    location  <1.4, 0.5, -4.8>
    look_at   <-0.1, -1,  0.0>
}


light_source {
  <0, 0, 0>
  rgb 1
  translate 10*z
}

// ----------------------------------------

// The Wall
difference {
  box {
    <-5, -0.5, -0.2>,
    < 5,  0.5,  0.2>
  }
  #declare i = 0;
  #while (i < 9)
    cylinder {
      <0, 0, -1>
      <0, 0,  1>
      0.3
      translate (-4 + i) * x
    }
    #declare i = i + 1;
  #end
  pigment { rgb 1 }
  finish { ambient 0 }
}

// Dust
box {
  <-4.999, -0.499, -4.999>,
  < 4.999,  0.499,  0.499>
  pigment { rgbt 1 }
  hollow
  interior {
    media {
      intervals 20
      scattering {
        2, rgb 0.1
      }
    }
  }
}

On 3.6, I would get the result I was looking for. In 3.7, with the now-real
gamma computation, the light rays are too bright. So I tried to set a lower
color for the media (0.01 instead of 0.1), but I can't get as much contrast as I
did in 3.6...
The workaround I use is to use type 3 instead of type 2, wich is more directive,
and then gives more contrast...

----

When're you're talking about the computed file, is it the colors of the pixels
stored ? Or after the gamma correction ?
Cause if the gamma correction is set to linear, then a linear preview in POV-Ray
wouldn't be wrong, would it ?...

Post a reply to this message

> Sure !
>
> Here is a simple scene I use to test some scattering :
>
>
> // ----------------------------------------
>
> camera {
>      location<1.4, 0.5, -4.8>
>      look_at<-0.1, -1,  0.0>
> }
>
>
> light_source {
>    <0, 0, 0>
>    rgb 1
>    translate 10*z
> }
>
> // ----------------------------------------
>
> // The Wall
> difference {
>    box {
>      <-5, -0.5, -0.2>,
>      <  5,  0.5,  0.2>
>    }
>    #declare i = 0;
>    #while (i<  9)
>      cylinder {
>        <0, 0, -1>
>        <0, 0,  1>
>        0.3
>        translate (-4 + i) * x
>      }
>      #declare i = i + 1;
>    #end
>    pigment { rgb 1 }
>    finish { ambient 0 }
> }
>
> // Dust
> box {
>    <-4.999, -0.499, -4.999>,
>    <  4.999,  0.499,  0.499>
>    pigment { rgbt 1 }
>    hollow
>    interior {
>      media {
>        intervals 20
>        scattering {
>          2, rgb 0.1
>        }
>      }
>    }
> }
>
> On 3.6, I would get the result I was looking for. In 3.7, with the now-real
> gamma computation, the light rays are too bright. So I tried to set a lower
> color for the media (0.01 instead of 0.1), but I can't get as much contrast as I
> did in 3.6...
> The workaround I use is to use type 3 instead of type 2, wich is more directive,
> and then gives more contrast...
>
> ----
>
> When're you're talking about the computed file, is it the colors of the pixels
> stored ? Or after the gamma correction ?
> Cause if the gamma correction is set to linear, then a linear preview in POV-Ray
> wouldn't be wrong, would it ?...
>
>

Normaly, you should set display_gamma to the actual gamma value of your 
display. On most Windows systems, it should be around 2.2, and I think 
that it's the value that is assumed it you don't explicitely set it.
This tells POV-Ray to correct the display correctly, but don't affect 
the actual output.



Alain

Post a reply to this message

> // Dust
> box {
>    <-4.999, -0.499, -4.999>,
>    <  4.999,  0.499,  0.499>
>    pigment { rgbt 1 }
>    hollow
>    interior {
>      media {
>        intervals 20
>        scattering {
>          2, rgb 0.1
>        }
>      }
>    }
> }
>

Unrelated to your problem, but you should NOT use intervals 20.
Much, much beter to leave it to it's default value of 1 and set samples 
instead.
You'll see that for the same final number of samples, the rendering 
speed get much beter.


Alain

Post a reply to this message

Yeah, I just noticed that too...
The thing is, I saw in the doc that default value for interval was 10 :
http://www.povray.org/documentation/view/3.6.1/421/
So when I first saw the results weren't good, I changed it to 20. But now if I
set it to 10, it works fine too, so I doubt the default value really is 10...
Maybe 1 indeed.

Also, still unrelated, but when I use method 3 with a very low variance
(0.000000001), a very high confidence (0.99999999), and "samples 10, 100",
shouldn't it use more than 10 if the result isn't perfect ? I don't see why
"samples 30, 100" works better there...

Post a reply to this message

Sorry, just noticed with method 3, max samples didn't matter... <_<

Post a reply to this message

Am 27.06.2010 08:59, schrieb Gyscos:

> On 3.6, I would get the result I was looking for. In 3.7, with the now-real
> gamma computation, the light rays are too bright. So I tried to set a lower
> color for the media (0.01 instead of 0.1), but I can't get as much contrast as I
> did in 3.6...
> The workaround I use is to use type 3 instead of type 2, wich is more directive,
> and then gives more contrast...

Yes, having had a look at the scene I guess that's the way to go indeed. 
(Apparently, type 2 was the wrong model for your purposes.)

> When're you're talking about the computed file, is it the colors of the pixels
> stored ? Or after the gamma correction ?

Neither. I mean the brightness levels computed; the "idea" of the image, 
rather than its actual binary representation.

When an output file is actually written, there is a mapping applied from 
the (simulated) physical brightness levels to the binary representation 
values. With most file types, this mapping includes some gamma-encoding, 
and in POV-Ray is governed by the FILE_GAMMA parameter.

Likewise, when a file is read and displayed by a viewing software, there 
is a mapping applied from the binary representation values back to 
(real) physical brightness levels, via the viewing software, operating 
system API, graphics drivers, graphics card, display controller, and 
(typically) LCD panel. With most file types, this mapping is fixed and 
out of POV-Ray's control.

Last not least, when POV-Ray outputs to the preview window, there is a 
mapping applied directly from the /simulated/ physical brightness levels 
to /real/ physical brightness levels, via the OS API, graphics drivers, 
graphics card, display controller, and (typically) LCD panel. This 
mapping, in all cases, is governed by the DISPLAY_GAMMA parameter.


> Cause if the gamma correction is set to linear, then a linear preview in POV-Ray
> wouldn't be wrong, would it ?...

I think you're approaching the problem wrong, and it's difficult (though 
not impossible) to argue against it, so I prefer to try and lead you to 
the conclusion via a different path. Forget for a moment how you /think/ 
FILE_GAMMA and DISPLAY_GAMMA are related - because as a matter of fact 
they're not: They're serving independent purposes.

Let's have a look at DISPLAY_GAMMA:

This is the parameter that controls how /simulated/ physical brightness 
levels (as computed by the POV-Ray rendering engine) are mapped to 
/real/ physical brightness levels emitted by your display.

I think it should be obvious that you want a direct 1:1 mapping between 
these two: You want your display to show what POV-Ray calculated.

However, the pipeline from the operating system to the emitted light has 
some non-linearities in it: Rather than a 1:1 mapping, it is 
approximately a f(x)=x^GAMMA mapping, with some system-specific fixed 
value for GAMMA; so in order to achieve the net 1:1 mapping, POV-Ray 
must compensate for that before handing the data over to the OS, by 
applying another g(x)=x^(1/GAMMA) mapping.

Evidently, in order to do so, POV-Ray needs to know the value of GAMMA, 
which is exactly what you specify with DISPLAY_GAMMA. If you get this 
wrong, you'll retain non-linearities in the mapping between simulated 
and real light intensities, and the preview will /not/ show what was 
computed.

Post a reply to this message

Thanks, I think I get it better now...

But isn't it possible to query the right value for Display_Gamma from the OS ? I
mean, how do other viewer software do ?

Also, about File_Gamma, it is used for the gamma-encoding that is applied when
creating the file. When reading the file, it is decoded by the software, and
then sent to the OS.
I understand that, between the file being sent to the OS and the pixel being
illuminated on the screen, there can be the gamma-transformation, caused by the
graphic card, system, screen, ... because of some non-linearity.
Now, before that, how does the software decode the file ?
Does it do a reverse-encoding with the gamma value stored in the file ? Or does
it just send it linearly to the system ?


I understood the Display_Gamma was mainly to compensate the system+GC+screen non
linearity.

The question is : What should the File_Gamma value compensate ? The software
decoding ? The system+GC+screen non linearity ? Or the eye's perception ?

Thanks for your patience :)

Post a reply to this message