On Sat, Oct 17, 2009 at 05:23:40AM -0700, cspiel wrote:
>
> Roger -
>
> On Oct 16, 11:53 am, Rogier Wolff <rew-googlegro...@bitwizard.nl>
> 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?
The problem is more complex. The normal mode-of-operation of enblend
is: that images are added incrementally. So such an "almost
overlapping" image could very well be completely inside the "already
assembled pixels", which enblend detects, but also, as is probably now
the case, only just outside the currently being-stitched area.
Enblend already detects the case where all pixels are already
accounted for. We could instead of just checking black-or-white wheter
/any/ pixels are new, just count the number of pixels being new. If
this count is very low, it is a hint there is something going on.
Of course, if I take say 3x3 shots (non-bracketed) and overlap them
almost 50%, the center one will have only a small amount of
only-defined-by-this-image pixels, but still be essential for the end
result.
Enblend (by default, I haven't tried the option that changes this
behaviour) adds each image as it goes. It could make a map of "how
many images do I have for this pixel", next for each (non-transparent)
pixel in image X if the count is not equal to one, there are other
images defining this pixel. An image where ALL pixels are marked
not-one, is redundant. Again, it's easy to count the pixels to get a
measure of how redundant each image is.
Just printing this info, will allow hugin to read it and present it to
the user, and this info can be interpreted by a human to do "the right
thing".
For example, I am working on a .7Gpixel panorama. I took the first 8
images with auto-focus on before I noticed this. I then reshot those
images. Of course I didn't remember this when I started stitching
(*). I would've been warned of this situation if enblend had warned
me: Images 0-15 are redundant.
pixels of the source image that overlap other images.
example output:
-------------------------------
overlap image
percentage name
100% p25160000.tif // At least ONE of these images can
p25160001.tif // be removed without affecting the
p25160002.tif // number of pixels in the final image.
p25160003.tif // It could be that removing one
p25160004.tif // makes another image non-redundant.
p25160005.tif
p25160006.tif
p25160007.tif
p25160008.tif
98% p25160034.tif
95% p25160038.tif
92% p25160039.tif
65% p25160021.tif
64% p25160022.tif
63% p25160056.tif
63% p25160023.tif
62% p25160018.tif
62% p25160026.tif
....
-------------------------------
In the case at hand, the "unique pixels from one image" are a small
narrow line of pixels. These are delimited by the edge of the
image. The overlapping region is MUCH larger. This is an obvious
warning sign.
> > 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
OK.
Roger.
(*) Of course you look at the images before stitching starts. However,
they are easily recognized as belonging together and then lumped into
one directory "to be stitched". Then later on I start stiching that
directory I just let the keypoint finder look at them...
--
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
