Hi,
I suspect a problem in the vectorization of the seam lines. There
is currently no checking that the MaskVectorizeDistance parameter is
suitable for the number of actual pixels on the seam (the points
visited by the CrackContourCirculator). Thus we can construct snakes
that undersample the seam and have only one or two vertices. This is
likely to happen when the distance transform result has many small,
fragmented patches. For each seam we should compute an appropriate
MaskVectorizeDistance heuristically.
The condition that leads to the error message "mask is entirely black,
but the white image was not identified as redundant" also needs to be
examined. If the seam optimization is allowed to remove snakes
entirely, either because the vectorization decides the contour is too
small or because the annealer collapses the contour, then this
condition should not be an error. The white image does have pixels to
contribute (according to the distance transform), but the optimization
decided that it was not worthwhile to blend them in.
Currently the optimization does not consider the contour area as a
constraint. I think this requires more thought. Should the
optimization be allowed to collapse contours or is this a bug?
Andrew
On Sat, Oct 17, 2009 at 5:23 AM, cspiel <[email protected]> wrote:
>
> Roger -
>
> On Oct 16, 11:53 am, Rogier Wolff <[email protected]>
> wrote:
>> Most people are not this familiar
>> with the code, and simply fire up a GUI. The hugin-0.7.0 gui, I
>> suspect simply blended all the images from an exposure stack.
>
> What do you suggest Enblend should do?
> Should it detect an almost complete overlap
> of a pair of images and report the problem to
> the user? This would be very helpful in the
> case we discuss here, but lead us to the problem
> of how to identify these pairs of images.
> Furthermore, how can we code this efficiently?
>
>
>> It is a funny situation that only crashes enblend in weird
>> circumstances, but it is still a bug in enblend that is good to have
>> fixed. So even though the original test-data is a bit nonsensical, it
>> did allow us to find and fix a bug.
>
> You are totally right. Enblend must
> behave even with nonsensical data. Right now
> the Distance Transform routine goes ballistic
> when two images almost completely overlap. I
> have some ideas, but I'm also curious of your
> suggestions.
>
>
> /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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
