Grassblade wrote:
> I don't think that's the effect you were looking for. I have taken a look at
> your code, and if I understand correctly, you are making interpolation pixel
> per pixel, but with cubic interpolation you need 4 pixels, so if you are
> repeating it on the next pixel, you are overlapping the previous
> interplation. I've never tried it, but I think you should skip to the next
> block of 4*4 pixels (or maybe 3*3, considering continuity/differentiability
> of the block's edges).
> 

Hmm, you may be right. Christoph pointed me toward a new version of 
MegaPOV which does what I want. If that works, then I won't improve my code.

~Sam

Post a reply to this message

"Samuel Benge" <stb### [at] hotmailcom> wrote in message 
news:45eef8a7$1@news.povray.org...
> I was hoping that Tek's blended cells technique would work well for 
> height_fields, but as it turns out, those extra "Steps" don't look so 
> good... maybe if other things were done to the pigment it would be good. 
> Oh well :) I figured I should post it anyway.

IMO the problem is it's only blending to the adjacent cell, and it always 
uses pov's cubic curve rather than trying to maintain a smooth gradient. If 
I'm understanding correctly Vincent's technique was actually doing cubic 
interpolation, rather than just using cubic_wave (which isn't equivalent)...

Of course I'm saying all this without checking anyone's source code, but 
since it's based on my blended cells I would expect it to create curved 
steps where there should be a smooth gradient, which would cause the problem 
you're seeing.

Wow I explained that really badly!

-- 
Tek
http://evilsuperbrain.com

Post a reply to this message

> If I'm understanding correctly Vincent's technique was actually doing
> cubic interpolation, rather than just using cubic_wave (which isn't
> equivalent)...
> 

Well I don't know if it was cubic interpolation proper, but looking at
my code it seems that I was attempting to keep a continuous slope at
each vertex, and likely along the sides of the cells as well. Indeed
there is a cubic polynomial (degree 3 in x and 3 in y, in fact) looming
in there, but no cubic_wave...

For now my code is horribly mangled, because it is doing some other
things such as blending with another pattern, etc. and I never tried to
extract the interpolation from there. I'll try to single out and clean
up this part, then post it.

I'm not too sure about the efficiency of my technique either, I
implemented everything with functions, and thus it spends a lot of time
re-computing things that could have been stored... I don't remember
exactly why I did it like that. It seems I have another non-working
version where I tried to use arrays... There could have been something
about being unable to read an array from inside a function, I believe.

-- 
Vincent

Post a reply to this message

Tek wrote:
> "Samuel Benge" <stb### [at] hotmailcom> wrote in message 
> news:45eef8a7$1@news.povray.org...
>I figured I should post it anyway.
> 
> IMO the problem is it's only blending to the adjacent cell, and it always 
> uses pov's cubic curve rather than trying to maintain a smooth gradient.

Yes, I was hoping to control that with a poly_wave n statement after a 
cubic_mapped pigment_pattern, but it didn't work out very well. The 
cubic wave is still expressed in the same way, only shifted one way or 
another.

> If 
> I'm understanding correctly Vincent's technique was actually doing cubic 
> interpolation, rather than just using cubic_wave (which isn't equivalent)...
> 
> Of course I'm saying all this without checking anyone's source code, but 
> since it's based on my blended cells I would expect it to create curved 
> steps where there should be a smooth gradient, which would cause the problem 
> you're seeing.
> 
> Wow I explained that really badly!

Maybe so, but I understand why there are steps. I don't like it, but at 
least I have the newest version of MegaPOV now. It supports bi-cubic 
interpolation for image maps :)

~Sam

Post a reply to this message

If you really wanted to do it with my system, which would not be a good 
idea, you'd need to overlap 4 copies of the pattern on every axis, so 16 for 
an image, with each component being adjusted to behave like a part in a 
cubic formula to create a nice curve through the surfaces.

My system just blends between 2 values, but to get a nice smooth slope you 
need to blend 4 using a much more complex formula.

-- 
Tek
http://evilsuperbrain.com


"Samuel Benge" <stb### [at] hotmailcom> wrote in message 
news:45f04c0e$1@news.povray.org...
> Tek wrote:
>> "Samuel Benge" <stb### [at] hotmailcom> wrote in message 
>> news:45eef8a7$1@news.povray.org...
>>I figured I should post it anyway.
>>
>> IMO the problem is it's only blending to the adjacent cell, and it always 
>> uses pov's cubic curve rather than trying to maintain a smooth gradient.
>
> Yes, I was hoping to control that with a poly_wave n statement after a 
> cubic_mapped pigment_pattern, but it didn't work out very well. The cubic 
> wave is still expressed in the same way, only shifted one way or another.
>
>> If I'm understanding correctly Vincent's technique was actually doing 
>> cubic interpolation, rather than just using cubic_wave (which isn't 
>> equivalent)...
>>
>> Of course I'm saying all this without checking anyone's source code, but 
>> since it's based on my blended cells I would expect it to create curved 
>> steps where there should be a smooth gradient, which would cause the 
>> problem you're seeing.
>>
>> Wow I explained that really badly!
>
> Maybe so, but I understand why there are steps. I don't like it, but at 
> least I have the newest version of MegaPOV now. It supports bi-cubic 
> interpolation for image maps :)
>
> ~Sam
>

Post a reply to this message

There is an interpolation method, based on signal-processing techniques,
known as 'Whittaker interpolation' that can be extended at 2 dimensions,
and therefore applies to 2-D data (diagrams, images or whatsoever that can
be expressed as f(u, v)). This method makes good interpolations and gives
good results.

The formula (seen in a book!) is:

Being given E(ui, vj), with i in [1..N], j in [1..M} the grid value of the
data in question, and with steps du in u and dv in v, the value of E in a
point (u, v) is given by:

        N    M
       ---- ----
                      sin(PI*(u-u1)/du - i*PI) sin(PI*(v-v1)/dv - j*PI)
E(u,v)=/    /   E(ui,vj)------------------------ ------------------------
       ---  ---           PI*(u-u1)/du - i*PI     PI*(v-v1)/dv - j*PI
         i=1  j=1

OK it is quite a complicated formula, and I apologize, but perhaps POV-team
members who have implemented math-related features in POV can understand
and give an opinion.

However, there must be somewhere well-known image-processing techniques to
perform interpolations. If some of you are fresh engineers ...


    Bruno

Post a reply to this message

> Being given E(ui, vj), with i in [1..N], j in [1..M} the grid value of the
> data in question, and with steps du in u and dv in v, the value of E in a
> point (u, v) is given by:
> 
>         N    M
>        ---- ----
>                       sin(PI*(u-u1)/du - i*PI) sin(PI*(v-v1)/dv - j*PI)
> E(u,v)=/    /   E(ui,vj)------------------------ ------------------------
>        ---  ---           PI*(u-u1)/du - i*PI     PI*(v-v1)/dv - j*PI
>          i=1  j=1
> 

Yes, I heard about this before. In fact, what this formula does is 
summing plenty of 2D sinc functions, one for each point of the grid. The 
scaling with PI is merely to ensure that each sinc is zero at all grid 
points, except the one it is centered on.

This interpolation is indeed good in signal processing, because if I 
remember correctly, it does not add frequencies higher than the sampling 
you already have from the grid.

But it seems prohibitive to compute, since you must consider every point 
of the grid each time you need a value. It can be sped up by considering 
a limited set of neighbours, but then it becomes tricky to ensure that 
the value and derivative(s) stay continuous.

-- 
Vincent

Post a reply to this message

Vincent Le Chevalier <gal### [at] libertyALLsurfSPAMfr> wrote:

> > Being given E(ui, vj), with i in [1..N], j in [1..M} the grid value of the
> > data in question, and with steps du in u and dv in v, the value of E in a
> > point (u, v) is given by:
> >
> >         N    M
> >        ---- ----
> >                       sin(PI*(u-u1)/du - i*PI) sin(PI*(v-v1)/dv - j*PI)
> > E(u,v)=/    /   E(ui,vj)------------------------ ------------------------
> >        ---  ---           PI*(u-u1)/du - i*PI     PI*(v-v1)/dv - j*PI
> >          i=1  j=1
> >
>
> Yes, I heard about this before. In fact, what this formula does is
> summing plenty of 2D sinc functions, one for each point of the grid. The
> scaling with PI is merely to ensure that each sinc is zero at all grid
> points, except the one it is centered on.
>
> This interpolation is indeed good in signal processing, because if I
> remember correctly, it does not add frequencies higher than the sampling
> you already have from the grid.
>
> But it seems prohibitive to compute, since you must consider every point
> of the grid each time you need a value. It can be sped up by considering
> a limited set of neighbours, but then it becomes tricky to ensure that
> the value and derivative(s) stay continuous.
>
> --
> Vincent

You're right, it is not costless. But I have an application using it and it
works quite fast. You might use this interpolation only if you want quality
and/or if the extra computation time is neglectable wrt the rest of the
image. Many things are a compromise.

In addition, you should not retrict the neighbours otherwise you'll get
ondulations (you obviously studied signal processing :)).

    Bruno

PS: here's an interresting link:
http://www.cambridgeincolour.com/tutorials/image-interpolation.htm

Post a reply to this message

> An easy-to-use macro of your technique would be useful, if it 
> renders/parses quickly. It is an improvement over linear
> interpolation, that much is evident.
> 

I posted a macro version of my technique under your thread with the same
subject in povray.binaries.scene-files. I wouldn't say it is quick...
But I don't really know if a quicker implementation can be done.

Of course since it is in Megapov now the incentive to optimize is a bit
diminished :-)

However, as I said in my message over at povray.binaries.scene-files, I
believe you could make interesting things by tweaking the computation a
bit. Since the bicubic method needs the slope at each grid point, you
could specify anything, not necessarily deducing it from the data as
I've done.

I also made a new comparison of the bilinear and bicubic methods using
this new scene file and a lower-res height field, see the attachment.

Regards,

-- 
Vincent

Post a reply to this message

Attachments:
Download 'interpolations.jpg' (72 KB)

Preview of image 'interpolations.jpg'

Vincent Le Chevalier wrote:
> 
> I posted a macro version of my technique under your thread with the same
> subject in povray.binaries.scene-files. I wouldn't say it is quick...
> But I don't really know if a quicker implementation can be done.

Okay, I'll give it a look. There's always something to learn from 
techniques like this :)

> Of course since it is in Megapov now the incentive to optimize is a bit
> diminished :-)

Tell me about it!

> However, as I said in my message over at povray.binaries.scene-files, I
> believe you could make interesting things by tweaking the computation a
> bit. Since the bicubic method needs the slope at each grid point, you
> could specify anything, not necessarily deducing it from the data as
> I've done.
> 
> I also made a new comparison of the bilinear and bicubic methods using
> this new scene file and a lower-res height field, see the attachment.
> 
> Regards,

Looks good. Perfect, even.

~Sam

Post a reply to this message