Fusing before or after

[tahoedave360]

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

[Gerry Patterson]

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

On Fri, May 22, 2009 at 7:50 PM, DaveN <tahoedave360@...> 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?

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

[Peter Gawthrop-2]

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.

 
From: DaveN <tahoedave360@...>
Subject: [hugin-ptx] Fusing before or after
Date: Fri, 22 May 2009 17:50:04 -0700 (PDT)

>
> 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?
> >
>
> ______________________________________________        
> This email has been scanned by Netintelligence        
> http://www.netintelligence.com/email
>

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

[Harry van der Wolf-3]

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 <peter@...>

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.


From: DaveN <tahoedave360@...>
Subject: [hugin-ptx] Fusing before or after
Date: Fri, 22 May 2009 17:50:04 -0700 (PDT)

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

> ______________________________________________
> This email has been scanned by Netintelligence
> http://www.netintelligence.com/email

>

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

[tahoedave360]

Hi Gerry,

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...@...> 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
>
> On Fri, May 22, 2009 at 7:50 PM, 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?

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

[Yuval Levy-6]

Harry van der Wolf wrote:
> 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


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

[Gerry Patterson]

Hi all,

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

On Sat, May 23, 2009 at 2:29 PM, Yuval Levy <google@...> wrote:

Harry van der Wolf wrote:
> 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

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

[Markku Kolkka-2]

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
of http://static.panoramio.com/photos/original/10143416.jpg

--
 Markku Kolkka
 markku.kolkka@...

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

[Harry van der Wolf-3]

2009/5/25 Markku Kolkka <markku.kolkka@...>

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
of http://static.panoramio.com/photos/original/10143416.jpg

--
 Markku Kolkka
 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 artifact" issue which is described on enblend.sourceforge.net at http://enblend.sourceforge.net/banding.htm.

Actually only the conclusion matters:

"In summary, it is a combination of numerical precision errors and limitations of an 8 bit/channel color format that is the cause of the banding artifacts. Rounding errors were responsible for the shape of the bands, but this was just hiding the underlying issue that 256 levels of green is not enough for quality digital imaging."

 

Harry

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

[tahoedave360]

Take a look at the fused image before transforming to the panorama.
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...@...> wrote:

> 2009/5/25 Markku Kolkka <markku.kol...@...>
>
>
>
>
>
> > 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
> >  markku.kol...@...
>
> 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
> artifact" issue which is described on enblend.sourceforge.net athttp://enblend.sourceforge.net/banding.htm.
> Actually only the conclusion matters:
> *"In summary, it is a combination of numerical precision errors and
> limitations of an 8 bit/channel color format that is the cause of the
> banding artifacts. Rounding errors were responsible for the shape of the
> bands, but this was just hiding the underlying issue that 256 levels of
> green is not enough for quality digital imaging."*
>
> Harry

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

[paul womack]

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

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)

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

[B. Schnieders]

hi all,
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

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

[timboj]

Hi Benjamin,

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

Benjamin Schnieders wrote:

> hi all,
> 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
>
> >
>

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

>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

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

[dkloi]

On 26 May, 11:23, paul womack <pwom...@...> wrote:
[SNIP]

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

I'm getting some weird results when using enfuse directly in Hugin:
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.
--~--~---------~--~----~------------~-------~--~----~
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]

Hi Harry et al.

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...@...> 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...@...>
>
>
>
> > 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.
>
> > From: DaveN <tahoedave...@...>
> > Subject: [hugin-ptx] Fusing before or after
> > Date: Fri, 22 May 2009 17:50:04 -0700 (PDT)
>
> > > 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?
>
> > > ______________________________________________
> > > This email has been scanned by Netintelligence
> > >http://www.netintelligence.com/email

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

[Harry van der Wolf-3]

2009/5/27 Tom Sharpless <TKSharpless@...>

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




 

On May 23, 5:18 am, Harry van der Wolf <hvdw...@...> 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...@...>

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

> > From: DaveN <tahoedave...@...>

> > Subject: [hugin-ptx] Fusing before or after
> > Date: Fri, 22 May 2009 17:50:04 -0700 (PDT)
>
> > > 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?
>
> > > ______________________________________________
> > > This email has been scanned by Netintelligence
> > >http://www.netintelligence.com/email

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

[B. Schnieders]

Bruno Postle wrote:

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

that worked fine, thanks :) as i saw, ptomerge did not recalculate the
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

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

[paul womack]

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" :-)

   BugBear

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