[ptx] Hugin wishlist, RFC

[alexandre jenny]

That's an interesting wish list ...
Let's talk a little about it !

> 1. Band blending (or some other intelligent blending)
> 
>    Even with setting every capture parameter at my camera to 
> some fixed value, I still end up having differently exposed 
> images that hardly match up, even with large feathering. 
> Adjusting brightness kills the blue sky in most images, 
> adjust color paints them pink. Adjusting both does both.

Of course, it's the next part we have to work on (after finishing automatic
Point creation).
There's 2 points :
 - exposures compensation for matching
   * This part could be done by using the same approach as Dr hersch for
panotools, with
   one change : What he does is fitting neighboors histograms by solving a
256 variables
   matrices. He does that from the anchor picture to the last one, but
doesn't count about
   a strange case where circular reference occurs, for 360 for example. So
we have to do
   it in one pass : having a big 256*nb picture matrice solved in one pass,
using some
   over contraints to say that each histogram should not be disturbed too
much. And that should
   work great without any of the issues of panotools.
   * Other approach would to directly calculate a HDR pixels value using
different pixels values
   and exif parameters. But that's for future after having a good algorithm
working.
 - blending algorithm to match 2 right exposed pictures.
   ( this one can be done by current stage of nona, but can be improuved to
used for
    example a multi spectral blending sheme).

> 2. Incremental optimization
> 
>    I think Pablo started this already, and it definetely will 
> easy panorama creation, especially for the beginners. This 
> gets around the incremental manual "position estimation", and 
> successive optimization afterwards.

Pablo is doing it.
We can also think of implementing the hough transform in hugin to have a
good starting point from
the manually located controls points (The same hough transform as in sift
for panorama).

> 3. Automatic panorama control point creation
> 
>    Alexandre did a replacement to the keypoints binary 
> (Alexandre: how far is t? Can I help/review?). Though for now 
> I am happy with my version, such a tool shipping with hugin 
> would be great. To be usable for everybody it must contain 
> some geometric matching code, though. The current matching is 
> sufficient for us, as we just get rid of the wrong control 
> points after the first optimization by deleting the worst 
> ones, but a beginner might find this difficult. Also, it must 
> have some penalty function so that clustering of control 
> points is purged in favor of more spacious matches. (That is: 
> the polygon area of all matching control points should be 
> large, not just a small cluster at some easy features)

So my big part. Well sebastian, I rewrote in c++ the whole algorithm. And
I solved many of the uncovered code : for example : I pretty sure to have
achieved
the scale invariance by using a 3D fitting sheme with a hessian matrice.
I still have some issues with the real calculation of feature vector and I
will
mail you about that.
Moreover, I discovered some way to optimize the sift detection in the case
of panorama,
which allows us to run below 2s for detection of a 800x600 (Actually in
debug mode,
I'm around 10-15s for a 800x600 on an athlon 1.33 ghz).
But I have to solve the last issues to check that.

> 4. "Horizon points"
> 
>    I find the idea of setting horizontal lines 
> counter-intuitive. Maybe to straighten the top of a gate or 
> building, but to straighten the horizon I think this is more 
> intuitive: Allow the user to drop points where he expects the 
> horizon ("horizon points"). This points, of which there have 
> to be at least 2 are used for two things: anchoring the 
> height to 0 degrees, and creating horizontal line control 
> point pairs between them (invisible to the user). Most people 
> have a very good idea where the horizon is located, even if 
> its completely covered with buildings and trees and such 
> (must be some evolutional thing).

In Realviz stitcher, they have such a function which is called horizontal
line.

> 5. Unneccessary picture detection
> 
>    As I like to take panoramas just manually I sometimes lose 
> the "map" of what areas I already captured and capture more, 
> just to be sure. This ends up in bogus pictures, overlaying 
> some other pictures, but they are of no real use. They slow 
> down optimization and panorama creation. Hugin could suggest 
> such pictures for removal.

... No comment ... I doesn't do that ;-)

> 6. "Camera profiles"
> 
>    My digicam (and I guess lots of others) use some screwed 
> focal length (7.8mm to 24mm something) being "equivalent" to 
> some 38mm camera. For use with hugin I have to use 38mm, but 
> the EXIF information reads 7.8mm. I guess it would help most 
> users to use some kind of "camera profile", where they can 
> specify one time the focal length and later choose the camera 
> profile to use, instead of doing manual adjustment everytime 
> they import pictures.

... No comment again ... 



Bye
    Alexandre