I implemented gamut mapping in Ive's spectral rendering rig, based on method 2
of CIE.inc in Lightsys IV.  Values above 1.0 are still clipped (which can
distort the hue).  Attached are renders of a modified version of Prism.pov.  As
you can see from the Osram render, there are still some bugs to be worked out
for brighter values.

I made one change from the algorithm in MapGamut(): when finding the lowest of
the RGB channels, I used <= instead of <, because the latter would always return
the blue value if the red and green happened to be identical.  (You might want
to look into that, Ive.)

Post a reply to this message

Attachments:
Download 'prism_montage.png' (41 KB)

Preview of image 'prism_montage.png'

Am 01.12.2013 06:11, schrieb Cousin Ricky:
> I implemented gamut mapping in Ive's spectral rendering rig, based on method 2
> of CIE.inc in Lightsys IV.  Values above 1.0 are still clipped (which can
> distort the hue).  Attached are renders of a modified version of Prism.pov.  As
> you can see from the Osram render, there are still some bugs to be worked out
> for brighter values.
>
Coincidental I'm just about to release version 0.2 (within the next few 
hours, just one more example scene to render) so in case you are willing 
to share your addition (AFAIR gamut mapping was on my to-do-list anyway) 
your contribution would be quite welcome.
Note that HDR values are not addressed by gamut-mapping but are again an 
art of its own. There are a lot algorithms out there like "local 
contrast mapping" by well known Greg Ward and also "adaptive logarithmic 
mapping" or "gradient domain mapping" just to name a few ;) and there is 
no way to say one of them is the best - it usually depends on the kind 
of image to process.
Personally I do prefer to do stuff like this as post-processing.

> I made one change from the algorithm in MapGamut(): when finding the lowest of
> the RGB channels, I used <= instead of <, because the latter would always return
> the blue value if the red and green happened to be identical.  (You might want
> to look into that, Ive.)
>
Will do, and thanks for the hint.

-Ive

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
> Coincidental I'm just about to release version 0.2 (within the next few
> hours, just one more example scene to render) so in case you are willing
> to share your addition (AFAIR gamut mapping was on my to-do-list anyway)
> your contribution would be quite welcome.

It is a modification to SpectralComposer.pov, which I also converted to a .inc
file because I prefer that to modifying a library file for each project.  Should
I email it to you?

> Note that HDR values are not addressed by gamut-mapping but are again an
> art of its own.

And I see that's also on your to-do list, although UberPOV /may/ make that job
easier.

> Personally I do prefer to do stuff like this as post-processing.

That would certainly be faster than doing it with SDL.  However, I'm not sure
that the wrap-around that often happens with POV-Ray pigment functions won't
thwart that when the entire render is a giant pigment function.  (Otherwise,
couldn't we do the gamut mapping in post-processing as well?)

Post a reply to this message

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> As
> you can see from the Osram render, there are still some bugs to be worked out
> for brighter values.

When investigating the problem, I found that lowering HDR_min to cover all
negative values solved the problem for a test scene.  However, doing this did
not help the Osram CoolBeam 20W render (and the lowest value turned out to be
-0.431, well within the default).

Post a reply to this message

Am 02.12.2013 04:31, schrieb Cousin Ricky:
> Ive <ive### [at] lilysoftorg> wrote:
>> Coincidental I'm just about to release version 0.2 (within the next few
>> hours, just one more example scene to render) so in case you are willing
>> to share your addition (AFAIR gamut mapping was on my to-do-list anyway)
>> your contribution would be quite welcome.
>
> It is a modification to SpectralComposer.pov, which I also converted to a .inc
> file because I prefer that to modifying a library file for each project.  Should
> I email it to you?
>
Please do so!

>> Note that HDR values are not addressed by gamut-mapping but are again an
>> art of its own.
>
> And I see that's also on your to-do list, although UberPOV /may/ make that job
> easier.
>
Yes, as far as I understand it, Christoph did implement some kind of 
HDR-tonemapping but I didn't try it myself yet. Anyway, I would prefer 
to have just official POV-Ray as requirement.


>> Personally I do prefer to do stuff like this as post-processing.
>
> That would certainly be faster than doing it with SDL.  However, I'm not sure
> that the wrap-around that often happens with POV-Ray pigment functions won't
> thwart that when the entire render is a giant pigment function.
 >
Well, that is what HDR_min and HDR_max are meant for - and it should 
work, in case I didn't make a stupid mistake somewhere that is ;)

> (Otherwise, couldn't we do the gamut mapping in post-processing as well?)
>
Yes, sure, but writing SDL code is kinda fun and reading it might even 
be interesting for people who would otherwise not care about some C++ 
code ;)

-Ive

Post a reply to this message

Am 02.12.2013 07:41, schrieb Ive:

>>> Note that HDR values are not addressed by gamut-mapping but are again an
>>> art of its own.
>>
>> And I see that's also on your to-do list, although UberPOV /may/ make
>> that job
>> easier.
>>
> Yes, as far as I understand it, Christoph did implement some kind of
> HDR-tonemapping but I didn't try it myself yet.

I don't know if it even deserves that name. It's really nothing spectacular.

Post a reply to this message

Playing around with UberPOV's glare desaturation.

For the images in the third column, I ran SpectralComposer with reduced Exposure
to prevent clipping, rendering to OpenEXR to avoid loss of precision.  Then I
read them as image maps into UberPOV and reversed the exposure reduction,
letting extreme RGB values fall where they may.

Post a reply to this message

Attachments:
Download 'prism_montage.png' (249 KB)

Preview of image 'prism_montage.png'