hugin-devs team mailing list archive

[rew <936090@xxxxxxxxxxxxxxxxxx>]

I don't understand why matrixmode works so horribly then.

There is a tendency to say: "Oh, but this program can do that too". This
results in complex programs that work when the programmer was thinking
of exactly what you want, and that it won't do what someone else wants
when he wants something slightly different.

So, in my "big" shot, I can currently (with my patch) tell cpfind to
only do detections on the direct neighbours. Just horizontal and
vertical. I can also tell it to do also the diagonal neighbours.

All this is external to cpfind, and making additional choices is easy.

This "make one program do everything" attitude is exactly what hugin
should not be about. If we follow the unix strategy of making small
programs that "do one thing and do it well", then  we have building
blocks that allow us to build great things.

cpfind is the control point finder. THAT is the one thing it should be
built to do, and THAT is what it should do.

Suggestions like: just call it with two files, then it will just read
the cached keypoint files and match between those two files. Well great!
But then you incur the cost of starting up cpfind multiple times. But
also the reading of the cache-keypoint-files. In my case, every keypoint
file would then have to be loaded twice. If I want the diagonal matches
as well, this becomes "four times". I was told that reading the keypoint
file is almost as expensive as doing the keypoint detection again.

Now, when I get my way, and we would separate the overlap-detection into
a separate program, then it would be easy to build a "multirow" mode
again. Just run cpfind, run a quick optimize, run the overlap detection
and run cpfind on the image pairs we haven't done before.  Simple.

If however something goes wrong, or needs adjusting in the middle, there
is an "interface" available where another program can be made that does
the adjusting. Or the user might adjust manually. With the current
situation there is simply NOTHING you can do when it doesn't work
properly. Even debugging is difficult.

Now, take my "big pano" for instance.

I have put all the images on a "regular grid". There is almost 50%
overlap in each direction. Image 0 overlaps with image 1, and with image
19. Image 1 then overlaps with image 0 and 2, and in the next column
with 17, 18, and 19.

If you claim that this is detected by cpfind, then there is something
horribly wrong:

I feed cpfind this "default layout" where there is exactly the same
amount of overlap.

When I run --multirow, after checking 1-2, 2-3 etc up to 378-379, I get:

--- Find matches in images groups ---
i0 <> i8 : Found 0 matches
i0 <> i9 : Found 0 matches
i0 <> i10 : Found 0 matches
i0 <> i11 : Found 0 matches
i0 <> i28 : Found 0 matches
i0 <> i12 : Found 0 matches
i0 <> i29 : Found 0 matches
i0 <> i30 : Found 0 matches
i0 <> i31 : Found 0 matches
i0 <> i32 : Found 0 matches
i0 <> i33 : Found 0 matches
i0 <> i46 : Found 0 matches
i0 <> i47 : Found 0 matches
i0 <> i48 : Found 0 matches
i0 <> i50 : Found 0 matches
i0 <> i49 : Found 0 matches
i0 <> i51 : Found 0 matches
i0 <> i52 : Found 0 matches
i0 <> i53 : Found 0 matches
i0 <> i66 : Found 0 matches
i0 <> i67 : Found 0 matches
i0 <> i68 : Found 0 matches
i0 <> i69 : Found 0 matches
i0 <> i70 : Found 0 matches
i0 <> i72 : Found 0 matches
i0 <> i73 : Found 0 matches
i0 <> i88 : Found 0 matches
i0 <> i89 : Found 0 matches
i0 <> i90 : Found 0 matches
i0 <> i130 : Found 0 matches
i0 <> i131 : Found 0 matches
i0 <> i148 : Found 0 matches
i0 <> i149 : Found 0 matches
i0 <> i150 : Found 0 matches
i0 <> i168 : Found 0 matches
i0 <> i151 : Found 0 matches
i0 <> i169 : Found 0 matches
i0 <> i171 : Found 0 matches
i0 <> i188 : Found 0 matches
i0 <> i172 : Found 0 matches
i0 <> i189 : Found 0 matches
i0 <> i190 : Found 0 matches
i0 <> i191 : Found 0 matches
i0 <> i208 : Found 0 matches
i0 <> i192 : Found 0 matches
i0 <> i209 : Found 0 matches
i0 <> i210 : Found 0 matches
i0 <> i211 : Found 0 matches
i0 <> i212 : Found 0 matches
i0 <> i213 : Found 0 matches
i0 <> i228 : Found 0 matches
i0 <> i229 : Found 0 matches
i0 <> i230 : Found 0 matches
i0 <> i231 : Found 0 matches
i0 <> i271 : Found 0 matches
i0 <> i328 : Found 0 matches
i0 <> i272 : Found 0 matches
i0 <> i329 : Found 0 matches
i0 <> i330 : Found 0 matches
i0 <> i368 : Found 0 matches
i0 <> i370 : Found 0 matches
i0 <> i369 : Found 0 matches
i0 <> i371 : Found 0 matches
i8 <> i9 : Found 0 matches
i0 <> i379 : Found 0 matches
i8 <> i10 : Found 0 matches
i8 <> i11 : Found 0 matches

