Fusing before or after
DaveN
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?
Gerry Patterson
There are cases when one photographs hand-held and the different exposures are not aligned well enough to be fused first.
Best Regards,
- Gerry
Peter Gawthrop
I fuse first. The reason is that, in my case, each set of eight
images is taken with exactly the same settings (using manual
mode). The other advantage is that selecting control points for the
fused images is easy as all of the image is visible.
Peter.
> This email has been scanned by Netintelligence
> http://www.netintelligence.com/email
>
Harry van der Wolf
I also fuse first (but maybe I'm a bit biased being the writer of the ImageFuser tool).
The reason I do this is that Hugin has sometimes difficulties in finding CP's between the very dark and light images in such bracketed sets. It is sometimes also hard to do that by hand. In that case prefusing the helps a lot.
As an addition to what Gerry said about hand-held images: You can use align_image_stack to perfectly align your bracketed photos before fusing them. The better fusing gui's come with align_image_stack and do support that.
Harry
Tahoe Dave
I can see the logic of 'post processing' fusion for hand held images
but that assumes each exposure set is aligned in itself and then the
exposures are aligned which I don't think the programs do. Don't they
align one image set and then apply the same settings to each exposure
set? I nearly always shoot using a tripod and in that case a tool
like Kekus' Xfuse works out great with its batch processing option. I
haven't done any exposure fused panoramas yet though.
Dave
On May 22, 7:00 pm, Gerry Patterson <thedeepvo...@gmail.com> wrote:
> Hello,
>
> There are cases when one photographs hand-held and the different exposures
> are not aligned well enough to be fused first.
>
> Best Regards,
>
> - Gerry
>
Yuval Levy
> I also fuse first
+1 most of the time, but not all the time.
> As an addition to what Gerry said about hand-held images: You can use
> align_image_stack to perfectly align your bracketed photos before fusing
> them. The better fusing gui's come with align_image_stack and do support
> that.
my wish is to eventually have a "composing GUI" to deal with the
"sequence of images" - whatever that sequence is.
constrains and actions are boxes of different sizes, that the user can
drag and drop on the working surface; and that smart logic can auto-create.
actions are things like:
- determine CP
- add masks
- blend / fuse
- optimize position in space
- manual edit of individual parameters
- remap
- forks (to have mutliple processing, e.g. for different outputs from
the same project)
constraints are things like:
- defining which images belong to a bracket and what type of bracket it is
- which images share the same set of parameters
- areas/mask of an image not to be considered for CP generation
- areas/mask fo an image that *must* be preserved or *must* be hidden
a GUI to move around and connect the boxes with a little bit of logic to
make sense of the connections (e.g. don't blend a single image or don't
enfuse images with same EV) sort of like a syntax checker before a
controller engine starts the different tools in the appropriate order
and with the appropriate parameters.
Ideally the interface between the GUI and the controller engine would be
an XML file, although if the GUI understands the Makefile format it
could create a Makefile directly, but that would make the Makefile part
of the project and I am not sure how it will affect the projects in
terms of portability to a different box? rather go safe, describe it in
an XML and have an XML to MakeFile thing...
Yuv
Gerry Patterson
I hope I didn't give anyone the wrong idea. I almost always shoot bracketed sets with a tripod. As such, fusion before blending makes sense for me, too. However, I have been burned before by not considering how others shoot, so I was just presenting a case when one would possibly want to blend first, and fuse later.
What Yuval describes is something similar to a mindmap I had given him earlier. I think the XML file or someother top level persistent storage format will eventually be a useful addition to Huginl. While most of hugins options and settings can be stored in comments inside of a .pto file, it can be clumlsy. Makefiles and .pto files would be exported from hugin when required.... I hadn't really considered much of a revamp to the GUI, just enough additions to set the constraints as needed..
I am interested in James GSOC project this year as he plans on tackling the bracket exposure support in Hugin.
Best Regards,
- Gerry
Markku Kolkka
2009):
> 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?
I'm getting highlight banding artifacts when fusing (to 16-bit
TIFF) before making the panorama. See e.g. the top left corner
of http://static.panoramio.com/photos/original/10143416.jpg
--
Markku Kolkka
markku...@iki.fi
Harry van der Wolf
Tahoe Dave
The the image that is converted to the upper left corner have the
artifact? If it doesn't then it isn't an enfuse problem but it may be
an enblend problem.
On May 25, 12:44 am, Harry van der Wolf <hvdw...@gmail.com> wrote:
> 2009/5/25 Markku Kolkka <markku.kol...@iki.fi>
>
>
>
>
> > DaveN kirjoitti viestissään (lähetysaika lauantai, 23. toukokuuta
> > 2009):
> > > 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?
>
> > I'm getting highlight banding artifacts when fusing (to 16-bit
> > TIFF) before making the panorama. See e.g. the top left corner
> > ofhttp://static.panoramio.com/photos/original/10143416.jpg
>
> > --
> > Markku Kolkka
> You mention that you fuse to 16bit tiff. Fusing from what source images,
> also 16bit tiff or from 8bit tiff or jpg?
> If you are fusing from jpg or 8bit tiff you might run into the "banding
> banding artifacts. Rounding errors were responsible for the shape of the
> bands, but this was just hiding the underlying issue that 256 levels of
>
> Harry
paul womack
There are a number of pros and cons.
IF the bracketed shots were taken using a (good) tripod,
the images can be fused prior to stitching.
However, this makes subsequent use of exposure optimisation
in hugin "questionable", since the numerical basis of the optimisation
is destroyed by the (clever and generally desirable) things enfuse does.
The other possibility is that fusing is on a PER shot basis, and may
create edge conditions between successive shots in the panorama
that might cause difficulties for enblend.
However, post-fusing requires the shots to be aligned.
One way round this is to create a hugin project of the
"middle" exposure in the bracket set, and then use this
as a template for the more extreme exposures. This avoids
the difficulties of placing control points on the extreme
exposures at the ends of the bracketing. This only works
for tripod-taken sets.
Finally, pre fusing IS computationally efficient; if you repeatedly
"tweak" your panorama project, having all the fusing done as a pre-stage
is clearly efficient. Further, fusing a bracketed set of
stitched panoramas is a massively RAM intensive activity, whereas
fusing the shots separately might well fit in RAM.
BugBear (pre fuser, on balance)
Benjamin Schnieders
actually i'm having a problem with exactly that question right now.
i have a series of image stacks i'd like to stitch and fuse, so stack1_0
.. stack 1_6 until stack7_6. the thing is, the images are pretty dark,
so automatic control point generation does a very bad job using all the
images. align_image_stack however manages to align my stacks pretty well
(they are shot with a bad tripod, so a little alignment is needed)
but everything align_image_stack can give me is a complete .hdr, (which
is, as far as i know, bad input to enfuse) a set of remapped images
(which i don't need as i want to remap them later, aligned in total) or
a pto file that holds information about the image offsets.
seems that the latest is just what i need, but then, is there a method
of merging these pto files together in a way that the images will "stick
together"?
to get proper results, atm i only see one solution:
- take the brightest set of images, generate control points, align them
- starting from the brightest image, use align_image_stack to align each
whole stack to a .pto file
- manually add up the translations calculated by align_image_stack to
all further images and insert them into the big .pto from the beginning
- run enfuse and enblend.
definitely not the best way. are there scripts oder other tricks that
will help?
thanks,
Benjamin
Tim Nugent
I deal with enfuse and bracketed sets with a patch I wrote:
http://ultrawide.wordpress.com/2008/11/16/hacking-hugin-part-1/
I load the first set of images, generate control points and align, then
send the pano to batch. Then on the images panel, click 'bracket up' to
switch to the next bracketed set, but keeping the control
points/alignment from the first bracket set (this solves the problem
when the set is too bright/dark to find CPs). Save and send to batch,
then repeat for remaining bracketed sets.
At the end, all the panos should have been warped in the same way. Then
I enfuse them from the command line.
Cheers,
Tim
Bruno Postle
>
>but everything align_image_stack can give me is a complete .hdr, (which
>is, as far as i know, bad input to enfuse) a set of remapped images
>(which i don't need as i want to remap them later, aligned in total) or
>a pto file that holds information about the image offsets.
>
>seems that the latest is just what i need, but then, is there a method
>of merging these pto files together in a way that the images will "stick
>together"?
Yes, you could use ptomerge (from Panotools::Script) to join all the
projects created by align_image_stack with a project created by
autopano-sift-c or panomatic.
>to get proper results, atm i only see one solution:
>
>- take the brightest set of images, generate control points, align them
>- starting from the brightest image, use align_image_stack to align each
>whole stack to a .pto file
>- manually add up the translations calculated by align_image_stack to
>all further images and insert them into the big .pto from the beginning
This is exactly what the match-n-shift --stacks option does (also
from Panotools::Script).
i.e. something like this in the hugin preferences should do what you
want:
AutopanoExe=match-n-shift
Args=-b -a -f %f -v %v -c -p %p -o %o %i
--
Bruno
dkloi
[SNIP]
> the images can be fused prior to stitching.
>
> However, this makes subsequent use of exposure optimisation
> in hugin "questionable", since the numerical basis of the optimisation
> is destroyed by the (clever and generally desirable) things enfuse does.
>
> The other possibility is that fusing is on a PER shot basis, and may
> create edge conditions between successive shots in the panorama
> that might cause difficulties for enblend.
>
> However, post-fusing requires the shots to be aligned.
> One way round this is to create a hugin project of the
> "middle" exposure in the bracket set, and then use this
> as a template for the more extreme exposures. This avoids
> the difficulties of placing control points on the extreme
> exposures at the ends of the bracketing. This only works
> for tripod-taken sets.
http://cnqo.phys.strath.ac.uk/~daniel/Photos/Examples/Pre-fused.jpg
I've followed the tutorial given at http://hugin.sourceforge.net/tutorials/enfuse-360/en.shtml,
except for manually aligning the three stacks. I aligned the middle
exposures as normal, then each bracketed shot with the middle exposure
shot. I tried without and with photometric optimisation but got weird
results both times.
In comparison, I stitched and blended each exposure layer, then
enfused the three pannoramas and got this much better result,
http://cnqo.phys.strath.ac.uk/~daniel/Photos/Examples/Post-fused.jpg.
Source images were taken on tripod, -2EV, 0EV and +2EV exposure at
each position (6+1+1).
Cheers,
Daniel.
Tom Sharpless
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.
With Hugin I tend to stitch first, then spend too much time fixing
ghosts by hand. But that is mainly because I can't understand how to
do it the other way, which based on this thread, I guess must be
better.
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? 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?
Regards, Tom
On May 23, 5:18 am, Harry van der Wolf <hvdw...@gmail.com> wrote:
> Hi Dave,
>
> I also fuse first (but maybe I'm a bit biased being the writer of the
> ImageFuser tool).
> The reason I do this is that Hugin has sometimes difficulties in finding
> CP's between the very dark and light images in such bracketed sets. It is
> sometimes also hard to do that by hand. In that case prefusing the helps a
> lot.
>
> As an addition to what Gerry said about hand-held images: You can use
> align_image_stack to perfectly align your bracketed photos before fusing
> them. The better fusing gui's come with align_image_stack and do support
> that.
>
> Harry
>
> 2009/5/23 Peter Gawthrop <pe...@gawthrop.net>
>
>
>
> > Hi Dave,
>
> > I fuse first. The reason is that, in my case, each set of eight
> > images is taken with exactly the same settings (using manual
> > mode). The other advantage is that selecting control points for the
> > fused images is easy as all of the image is visible.
>
> > Peter.
>
Harry van der Wolf
Are you fully satisfied with align_image_stack? I have noticed some
complaints as well as much praise in the lists.
I'm quite satisfied with align_image_stack. As it is not perfect, I'm not fully satisfied ;-).
Also align_image_stack sometimes has problems with very dark images.
Align_image_stack creates "aligned" tiffs and it can create a HDR.
One of the issues right now is that align_image_stack doesn't create a correct HDR when the input is tiff, both 8bit as well as 16bit (didn't try with 32bit). It makes a correct HDR image from jpeg and 8bit/16bit png.
I still need to file a bug. (I've been quite busy last week).
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?
It's main limitation is it's speed (or better: lack of it). I have the idea that the code could be optimised for speed, but that might just be my impatient nature. Next to that is the mentioned bug off course, but that's not an improvement, only a (neccessary) bug fix.
Maybe others experience other limitations.
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?
Regards, Tom
No, it doesn't do that. It only works with Control Points. I have no experience at all with these kind of "fine-aligner using correlation" algorithms so it might be a helpful addition, but I can't judge. I would welcome such an addition if it is only to see whether it works. But then again: I'm not the one who can program that and who needs to put time and effort into it.
Hoi,
Harry
Bruno Postle
>
>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
Benjamin Schnieders
> On Tue 26-May-2009 at 22:54 +0200, Benjamin Schnieders wrote:
>
>> but everything align_image_stack can give me is a complete .hdr, (which
>> is, as far as i know, bad input to enfuse) a set of remapped images
>> (which i don't need as i want to remap them later, aligned in total) or
>> a pto file that holds information about the image offsets.
>>
>> seems that the latest is just what i need, but then, is there a method
>> of merging these pto files together in a way that the images will "stick
>> together"?
>>
>
> Yes, you could use ptomerge (from Panotools::Script) to join all the
> projects created by align_image_stack with a project created by
> autopano-sift-c or panomatic.
>
positions of the relatively oriented images, (just as i guessed) but
instead added all the control points holding the stacks, that's fine as
well. test worked out nicely, now my 84-image-pano of a nighly power
plant will be next (looking forward to it :))
i wrote some scripts to ease the extraction of different levels of 8-bit
pngs from 14-bit raws, then creating ptos for each stack, i think
panotools-script could be enhanced with scripts like these (mine are
definitely not for other eyes, because of the code quality ;))
>> This is exactly what the match-n-shift --stacks option does (also
>> from Panotools::Script).
>>
>> i.e. something like this in the hugin preferences should do what you
>> want:
>>
>> AutopanoExe=match-n-shift
>> Args=-b -a -f %f -v %v -c -p %p -o %o %
i will also give that a try, last time i built hugin was without
match-n-shift, so next time my cpu is idle i will try it...
thank again,
Benjamin
paul womack
>
> 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" :-)
BugBear
Bruno Postle
Yes, or "confuse".
--
Bruno
Tom Sharpless
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
Bruno Postle
>
>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
Pablo d'Angelo
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
Habi
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/
J. Schneider
> 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?
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