 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmx de> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> A algorithm with up to n**2 complexity per pixel afaict (wthout checking in
> detail) from some of the existing algorithms.
With n being what?
Well, anyways, this sounds all too complicated. I'm doing this just as
a hobby, not as my payjob. I'm not finding too much motivation to study
dozens of pages of complicated math for this. Unless someone can give me
a simple algorithm I can implement, I'm really sorry.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> 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).
It's perfectly possible and in fact quite easy to do something like this:
#declare Im = pigment { image_map { jpg "MyImage" } };
#declare R = max_extent(Im);
and then R.x would be the width of the image and R.y the height.
(I actually went ahead and implemented this just to see if it would work,
and it worked like a charm.)
The only question is whether max_extent() is the suitable function for
this.
It has been suggested that image_width, when used as a function (and given
the image map pigment identifier as parameter) would return the width of the
image, and likewise image_height the height, but I'm not completely sure how
trivial this is to implement in the parser because these keywords are already
used as float identifiers. It would mean that when parsing these keywords the
parser would have to look for an optional opening parenthesis after it, and
if it appears, behave differently. I haven't yet looked, but my past
experience in trying this "check for an optional syntax element" with the
current parser has been daunting. (More precisely, I tried to implement
concatenation of strings using the + operator. I hit a wall.)
(max_extent() doesn't have this problem because it's already a vector
function, and thus it's simply a question of checking the type of the
parameter. This is very trivial to implement in the parser.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