So it checked 63 pairs that are COMPLETELY BOGUS. It needed to check
0-19 (about 45% overlap) and 0-18 (about 22% overlap). It didn't check
the correct pairs, and it checked 31 times more unnecessary pairs. And
it checked more than 60 times more pairs than I would have wanted it to
do. (I think the layout should become sufficiently "stiff" with the
diagonal matches left out).

Next it doesn't check 1-18 nor 1-17 and 1-19. Similarly it skips some 20
more overlapping images and continues with 8-9. This match has already
been tried. Then it tries 8-10. These two overlap for almost 25%. 0
matches is probably correct, because both images are mostly sky. 8-11.
Good choice. Alas only sky this time.

Then it continues.... 
i8 <> i12 : Found 0 matches
i8 <> i28 : Found 0 matches
i8 <> i29 : Found 0 matches
i8 <> i30 : Found 0 matches
i8 <> i31 : Found 5 matches
i8 <> i32 : Found 0 matches
i8 <> i33 : Found 0 matches
i8 <> i46 : Found 0 matches
i8 <> i48 : Found 0 matches
i8 <> i47 : Found 0 matches
i8 <> i49 : Found 0 matches
i8 <> i50 : Found 0 matches

and finds matches that are bogus. If I can reliably tell it NOT to
search for matches in images that do not overlap these accidents would
not happen.

So far, in trying to stitch my pano, hugin only makes things worse.
There is apparently some play in my mechanics. The odd columns (going
up) are offset a bit from the even ones (going down). That is easily
visible. However in general the layout is WAY better than was I get
after letting cpfind and hugin have their way.

-- 
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/936090

Title:
  cpfind does not handle "matrixmode" correctly.

Status in Hugin - Panorama Tools GUI:
  Triaged

Bug description:
  I'm shooting panoramas in matrix mode. So I do a row, move to the next
  row and then move along the row again.

  for example 16 pictures might be taken as follows:

    0   1    2   3  
    7   6    5   4
    8   9  10 11
  15 14 13 12

  I use the "snake" algorithm to reduce the amount of movement of the
  camera.

  This means that every picture "n" is adjacent to picture "n+1",  but
  also to some picture in the next row. I haven't managed to get
  cpfind's matrixmode to analyse the correct image pairs.

  Determining which images overlap with what others is something that
  cpfind shouldn't be bothered with. I suggest cpfind implements
  "linear" and "all" modes, but nothing else.

  I have implemented a "--checkmatchesfile" option.  If specified cpfind
  will load the image pairs to check from the file.

  For now I "manually" created the pairs-file with a simple shell
  script. However the hugin fast preview layout window also "knows" what
  image pairs overlap. It can easily be modified to output this file! In
  my case I've also written a script that will create an initial layout
  for an empty PTO file. The fast preview/layout window will then know
  "instantly" which images overlap, and should be able to output a nice
  checkmatchesfile for me.

  The improvement in quality of the resulting layout is enormous! 
  (it also seems that my checkmatches list is much shorter than the matrix mode default, so it runs faster too. )

  
  I must admit that my C++ skills are a bit lacking. The ugliest part is in PanoDetector::prepareMatches . There I mostly use C to read the checkmatches file. Someone fluent in C++ can easily translate that to C++. 

  The patch also corrects a typo in RANSACOptimizer::Mode getRansacMode
  . (the name was "setRan...")

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/936090/+subscriptions