![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 29.08.2012 09:13, schrieb Jaime Vives Piqueres:
> Darn... I was expecting a yellow Dogde Challenger! :)
>
As usual I'm just hopping from one unfinished project to the next!
My virtue of patience is not as strong as you might think ;)
And this actually reminds me of some beauty line named in your honor
that needs my attention... *
-Ive
* sorry: in-joke
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In case anyone is interested, I have made a 1920x1200 16bit/channel PNG
version and also the "raw" rendered data in linear Adobe-RGB as a TIFF
available from my side at
http://www.lilysoft.org/CGI/YMO/yellowmagic.htm
But be warned, those are big files.
-Ive
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 29.08.2012 10:08, schrieb Thomas de Groot:
> This going a bit beyond my mental capacities, but I find it fascinating
> nonetheless. ;-)
>
Well, I'm not good in explaining, but all this is just about that within
the sRGB color space "only" 35% of the colors an average can "see" and
distinguish are represented. Within Adobe RGB this is already about 50%
and lets say a high quality art print covers up to 90%.
In practice the 35% of sRGB are not as bad as it sounds as mainly
high-saturated colors are effected and as long as nobody opens a
New-Wave nightclub in Gancaloon it shouldn't be much of a problem ;)
-Ive
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 29.08.2012 13:33, schrieb Ive:
> an average can "see" and
err, make this "an average human can "see" and" ...
-Ive
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 29.08.2012 13:12, schrieb Ive:
> Am 29.08.2012 12:08, schrieb clipka:
>> Am 29.08.2012 07:42, schrieb Ive:
>>
>>> But what I will try some day is using POV-Ray as spectral renderer :)
>>
>> And what /I/ will do some day is make a spectral rendering patch for
>> POV-Ray :-)
>>
>> From a mathematical point of view, the classic three-component RGB
>> approach is a pretty poor one, no matter what color space you're using.
>> From all the brain-wrecking I did about the topic, I suspect that a
>> straightforward N-channel spectral approach is the best solution.
>>
> Do you really think this is worth the effort?
I won't know until I try :-)
> To really benefit from a
> spectral render engine one needs spectral data for diffuse and specular
> reflectance for A LOT of materials. But somehow I suspect not that many
> POV-Ray users have a spectrophotometer at home.
While that's certainly true, I guess even with rgb-specified colors it
will already do some good to scenes with colored transparent objects, so
that e.g. two orange filters in sequence won't necessarily exhibit a hue
shift towards red, but could retain the orange hue while just gaining in
saturation.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 29.08.2012 13:12, schrieb Ive:
>> But first there's some cleaning-up to do on the color handling code of
>> official POV-Ray.
>>
> Like what? Just curious.
Using the same color data type throughout, for instance. As it is now,
some parts of the code use old C-style structures, while others already
use C++-style objects. Obviously, a consistent use of C++-style objects
would be easier to base a spectral rendering patch on.
Another thing is the internal handling of F and T components, which I
intend to replace with a full RGB transparency model. Again, this will
simplify implementing a sane spectral rendering patch.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 29.08.2012 13:04, schrieb Ive:
> Am 29.08.2012 12:11, schrieb clipka:
>> Am 29.08.2012 07:42, schrieb Ive:
>> 11 steps will do if you make use of three color channels per frame :)
>
> Of course [heading my forehead with my fist] thats brilliant. With only
> 11 animation frames a range from lets say 380nm to 700nm can be covered.
>
> BTW I'm aware that POV-Ray internally assumes sRGB primaries for
> iridescence and color->grayscale conversion. Is there anything else
> internally hard-coded that expects sRGB?
Dispersion springs to my mind.
Note that for iridescence you can override the assumed wavelengths.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 29-8-2012 13:33, Ive wrote:
> Am 29.08.2012 10:08, schrieb Thomas de Groot:
>> This going a bit beyond my mental capacities, but I find it fascinating
>> nonetheless. ;-)
>>
> Well, I'm not good in explaining, but all this is just about that within
> the sRGB color space "only" 35% of the colors an average can "see" and
> distinguish are represented. Within Adobe RGB this is already about 50%
> and lets say a high quality art print covers up to 90%.
I suppose one should be able to compare to see the differences. Could
you show a smaller image with both techniques side by side? Would that
be meaningful?
>
> In practice the 35% of sRGB are not as bad as it sounds as mainly
> high-saturated colors are effected and as long as nobody opens a
> New-Wave nightclub in Gancaloon it shouldn't be much of a problem ;)
I have received a few applications in fact, but refused. It's against
the Satrap's law ;-)
Thomas
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 29.08.2012 16:44, schrieb Thomas de Groot:
> On 29-8-2012 13:33, Ive wrote:
> I suppose one should be able to compare to see the differences. Could
> you show a smaller image with both techniques side by side? Would that
> be meaningful?
>
The image named "ymo - (Adobe RGB)" is the image where all colors are
defined within the Adobe RGB primaries and after rendering the image is
converted to linear sRGB (aka scRGB).
The one named "ymo - (sRGB)" uses already from Adobe RGB to sRGB
converted color definitions and no more color transformation on the
rendered output.
Both images did use linear gamma for color definitions and rendering,
output was 16bit IEEE floating point (using OpenEXR) and the final step
for both was reducing the bit-depth to 8bit/channel and applying the
sRGB transfer function.
To actually judge the difference it would be best to store them local
and use some image viewer that allows for browsing and setting a pitch
black background - I think.
I'm not saying that one or the other does look better (this kind of
scene makes it very hard to judge anyway) but it is interesting that
there *is* a difference.
My main goal was to render something for my own use and here it *does*
look much better - sadly I can share this only with people with a
similar high-end monitor but those will get cheaper and more common over
the years.
And I should also mention that using Adobe RGB as workspace for CGI
images IMO makes only sense when both monitor and graphics card do
support 10bit/channel as within the usual 8bit/channel color banding
becomes very prominent - the back-draw of the wider gamut. Not to
mention the need for appropriate software that does indeed support all
those features.
-Ive
Post a reply to this message
Attachments:
Download 'ymo crop2 (adobe rgb).png' (130 KB)
Download 'ymo crop2 (srgb).png' (144 KB)
Preview of image 'ymo crop2 (adobe rgb).png'
![ymo crop2 (adobe rgb).png](/povray.binaries.images/attachment/%3C503f08e2%40news.povray.org%3E/ymo%20crop2%20%28adobe%20rgb%29.png?preview=1)
Preview of image 'ymo crop2 (srgb).png'
![ymo crop2 (srgb).png](/povray.binaries.images/attachment/%3C503f08e2%40news.povray.org%3E/ymo%20crop2%20%28srgb%29.png?preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thanks Ive. There is indeed a very slight difference. A worthwhile
experiment; preparing for the future :-)
Thomas
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |