Fusing before or after

[Bruno Postle]

On Thu 28-May-2009 at 09:40 +0100, paul womack wrote:

>Bruno Postle wrote:
>>
>> Otherwise there are two important hugin options that we don't yet
>> have that will be relatively simple to add with some extra Makefile
>> rules:
>>
>> 1. enfusing stacks as the first step before remapping with nona.
>> 2. enfusing exposure layers as the last step after blending with
>> enfuse.
>
>I imagine that last word should be "enblend" :-)

Yes, or "confuse".

--
Bruno

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Tom Sharpless]

Thanks, Bruno

So align_image_stack does use local correlations, then generates CP's
as a way of communicating the required alignment to other tools?

Is this done in such a way as to allow some warping as well as simple
shifting in the final alignment step?  That is, are the CP's based
only or mainly on local shifts?  If that is the case then I think
these CP's could profitably be fed to libpano's morph-to-fit facility
(or an improved one, if someone would like to write that) in cases
where parallax is a problem.

-- Tom

On May 27, 4:55 pm, Bruno Postle <br...@...> wrote:

> On Wed 27-May-2009 at 08:27 -0700, Tom Sharpless wrote:
>
>
>
> >I generally stitch multiple exposure sequences with PTGui, as that
> >gives me what seems an intelligible choice: either share CPs across
> >exposures or align each image with independent CPs; while I can't make
> >head or tail of the options in Hugin.  I think the Hugin UI needs some
> >serious work in this area, so everyone can have a nice tool like
> >ImageFuser.
> >Are you fully satisfied with align_image_stack?  I have noticed some
> >complaints as well as much praise in the lists.  Not being a user of
> >it myself, but interested in image alignment problems as a developer,
> >I wonder if you or others could suggest what are its main
> >limitations?
>
> As far as I'm concerned this is largely a solved problem.  hugin
> doesn't yet have the ability to hard-link the positions of photos in
> a stack, but align_image_stack does a good job of doing this linking
> with control points - With the added advantage of dealing with
> slight misalignments, up to and including my sloppy hand-held
> bracketing.
>
> The disadvantage is that align_image_stack takes some amount of time
> and that the control-points it generates slow down the optimiser.  
> However, there is probably an order-of-magnitude speed increase
> available in the hugin workflow, but I'm sure it isn't here.
>
> Otherwise there are two important hugin options that we don't yet
> have that will be relatively simple to add with some extra Makefile
> rules:
>
> 1. enfusing stacks as the first step before remapping with nona.
> 2. enfusing exposure layers as the last step after blending with
> enfuse.
>
> For (1) to work sensibly, it should only happen when the photos are
> known to be exactly aligned, James is working on a GUI and backend
> to allow specifying and optimising this (or rather unspecifying, as
> stacks are easy to detect by looking at EXIF data, the distinction
> is whether or not they are exact stacks or not).
>
> >I imagine a fine-aligner using correlation (as opposed to control
> >points) might be a helpful addition to align_image_stack.  Or does
> >it already do that?
>
> align_image_stack uses the same pixel correlation as the hugin
> fine-tune, which is why it is much faster than a control point
> matcher.
>
> Have you tried match-n-shift where all this is implemented?  Though
> James has convinced me that most of this logic should be in hugin
> itself rather than in a separate control-point generator.
>
> --
> Bruno

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Bruno Postle]

On Thu 28-May-2009 at 07:52 -0700, Tom Sharpless wrote:
>
>So align_image_stack does use local correlations, then generates CP's
>as a way of communicating the required alignment to other tools?

It generates control points because it uses the hugin optimiser to
do the alignment (which is also why it accepts projection and field
of view parameters).

>Is this done in such a way as to allow some warping as well as simple
>shifting in the final alignment step?

The alignment uses the usual roll, pitch, yaw and fov distortion.

>That is, are the CP's based only or mainly on local shifts?

No idea, the image is divided up into a grid and a feature detector
tries to place an even distribution of points over the image area.

In practice, with the -p option it behaves like a control point
generator that only works with stacked photos, but which produces
very few 'bad' points and which works very well with large exposure
differences.

--
Bruno

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Pablo d'Angelo]

Hi all,

This description is correct. Note that align_image_stack was really
written more like a proof of concept and is not really well optimized.
Actually, the implementation of the normalized cross correlation in
hugin is very basic and thus quite slow. Replacing it with a properly
optimized version (I believe opencv has a nicely optimized correlator)
would make both align_image_stack and the fine tune functionality much
faster.

ciao
   Pablo

Bruno Postle wrote

> On Thu 28-May-2009 at 07:52 -0700, Tom Sharpless wrote:
>> So align_image_stack does use local correlations, then generates CP's
>> as a way of communicating the required alignment to other tools?
>
> It generates control points because it uses the hugin optimiser to
> do the alignment (which is also why it accepts projection and field
> of view parameters).
>
>> Is this done in such a way as to allow some warping as well as simple
>> shifting in the final alignment step?
>
> The alignment uses the usual roll, pitch, yaw and fov distortion.
>
>> That is, are the CP's based only or mainly on local shifts?
>
> No idea, the image is divided up into a grid and a feature detector
> tries to place an even distribution of points over the image area.
>
> In practice, with the -p option it behaves like a control point
> generator that only works with stacked photos, but which produces
> very few 'bad' points and which works very well with large exposure
> differences.
>

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[David Haberthür-3]

Hello all.

On May 23, 2:50 am, DaveN <tahoedave...@...> wrote:
> I don't know if this has been asked before (hard question to ask in a
> search) but why don't people fuse their images before making
> panoramas?  By that I mean the software for making panoramas (the
> hugin clone ptgui and autopano pro) seem to remap all the images to
> create differently exposed panoramas and then blend the panoramas.
> Wouldn't it be more efficient to exposure fuse the images and then
> make the panorama?

I'm very late to this thread, but I'm catching up.
I was wondering if I've been doing it entirely wrong "all the time".
All the time means that I havent made that many fused panoramas.
With my main example of the entrance to the train station in Bern [1]
i remember that I just dumped all the 87 images (29 photos for each
exposure step) into hugin and stitched a fused image in one single
output. It took a long time for Pan-O-Matic to find the control points
but in the end I got a quite impressive result.

So I'm asking: would I get another result if I'd have generated three
panoramas, one for each exposure step and then enfuse them to one
final panorama?

Greetings from Switzerland
Habi

[1]: http://www.flickr.com/photos/habi/sets/72157614221776963/
--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[J. Schneider-2]

Hello Habi,
> So I'm asking: would I get another result if I'd have generated three
> panoramas, one for each exposure step and then enfuse them to one
> final panorama?
I can't tell this but I have the impression that the scene isn't
particularly suitable for exposure fusing. I would expect the dark areas
  in the train station to have a little more detail than without fusing
but that's all. (Of course I haven't seen the original images or a
panorama made solely of the middle exposure.) By the way I would
recommend to use vertical control points to keep vertical edges of
buildings upright.

regards
Joachim

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---