47302c02@news.povray.org...

> Usually you want to be able to control color mapping after the render.

Theoretically yes, but when color mapping is an integral part of the image's 
aesthetics, it's often more practical to have it done at render time, rather 
than having to open the image in Photoshop and change it each time with the 
same settings. It's not uncommon to create scenes that depend heavily on 
color mapping to look right and having to correct them at each iteration of 
the creation process would considerably slow down the workflow. I guess 
that's the reason why the feature is included in most (if not all) high-end 
renderers.

G.

Post a reply to this message

472fbce7@news.povray.org...
> Gilles Tran <gitran_nospam_@wanadoo.fr> wrote:
>> A very useful feature that goes hand in hand with full area lights is 
>> color
>> mapping aka tone mapping aka exposure control.
>
>  I didn't quite get the idea from those images. Some text explaining in
> simple terms the idea and the algorithm could be useful.

In addition to Thorsten's links, here's an explanation about how it's done 
in Mental Ray :
http://toi.bk.tudelft.nl/toi-pedia/index.php?title=Rendering_Mental_Ray:_Tone_mapping

G.

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> MegaPOV gives you the 
> option of defining any tone mapping function although this currently is 
> limited to  a 1D function identical for all color channels.  It might be 
> interesting to make this a more general feature allowing full control 
> over the mapping in all three color channels

  Since POV-Ray supports user-defined vector functions, it might be possible
to do it like that.

-- 
                                                          - Warp

Post a reply to this message

Gilles Tran <gil### [at] agroparistechfr> wrote:
> In addition to Thorsten's links, here's an explanation about how it's done 
> in Mental Ray :
>
http://toi.bk.tudelft.nl/toi-pedia/index.php?title=Rendering_Mental_Ray:_Tone_mapping

  Am I understanding correctly that "tone mapping" is nothing else than
a function which takes one parameter, namely a brightness value (eg. of a
color channel), and returns a brigthness value (usually the input value
multiplied by some function)?

  Could it also be a function taking three parameters, namely the red,
green and blue components of the color, and returning a vector?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Gilles Tran <gil### [at] agroparistechfr> wrote:
>> In addition to Thorsten's links, here's an explanation about how it's done 
>> in Mental Ray :
>>
http://toi.bk.tudelft.nl/toi-pedia/index.php?title=Rendering_Mental_Ray:_Tone_mapping
> 
>   Am I understanding correctly that "tone mapping" is nothing else than
> a function which takes one parameter, namely a brightness value (eg. of a
> color channel), and returns a brigthness value (usually the input value
> multiplied by some function)?
> 
>   Could it also be a function taking three parameters, namely the red,
> green and blue components of the color, and returning a vector?

No, it can be much more complex than that. Go "Up" twice on the page whose
link I posted. It is actually from a dissertation discussing various
functions, some of which require more than a handful of parameters.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> No, it can be much more complex than that. Go "Up" twice on the page whose
> link I posted. It is actually from a dissertation discussing various
> functions, some of which require more than a handful of parameters.

  Could someone write a short summary?

  If it's not just a (user-defined) function which takes certain parameters
and returns a value/color, then what is it?

-- 
                                                          - Warp

Post a reply to this message

in news:47302c02@news.povray.org Christoph Hormann wrote:

> Usually you want to be able to 
> control color mapping after the render. 

Yes, but often you don't want to do it in a separate step/application. But 
if I'm not mistaken, gamma correction is now a kind of "postprocessing 
step". Isn't this the same place where tonemapping, colur managent, 
colourspace conversions  etc. should be done.
Such a setup would mean that tonemapping functions (or gamma-curves) won't 
be specified in the scene itself but in a "postprocessing-ini-file".

Ingo

Post a reply to this message

Warp wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>> No, it can be much more complex than that. Go "Up" twice on the page whose
>> link I posted. It is actually from a dissertation discussing various
>> functions, some of which require more than a handful of parameters.
> 
>   Could someone write a short summary?
> 
>   If it's not just a (user-defined) function which takes certain parameters
> and returns a value/color, then what is it?

A algorithm with up to n**2 complexity per pixel afaict (wthout checking in
detail) from some of the existing algorithms.

	Thorsten

Post a reply to this message

Warp nous apporta ses lumieres en ce 2007/11/05 22:19:
> Trevor G Quayle <Tin### [at] hotmailcom> wrote:
>> 1) System variables to return the resolution of an input image.  This appears to
>> be already available in the source code, just not passed on to the SDL.
> 
>   This should definitely be doable, but I'll have to ask the team about
> their opinion. (Cons: Minor feature, increases reserved keyword clutter...)
>

We already have image_width and image_height, why not reuse it with this 
variation: when included with an image that is loaded, it returns the dimentions 
of that image instead of that of the rendered image.
It could look somewhat like:

image_map{jpg "MyImage.jpg" Width = image_width, Height = image_hight, [your 
other parameters]}



-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you can no longer tell the 
difference between the top raytracing book and the "Raytracing for Dummies" 
book. To you, they're both hopelessly uninformed.
     -- Taps a.k.a. Tapio Vocadlo

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> Warp nous apporta ses lumieres en ce 2007/11/05 22:19:
> > Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> >> 1) System variables to return the resolution of an input image.  This appears to
> >> be already available in the source code, just not passed on to the SDL.
> >
> >   This should definitely be doable, but I'll have to ask the team about
> > their opinion. (Cons: Minor feature, increases reserved keyword clutter...)
> >
>
> We already have image_width and image_height, why not reuse it with this
> variation: when included with an image that is loaded, it returns the dimentions
> of that image instead of that of the rendered image.
> It could look somewhat like:
>
> image_map{jpg "MyImage.jpg" Width = image_width, Height = image_hight, [your
> other parameters]}
>
>

Unfortuneately image_map can't be declared explicitly like:
#declare A=image_map{jpg "MyImage.jpg"} so using it this way would require it to
be applied to something (mind you it could be just a dummy pigment, but this
seems un-neat to me).


I would see it working more similar to min_extent/max_extent maybe:

#declare A=resolution{jpg "MyImage.jpg"};

or perhaps min_extent/max_extent could be reused to avoid adding a new
keyword(in this case min_extent would always be <0,0> or it could be just left
out)

-tgq

Post a reply to this message