 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmx de> a écrit dans le message de news:
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> a écrit dans le message de news:
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> 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 a 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 float
> 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
I like the way you've shown it. Would it not be cleaner to do it direectly with
out the dummy pigment?
#declare R = max_extent(jpg "MyImage");
I think this would be more inuitive. Or is this more difficult to implement?
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> I like the way you've shown it. Would it not be cleaner to do it direectly with
> out the dummy pigment?
> #declare R = max_extent(jpg "MyImage");
> I think this would be more inuitive. Or is this more difficult to implement?
I would have to implement a "read only the header of a given image file,
but not the image itself", which would be rather laborious. Reading the
entire image file (and then just dropping it) would be a waste. Could as
well just do that into a pigment identifier.
Besides, I don't think your suggestion is more intuitive. In fact, quite
counter-intuitive because it makes a function act nothing like other similar
functions.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> 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.
FYI, when I was looking into this years ago, I pushed it back as too much
work for too little gain ;-)
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> a écrit dans le message de news:
4730da10@news.povray.org...
> 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.
Perhaps I'm wrong, but the typical color mapping that is found in most
renderers seems to be a much more simple thing and to belong to the "global
operators" class described in the Wikipedia article. It's even implemented
in free renderers like Indigo and Kerkythea, so I tend to assume that the
basics are well known to CG programmers. In any case, the exposure control
from Megapov would be a good start already.
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran <gitran_nospam_@wanadoo.fr> wrote:
> Perhaps I'm wrong, but the typical color mapping that is found in most
> renderers seems to be a much more simple thing and to belong to the "global
> operators" class described in the Wikipedia article. It's even implemented
> in free renderers like Indigo and Kerkythea, so I tend to assume that the
> basics are well known to CG programmers. In any case, the exposure control
> from Megapov would be a good start already.
I'm wondering that you mentioned tone mapping in relation to area lights,
yet from what I see it's not related to area lights at all, but it's simply
a post-processing step, in practice a function from unclamped pixel values
(of the final rendered image) to clamped ones.
Post-processing in POV-Ray is such a beast that I really don't want to
get my hands dirty on it. It's something for pov4.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran schrieb:
>
>>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. [...]
I am not sure if photoshop offers the features necessary for that but my
point is you will want to be able to *change* the tone mapping after the
render even if you already set some mapping function before the render.
Having a tone mapping feature in the render display would certainly be
nice, especially with a separate post processing program being able to
apply the same adjustments to the render output (this could be a simple
filter like the netpbm tools). But being only able to do the tone
mapping during the render or not at all would be the wrong way i think.
-- Christoph
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp nous apporta ses lumieres en ce 2007/11/06 16:32:
> 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.)
>
It looks like using max_extent() would be a beter option than the one I
proposed. Easier to implement and use, at least, it look like it's so.
--
Alain
-------------------------------------------------
Did you know that SATAN is an anagram for SANTA?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> At least for now the full illumination will by default be off (so it
> will work as currently), but it can be turned on with a new keyword inside
> the light_source definition block.
Warp,
Coming in late to this thread I'm afraid, but I thought I'd add my thanks for
implementing this feature. Should add a lot to realism.
Is this option available in beta 23, or will we need to wait for beta 24 to test
this? I've lost track of when b23 came out.
On a related area light point, do you know if the area light axes transform bug
(as noted in
http://news.povray.org/web.4694c449b02d2b905e1e98150%40news.povray.org ) will
be fixed in b24? It's still there in b23.
Mike.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Andrews <nomail@nomail> wrote:
> Is this option available in beta 23, or will we need to wait for beta 24 to test
> this? I've lost track of when b23 came out.
It should be in the next beta that comes out.
> On a related area light point, do you know if the area light axes transform bug
> (as noted in
> http://news.povray.org/web.4694c449b02d2b905e1e98150%40news.povray.org ) will
> be fixed in b24? It's still there in b23.
Probably not. I might look into this.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Mike Andrews <nomail@nomail> wrote:
> > Is this option available in beta 23, or will we need to wait for beta 24 to test
> > this? I've lost track of when b23 came out.
>
> It should be in the next beta that comes out.
Thanks, I look forward to testing this.
>
> > On a related area light point, do you know if the area light axes transform bug
> > (as noted in
> > http://news.povray.org/web.4694c449b02d2b905e1e98150%40news.povray.org ) will
> > be fixed in b24? It's still there in b23.
>
> Probably not. I might look into this.
It's not a big problem - it has been present since at least 3.6, probably
earlier, without anyone else commenting on it that I could see - but it appears
to have a very simple fix.
>
> --
> - Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
