![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
The files are in the zip!
~Sam
Post a reply to this message
Attachments:
Download 'cubic_interpolation.zip' (3 KB)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Vincent Le Chevalier
Subject: Re: cubic interpolation for image_maps
Date: 10 Mar 2007 18:04:25
Message: <45f33979@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Following the discussion in povray.binaries.images under the same
subject, here is my implementation of the bicubic interpolation.
The archive contains a scene file with the macro used for the
interpolation (could probably easily put in an include file if need be)
and an example TGA height field to test it on.
The implementation here is quite slow because it uses many function
calls. On the other hand, you could probably tweak it to have
interesting effects (for example by twisting the slope computation...).
Anyhow it is quite necessary when you want to blend image data with
procedural patterns in POV-Ray, because the internal interpolation
methods are more visible. I sure hope to see a similar internal method
in future official versions of POV-Ray...
And my thanks to Samuel for making me rediscover and clean up my old
code ;-)
Regards
--
Vincent
Post a reply to this message
Attachments:
Download 'interpolation.zip' (8 KB)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Vincent Le Chevalier wrote:
> Following the discussion in povray.binaries.images under the same
> subject, here is my implementation of the bicubic interpolation.
>
> The archive contains a scene file with the macro used for the
> interpolation (could probably easily put in an include file if need be)
> and an example TGA height field to test it on.
>
> The implementation here is quite slow because it uses many function
> calls.
Whoah. I'm inclined to call it slow, considering it took 1m 36s just to
parse!
> On the other hand, you could probably tweak it to have
> interesting effects (for example by twisting the slope computation...).
> Anyhow it is quite necessary when you want to blend image data with
> procedural patterns in POV-Ray, because the internal interpolation
> methods are more visible. I sure hope to see a similar internal method
> in future official versions of POV-Ray...
Upon closer inspection of the rendered image, I see that it shares
similar "step" artifacts as can be found with the blended cells
implementation, albeit yours are much less pronounced.
> And my thanks to Samuel for making me rediscover and clean up my old
> code ;-)
>
> Regards
Hey, any time I can help :)
~Sam
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Vincent Le Chevalier wrote:
>> The implementation here is quite slow because it uses many function
>> calls.
>
> Whoah. I'm inclined to call it slow, considering it took 1m 36s just
> to parse!
O:-)
OK, maybe I should have said 'very slow' then :-)
Back when I was playing with that I chose to use a height field built at
parse time, because when used in an isosurface... It's even slower. At
least after parsing the render goes quick.
> Upon closer inspection of the rendered image, I see that it shares
> similar "step" artifacts as can be found with the blended cells
> implementation, albeit yours are much less pronounced.
Yep, I saw those too.
I think that what we see here are discontinuities in the second
derivative, i.e. the slope is perfectly continuous but we can still see
that its rate of variation is not. The glossy finish also makes those
stand out.
Well, either that, or my implementation is wrong because the first
derivative *should* be continuous ;-)
Is there the same kind of effects with Megapov's interpolate 3 ?
Best
--
Vincent
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Is there the same kind of effects with Megapov's interpolate 3 ?
I just downloaded Megapov and tried interpolate 3, and I have the same
result. Well, almost... There are strange things at the border, maybe
because I have some offset. But the 'step' effect is indeed there.
I feel reassured for my code, it is still slow but at least it does what
I think it does :-)
Regards
--
Vincent
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Vincent Le Chevalier wrote:
>> Is there the same kind of effects with Megapov's interpolate 3 ?
>
> I just downloaded Megapov and tried interpolate 3, and I have the same
> result. Well, almost... There are strange things at the border, maybe
> because I have some offset. But the 'step' effect is indeed there.
There is a bug with interpolate 3, now that you mention it. When you
wrap the interpolated image inside a pigment_pattern, the white portions
of the image turn black....
~Sam
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> There is a bug with interpolate 3, now that you mention it. When you
> wrap the interpolated image inside a pigment_pattern, the white portions
> of the image turn black....
>
That could be because the values are not clipped to [0,1] after the
interpolation. IIRC in a pigment_pattern, only the fractional part is
taken into account, i.e. if the pigment value is 1.1, higher than white,
it is mapped to 0.1, nearly black.
Even if all grid points have values between 0 and 1, with the bicubic
interpolation you can get values out of that range. This does not happen
with bilinear interpolation.
In my code I have a choice to clip or not the value, in Megapov I don't
know what choice has been made...
Regards
--
Vincent
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |