[ptx] Enblend Multiresolution Spline Blender

[Andrew C Mihal]

On Wed, 10 Mar 2004, Pablo d'Angelo wrote:

> Usually, the overlaps are quite regular (no holes etc.). I think it should
> be possible to use this method. But probably I missed something, can you
> explain where you see the problems?

Ok, here comes the ascii art. Here is the line that enblend currently 
chooses:

     +---------------------------------+   /
     |                                 |/
     |               +-----------------+---------------------+
     |               |                /|                     |
     |               |             /   |                     |
     |               |          /      |                     |
     |               |         |       |                     |
     |               |         |       |                     |
     |               |        /        |                     |
     |               |     /           |                     |
     |               |  /              |                     |
     |               |/                |                     |
     +---------------+-----------------+                     |
                    /|                                       |
                 /   +---------------------------------------+


The idea is that the line is equidistant from the zones where there is 
only one image providing data.

With the distance-from-image-center method, the line you get is the 
perpendicular bisector of the centers of the two images.

     +---------------------------/-----+
     |                           |  A  |
     |               +----------/------+---------------------+
     |               |          |      |                     |
     |               |         /       |                     |
     |               |         |       |                     |
     |               |        /        |                     |
     |               |        |        |                     |
     |               |       /         |                     |
     |               |       |         |                     |
     |               |      /          |                     |
     |               |      |          |                     |
     +---------------+-----/-----------+                     |
                     | B   |                                 |
                     +----/----------------------------------+

Here the transition line goes through both regions where there is only one 
image providing data (A and B). In the pyrmask program, this would cause 
image artifacts because the little regions where the A and B are would be 
blended to nothing. Because pyrmask did not handle the alpha channel 
correctly, "nothing" meant pure black. So regions A and B would be 
noticeably darker, and there were visible seam lines when you cross from A 
or B into the main intersection region in the middle.

When you get to smaller pyramid levels, the transition line starts to
spread out. So even in the first figure there is going to be a set of
pixels that are in the blend region but are not in the overlap region -
but it should be a smaller set of pixels. I handle this case specially in
enblend by extrapolating pixels off the edges of the images. So there
might not be a problem in enblend using the line you suggest. I'll have to
test it out and see what happens.

> What would you prefer?
> I can to do the conversion to vigra, but it'll take a few days.

I don't know vigra at all. I see that it has a distance transform function 
though, and that could be used to caluclate either of the two types of 
lines above. What's important is the algorithm it uses. If it uses an 
erosive thinning approach like the one in enblend, there will be no 
improvement. I've been looking at a paper on the Nearest Feature Transform 
that should be dramatically faster that thinning - O(n) instead of 
O(n^(3/2)).

I want to do some more math and get a better understanding of what is 
going on at the boundaries of the images in the laplacian pyramids, and 
what is happening to the pixels that are in the blend zone but not in the 
intersection of the two images.

Andrew

---------------------------------
Andrew Mihal
www-cad.eecs.berkeley.edu/~mihal
mihal at eecs.berkeley.edu