hugin-devs team mailing list archive

[rew <936090@xxxxxxxxxxxxxxxxxx>]

Bruno & others,

I've decided to make a low-res (because of data-size reasons) version of
my project available.

At http://prive.bitwizard.nl/demo.zip you can find a 78Mb file that
contains 380 pictures I took.  (I took about double that amount, this is
just the run until the battery ran out. I now know I need to start out
with a full battery).

There is a "doit" script that shows how I generated the test_pre.pto,
test_pre2.pto and test.pto. Treasure that test.pto, as I've made it with
my patched cpfind.

I'm NOT asking you to do my work. What I want is to be able to stitch
this type of project with reasonable amounts of human intervention time
using hugin. I hereby invite you to run this project through hugin and
see how you evaluate the experience.  It is not about the resulting
stitch. It is about the process of generating that stitch.  This is just
a test-shot that I took to test the hugin stitching process.

If you find that this is possible with hugin at this time, please
document the process for me. I'll try to expand your notes into the
documentation wiki for others to use.

Please note that with the current layout that is generated by my "blind
estimation" script, the horizon is generally straight, but has a small
step at the edge of each image. The results I get often have the horizon
shaped into an S-shape. This is not realistic.

-- 
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