 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A test scene for refraction and dispersion, run on genuine POV-Ray
3.7.0.beta.34.
From left to right:
(1) no refraction
(2) refraction at a single interface between air (camera side) and a
medium with ior of 1.5 (scale/background side), tilted by 30 degrees
(3) ditto, but with dispersion (1.013, 20 samples)
(4) ditto, but with stronger dispersion (1.027) and only 2 samples
(5)-(8) ditto, but with 3 to 6 samples respectively
Common setup for each section is as follows:
- A fixed self-illuminated white scale mounted behind the refracting
interface, with 1-degrees divisions (numbered) and 0.5- and 0.1-degrees
subdivisions.
- A diffusely reflecting white background screen.
- Two self-illuminated white indicator shapes, one mounted in fixed
position in front of the refracting interface (left triangular shape),
another mounted at the scale (right triangular shape) at a precomupted
position so that it should line up with the other indicator.
- A spotlight source close to the camera, with photons enabled, which
should be visible as a blurred grey disk around the indicators' position.
Things to note in this render (which took 74 seconds on a Core i7 machine):
- The shortest-wavelength (extreme violet) sample is invariably
invisible, and the longest-wavelength (extreme red) almost so as well.
- Extremely low sample counts lead to wrong hues.
- The perceived "center" of the reflected image is slightly off when
using dispersion.
Conclusion: POV-Ray 3.7.0.beta.34 gets dispersion wrong. (Note however
that the same scene, rendered with POV-Ray 3.6, gives virtually
identical results, so the problem has been around a while.)
(Aside from the problems demonstrated here, POV-Ray 3.7.0.beta.34 also
has additional problems when more than one interface is involved - such
as with prisms - which POV-Ray 3.6 does not have. I'll demonstrate those
in a follow-up.)
Post a reply to this message
Attachments:
Download 'refraction_test_370beta34.png' (469 KB)
Preview of image 'refraction_test_370beta34.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here's the same scene rendered with a patched beta.34 (84 seconds; the
difference might be due to adc_bailout kicking in for the "ultraviolet"
rays with genuine beta.34).
Note how this patch keeps the lowest- and highest-wavelength samples
well within the visible realm for low sample counts, without adversely
affecting high sample counts. However, the hue is still adversely affected.
Post a reply to this message
Attachments:
Download 'refraction_test_patch_a.png' (602 KB)
Preview of image 'refraction_test_patch_a.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka schrieb:
... and another patch; notice how the color "sum" remains stable now
even with extremely low dispersion sample count. (79 seconds render time)
Post a reply to this message
Attachments:
Download 'refraction_test_patch_b.png' (595 KB)
Preview of image 'refraction_test_patch_b.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Similar test setup as before, but now with prisms.
Left to right:
(1) no prism, for reference
(2) prism with an ior of 1.303; front and back face tilted by 30 and -30
degrees, respectively
(3) ditto, but with an ior of 1.297
(4) ditto, but with an ior of 1.3 and a dispersion of 1.303/1.297 (20
samples). Note that this should give an effective ior of approximately
1.297 to 1.303, depending on wavelength.
The indicators for (2)-(4) are set for an ior of 1.3 in all cases.
First render was done with POV-Ray 3.6.2; note how the dispersion in (4)
"smears" the image of the marker quite exactly between the positions in
(2) and (3).
Second render was done with POV-Ray 3.7.0.beta.34; note how the
dispersion effect is barely noticeable.
The third render was done with a patched beta.34; note how the
dispersion now matches again.
Post a reply to this message
Attachments:
Download 'refraction_test_prism_362.png' (138 KB)
Download 'refraction_test_prism_370beta34.png' (137 KB)
Download 'refraction_test_prism_patch.png' (145 KB)
Preview of image 'refraction_test_prism_362.png'
Preview of image 'refraction_test_prism_370beta34.png'
Preview of image 'refraction_test_prism_patch.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Excellent work, sir! You are entitled to a bonus :-)
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot schrieb:
> Excellent work, sir! You are entitled to a bonus :-)
I'm still not happy with the whole smash.
Notice the brightness "peak" in the violet range? Doesn't appear natural
to me.
Right until beta.34, POV-Ray has been using a rather obscure and sketchy
formula to compute spectral colors, based on data from the 'net that I
didn't manage to track down. This makes it difficult to determine (a)
what color space the underlying data was designed for, (b) whether the
original data was gamma-precorrected or not, and (c) what wavelengths
the code is normalized to.
I tried to replace the formula with an interpolation table generated
from physical data normalized to the sRGB color space, but it looked
even worse.
(I did replace the formula with a table though - using values generated
directly from the formula for now - as this was needed to address the
"color drift" that occurred with low dispersion sample count.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> I'm still not happy with the whole smash.
>
> Notice the brightness "peak" in the violet range? Doesn't appear natural
> to me.
>
> Right until beta.34, POV-Ray has been using a rather obscure and sketchy
> formula to compute spectral colors, based on data from the 'net that I
> didn't manage to track down. This makes it difficult to determine (a)
> what color space the underlying data was designed for, (b) whether the
> original data was gamma-precorrected or not, and (c) what wavelengths
> the code is normalized to.
It seems the code tries to mimic the CIE CMF (color matching function)
within r,g,b values. Note the two peaks of the red component. I do not
know how well this is done but I do see two problems:
CIE reference white is D50 and not D65 as within s(c)RGB and the CMF
tables of course refer to the CIE xyz color space.
> I tried to replace the formula with an interpolation table generated
> from physical data normalized to the sRGB color space, but it looked
> even worse.
???
> (I did replace the formula with a table though - using values generated
> directly from the formula for now - as this was needed to address the
> "color drift" that occurred with low dispersion sample count.)
As an accurate in place calculation is quite computing intensive and as
you have already implemented a LUT it should be fairly easy to fill it
with accurate rgb values depending on the wavelength by using a bit of
POV-Ray SDL from my CIE.inc file and the macro
Wavelength2RGB(wavelength) from there.
like this:
#include "CIE.inc"
#declare WL_MIN = 385; //values below will not contribute much
#declare WL_MAX = 700; //values above are almost invisible
#declare WL_STEP = 5; //or whatever value is useful for your lut.
#declare WL = WL_MIN;
#while (WL <= WL_MAX)
#declare WL_RGB = Wavelength2RGB(WL);
/*
now write the WL_RGB value to a file or to the message pane or whatever
and use them for the POV-Ray source code LUT...
*/
#declare WL = WL + WL_STEP;
#end
Should be used with the default settings (sRGB primaries,
D65 whitepoint, D50 reference white and Bradford chromatic adaption).
It will fulfill the criteria that integrating over all samples will
result in *white*. The values close to UV and IR will become darker (as
they should) so the violet peak you did observe should disappear.
As I have not the faintest idea how the POV-Ray photon code is working
a few additional notes:
The values that are returned from 'Wavelength2RGB' are NOT normalized,
so maybe there should be a constant multiplier for all values (to make
them exactly fit into the 0.0 - 1.0 range).
The values that are chosen for WL_MIN and WL_MAX (or better how the
dispersion samples within POV-Ray are spread out) will have a huge
impact on the visual appearance, so for a low count of dispersion
samples they should be limited to only spread from e.g. 440nm to 640nm
(but only guessing here, has to be tried out).
So even if the values returned by Wavelength2RGB are perfectly accurate
there will be some trial and error involved to find visually good
looking values for the min and max dispersion spread especially when
only few samples are used.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive schrieb:
> It seems the code tries to mimic the CIE CMF (color matching function)
> within r,g,b values. Note the two peaks of the red component. I do not
> know how well this is done but I do see two problems:
> CIE reference white is D50 and not D65 as within s(c)RGB and the CMF
> tables of course refer to the CIE xyz color space.
Shouldn't the white point issue be addressed properly by the standard
XYZ->sRGB color space mapping?
Presuming of course that this (or something similar) was done by the
author of the function.
>> I tried to replace the formula with an interpolation table generated
>> from physical data normalized to the sRGB color space, but it looked
>> even worse.
>
> ???
Step 1: Grab the CIE tristimulus data. I would have expected this to
have given me spectral band colors in CIE XYZ color space.
Step 2: Convert CIE XYZ colors to sRGB primaries and white point using
the matrix as defined in the sRGB standard
Step 3: Fix gamut.
>> (I did replace the formula with a table though - using values
>> generated directly from the formula for now - as this was needed to
>> address the "color drift" that occurred with low dispersion sample
>> count.)
>
> As an accurate in place calculation is quite computing intensive and as
> you have already implemented a LUT it should be fairly easy to fill it
> with accurate rgb values depending on the wavelength by using a bit of
> POV-Ray SDL from my CIE.inc file and the macro
> Wavelength2RGB(wavelength) from there.
That's one reason (of multiple) why I modified the code to use a LUT now.
You got something already? Hey, me wants that!
Ah, you even included code... neat. I'll give it a try, thanks!
> Should be used with the default settings (sRGB primaries,
> D65 whitepoint, D50 reference white and Bradford chromatic adaption).
Ah, um... which means?
Well, never mind - I guess it'll be substantial enough to at least give
me a hint what to google for.
> It will fulfill the criteria that integrating over all samples will
> result in *white*. The values close to UV and IR will become darker (as
> they should) so the violet peak you did observe should disappear.
>
> As I have not the faintest idea how the POV-Ray photon code is working
> a few additional notes:
> The values that are returned from 'Wavelength2RGB' are NOT normalized,
> so maybe there should be a constant multiplier for all values (to make
> them exactly fit into the 0.0 - 1.0 range).
> The values that are chosen for WL_MIN and WL_MAX (or better how the
> dispersion samples within POV-Ray are spread out) will have a huge
> impact on the visual appearance, so for a low count of dispersion
> samples they should be limited to only spread from e.g. 440nm to 640nm
> (but only guessing here, has to be tried out).
The approach used by POV-Ray 3.6 (and 3.7 up intil beta.34) was to
spread from what could have been 380 nm to something like 730 nm; for a
3-sample dispersion it would then take wavelengths 380 nm, 555 nm and
730 nm. Which is obviously highly bogus because 380 nm and 730 nm are
virtually black already.
My current approach differs in two respects:
(1) As far as refraction angles are concerned, I allow for a
half-"bandwidth" marging near the edges of the visible spectrum; that
is, for instance with a 3-sample dispersion, sample rays will be assumed
to have wavelengths of 438 nm, 555 nm, and 672 nm, respectively.
(2) As far as sample ray colors are concerned, I'm not using /sample/
colors, but /integrated/ colors; that is, for instance in the 3-sample
dispersion example, the 438 nm ray would be colored as if it was a
bundle of rays from 380 to 497 nm; the 555 nm ray would be colored like
a bundle of rays from 497 nm to 613 nm; and the 672 nm ray would be
colored like a bundle of rays from 613 to 730 nm.
The lookup table is already adapted for this purpose, storing integrals
of the colors from 380 nm to X in steps of 5 nm; an individual ray will
then be colored by looking up two values from the table (for the ray's
nominal wavelength plus/minus half its "bandwidth"), and coloring the
ray according to the difference.
> So even if the values returned by Wavelength2RGB are perfectly accurate
> there will be some trial and error involved to find visually good
> looking values for the min and max dispersion spread especially when
> only few samples are used.
I think the integration approach does not suffer from this problem at all.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
