Hi,
The initial seam line generation I wrote is a nearest feature
transform based on voronoi transformation (Breu et al). There is a bug
in my implementation. I have a half-complete repair that is not
checked in yet, and Christoph has a repair in his staging branch. I
intend to replace the algorithm entirely with Danielsson's 4SED. I
also plan to write a version that computes the distance transform on
the surface of a sphere for full-360 images. Lack of time is the
primary factor holding back these projects.
The seam line optimization uses a two-step approach influenced by
research on active contours. The overlap region between an image pair
is treated as a cost function. Areas of disagreement and areas outside
the intersection region have high cost. First, the result of the
nearest feature transform is vectorized into a polyline, and a
generalized deterministic annealing algorithm is used to adjust the
vertex positions to optimize the cost of the line. The line is
penalized for crossing areas of high cost and vertices are penalized
for moving far from their initial positions in the center of the
overlap region. Second, Dijkstra's shortest path algorithm is used to
fill in the exact seam line between polyline vertices.
If you are interested in working on the seam line optimization, some
points to consider are:
- How to handle seams that are closed contours, e.g. the kind of
overlaps that are formed when patching the zenith or nadir of a
full-360 panorama.
- How to reduce the state space of the optimization to maintain
acceptable performance
- How to avoid geometrically uninteresting seam solutions, such as
seam lines that double back on themselves.
- How to encode the abstract notion of "seam invisibility" as the
optimization goal.
- How to identify image features that should or should not appear in
the final panorama.
I think these are all interesting problems and would be happy to
discuss ideas with you.
Andrew
On Sat, Jun 13, 2009 at 5:42 AM, cspiel <csp...@freenet.de> wrote:
>
> Tago -
>
> On Jun 12, 10:06 am, tago <liquidt...@gmail.com> wrote:
>> Why zero?
>
> If you are on the border, i.e. at the
> red or green lines then the distance to the
> respective border is zero.
>
>
>> If I start the line in the middle of the overlap wouldn't
>> the horizontal distance between red and green borders exactly half of
>> the overlap width ?
>
> What is the middle? How would you
> define it? Does your definition also hold if
> you turn the the example 90 degrees?
>
> As I said before the problem is manifestly
> two-dimensional. Just looking at one border is
> not enough. We must look at _all_ borders at
> the same time to find out what is the minimum
> distance to any of them.
>
>
>> Is the line generation based on something like the grassfire
>> transform ?
>
> I'm sorry, but I cannot tell you what
> Enblend's original algorithm is based upon,
> because I never understood it. 8-|
>
> The new algorithm employed in the "staging"
> branch uses two nearest neighbor transforms
> (NNT) of the differences between the mask files
> A and B. It constructs the seam mask by
> assigning zeros to pixels closer to the borders
> of A-B and ones to pixels closer to the borders
> of B-A. The boundary between the zeros and the
> ones makes up the initial seam line.
>
> You see that neither the computationally
> expensive Grassfire-, nor Watershed-
> transformations are necessary. The final
> assignment step is a point-wise operation and
> thus of linear complexity in the image size. It
> parallelizes trivially.
>
> Latest revisions of "staging" do compute both
> NNTs in parallel threads, too, given the project
> has been configured with "--disable-image-cache
> --enable-openmp" and the compiler supports
> OpenMP.
>
>
>> Are there details on how optimization works ?
>
> I guess there are lots of them! It is
> just that I have not looked at the seam-line
> optimization close enough to tell you what is
> going on there. What about you inspecting it
> and teaching me?
>
>
>> I guess one needs to
>> find a line that does not pass thru mismatches (i.e. parallax or
>> moving objects).
>
> As far as I understand, this is the way
> Enblend works. It would explain why SmartBlend
> sometimes produces superior output.
>
> I have an idea of how to improve on the
> optimization, though. Hopefully, it will take
> us on a par with SmartBlend. (Kornel will love
> to hear this;)
>
>
> HTH,
> Chris
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
