Based on the stage design by art director Yukimasa Okumura for the YMO 
performance in 1981.
I used an aged video tape (recorded from Japanese TV) as reference but 
have actually seen them life at Budokan in 1983 ;)

This image is basically the result of experimenting with Adobe-RGB (and 
it's wider gamut compared to sRGB) as working color space for rendering 
within POV-Ray. As my monitor fully covers the Adobe-RGB gamut I can 
visually design the colors and push them to the limits.
The interesting and surprising thing is: I do even get more vibrant 
colors and a better preservation of subtle texture details when 
rendering within Adobe-RGB and converting the final image to sRGB (by 
using ICC profiles) compared to defining the colors already within sRGB 
and rendering within sRGB. This was something that I did not expect and 
after having rechecked my color management pipeline I think that indeed 
the diffuse radiosity bounces do produce more vibrant and maybe more 
realistic results within the wider gamut.

Sadly the JPEG compression does make things even worse for this kind of 
image but anyway here is the (into sRGB converted) JPEG version - quite 
poor compared to the full blown 1920x1200 uncompressed Adobe-RGB image 
that I currently use as desktop background.

-Ive

Post a reply to this message

Attachments:
Download 'yellow magic (small).jpg' (180 KB)

Preview of image 'yellow magic (small).jpg'

Ive wrote:

> Based on the stage design by art director Yukimasa Okumura

looks great even in srgb ;) (and my monitor would be too old anyway)

> The interesting and surprising thing is: I do even get more vibrant 
> colors and a better preservation of subtle texture details when 
> rendering within Adobe-RGB

Do I understand correctly that you define colors in adobe rgb,
manually convert them to "linear adobe rgb" (x^1/2.2), render in
povray using file_gamma 2.2, reinterpret the output using an
adobe rgb profile and then convert to srgb?

And that this gives significantly different results compared to
using "linear srgb" (for lack of better term) via "srgb x" (not
x^1/2.2) and rendering using file_gamma srgb?

Interesting ... but it may not be so surprising after all if your
input colors are at extreme limits. Consider a pigment of maximum
adobe rgb red <255/255, 0.0, 0.0>. If lighting causes the output pixel
to be <240/255, 0.0, 0.0>, it is still outside srgb gamut and may end
up with maximum saturation after conversion, whereas clipping the
input value to srgb yields an srgb output of <240/255, 0.0, 0.0>.

As a sanity check, have you tried rendering in adobe rgb but
using only input colors that are within srgb gamut?

Post a reply to this message

Am 29.08.2012 02:20, schrieb Christian Froeschlin:
> looks great even in srgb ;) (and my monitor would be too old anyway)
>
thanks ;)

> Do I understand correctly that you define colors in adobe rgb,
> manually convert them to "linear adobe rgb" (x^1/2.2), render in
> povray using file_gamma 2.2, reinterpret the output using an
> adobe rgb profile and then convert to srgb?
>
Exactly! Better explained than I could - as usual. A minor detail is 
that I did use OpenEXR output as always and did assign a linear 
Adobe-RGB profile to it. Converting to sRGB was the last step when 
writing the JPEG file.


> And that this gives significantly different results compared to
> using "linear srgb" (for lack of better term) via "srgb x" (not
> x^1/2.2) and rendering using file_gamma srgb?
>
Yes, in this case where under the strong "neon" lighting highly 
saturated colors do result. And just to make it clear "srgb x" does not 
mean the "srgb" POV-Ray keyword it just means rgb values that do assume 
sRGB primaries and are manually converted from the original Adobe-RGB 
values using a color space transformation - and as just linear gamma is 
involved this boils down to a simple matrix multiplication.

> Interesting ... but it may not be so surprising after all if your
> input colors are at extreme limits. Consider a pigment of maximum
> adobe rgb red <255/255, 0.0, 0.0>. If lighting causes the output pixel
> to be <240/255, 0.0, 0.0>, it is still outside srgb gamut and may end
> up with maximum saturation after conversion, whereas clipping the
> input value to srgb yields an srgb output of <240/255, 0.0, 0.0>.
>
> As a sanity check, have you tried rendering in adobe rgb but
> using only input colors that are within srgb gamut?

No, but I really do not suspect any difference in this case.

But what I will try some day is using POV-Ray as spectral renderer :)

This could be done within an animation loop of e.g. 31 steps in 10nm 
from 400nm to 700nm (I got inspired by Bruce Lindbloom who did exactly 
this with his own self-made renderer).
Some spectral data for fluorescent tubes is already part of lightsys and 
for the color definitions I can use my spectrophotometer and visit some 
of my former business partners for real world paint samples that do 
match the stage design.
Due the characteristic of fluorescent light sources (with its strong 
peaks instead a continuous curve) I do expect some interesting results.

-Ive

Post a reply to this message

Darn... I was expecting a yellow Dogde Challenger! :)

Very nice indeed, and excellent on the technical side, as usual.

--
Jaime

Post a reply to this message

This going a bit beyond my mental capacities, but I find it fascinating 
nonetheless. ;-)

Thomas

Post a reply to this message

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.

But first there's some cleaning-up to do on the color handling code of 
official POV-Ray.

Post a reply to this message

Am 29.08.2012 07:42, schrieb Ive:

> But what I will try some day is using POV-Ray as spectral renderer :)
>
> This could be done within an animation loop of e.g. 31 steps in 10nm
> from 400nm to 700nm (I got inspired by Bruce Lindbloom who did exactly
> this with his own self-made renderer).

11 steps will do if you make use of three color channels per frame :)

Post a reply to this message

Le 29/08/2012 12:08, clipka a écrit :
> 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.
> 
> But first there's some cleaning-up to do on the color handling code of
> official POV-Ray.
> 


Assuming a ray's color is a 1D vector spectrum, please make the
pigment's color a 2D matrix. Most matrix would be resumed to a diagonal,
but using a matrix would allow to model shift on the spectrum.

Post a reply to this message

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?

-Ive

Post a reply to this message

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? 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.


> But first there's some cleaning-up to do on the color handling code of
> official POV-Ray.
>
Like what? Just curious.

-Ive

Post a reply to this message