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

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