image stack order

317 views
Skip to first unread message

Darius Blaszyk

unread,
Jul 14, 2012, 8:07:17 AM7/14/12
to hugi...@googlegroups.com
Hi,

I've stitched a number of images together and used the mask tool to mask certain regions out. Also I have reordered the order of images in the "images" tab. Everything looks perfect in the image preview, but when I export the panorama, the image order is not respected and the panorama turns out differently. Is there some switch I need to set to make my panorama the same as the preview?

Regards, Darius

Darius Blaszyk

unread,
Jul 14, 2012, 8:13:35 AM7/14/12
to hugi...@googlegroups.com

Bruno Postle

unread,
Jul 14, 2012, 4:59:29 PM7/14/12
to Hugin ptx
Stitching places a blending seam between photos, this seam isn't
visible in the preview because the position of the seam is
determined during the final blending step of stitching.

So the preview is just an approximation of the final result, in
particular it shows photos overlapping completely rather than
blended.

--
Bruno

Darius Blaszyk

unread,
Jul 15, 2012, 5:41:45 AM7/15/12
to hugi...@googlegroups.com
The thing is though that the order in which the images are rendered is not respected. Say I have two images, one with the background and one image that has a person in it on the foreground. The images are stitched to each other just fine, and I applied a mask over the person so that is only rendered and pasted in the background image. Additionally I changed the order of the images in the image tab. Now in the preview everything looks fine. The background image is rendered first and on top of that is the masked person shown. Now if I render the result image, the person is rendered first and on top of that is the background image rendered. Iow the stacking order is now different from the preview. I'm sure I missed a setting or this is a bug in the source code. Is there a way to circumvent this or as a temp solution create a script of some sort where I can modify the render order manually.

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

Jan Martin

unread,
Jul 15, 2012, 6:58:07 AM7/15/12
to hugi...@googlegroups.com
Not sure if this works.
You could open the .pto file with a text editor and check in what sequence the images are saved to it?
Manually re-sorting it might help?

Darius Blaszyk

unread,
Jul 15, 2012, 7:47:55 AM7/15/12
to hugi...@googlegroups.com
The sequence seems to be correct in the PTO file. I have also tried to reverse the image sequence in the GUI, but even that did not help. There must be some numbering order being used (according to original import sequence I presume). I'm afraid the only solution I see right now is to rename the files and import all the images again to correct the image stack sequence. I'm sure this is a bug in hugin, but I don't have enough knowledge of the internal workings to pinpoint the issue.

Jan Martin

unread,
Jul 15, 2012, 9:45:38 AM7/15/12
to hugi...@googlegroups.com
To solve this it would be helpful to have your pto file and the source images.
Can you zip and upload?

Bruno Postle

unread,
Jul 15, 2012, 4:40:10 PM7/15/12
to Hugin ptx
On Sun 15-Jul-2012 at 11:41 +0200, Darius Blaszyk wrote:
> The thing is though that the order in which the images are
> rendered is not respected. Say I have two images, one with the
> background and one image that has a person in it on the
> foreground. The images are stitched to each other just fine, and I
> applied a mask over the person so that is only rendered and pasted
> in the background image. Additionally I changed the order of the
> images in the image tab. Now in the preview everything looks fine.
> The background image is rendered first and on top of that is the
> masked person shown. Now if I render the result image, the person
> is rendered first and on top of that is the background image
> rendered.

I'm not sure here, are you talking about exposure fusion of a
bracketed stack? or seam blending a 'normal' panorama?

With exposure fusion, the image order shouldn't make any difference,
you will get the same result.

With seam blending, the order of photos does make a difference
because the first two photos are blended, then this combined image
is blended with the third photo etc... but this can't easily be
represented in the preview. In the simple case of two photos, you
should get the same result regardless of order (though I haven't
tested enblend for this).

--
Bruno

Darius Blaszyk

unread,
Jul 15, 2012, 9:11:15 AM7/15/12
to hugi...@googlegroups.com
After updating to 2011.4.0 still no luck.


On Jul 15, 2012, at 2:41 PM, Darius Blaszyk wrote:

Still no luck, after renaming the image files to the order in which I need them and creating a new project so I can import them in the correct order from the start I still did not manage to create the correct panorama. The preview shows everything correct (containing a lot of masked images). When I export the panorama however some of the masked images seem to be lost ie not used. Also the order of the image seems to be different from the order defined in the UI. 

Is it possible to preserve the intermediate tiff files the hugin produces so I can blend the tiff files myself? Even better, is it possible to have hugin output a script that I can run manually to see if I can create the panorama myself?

Hugin version: 2011.0.1
Mac OSX 10.6.8

Darius 

Darius Blaszyk

unread,
Jul 15, 2012, 11:05:15 AM7/15/12
to hugi...@googlegroups.com

Please note that if you change the stack order of img01 and img02 that this also does not work. Although the correct stack order is shown in the preview, the stack order is not respected in the final render.

This makes me believe that there are two problems.

1. stack order not being respected
2. masked images are not (correctly) used

Darius Blaszyk

unread,
Jul 15, 2012, 5:12:22 PM7/15/12
to hugi...@googlegroups.com

Darius Blaszyk

unread,
Jul 15, 2012, 8:41:02 AM7/15/12
to hugi...@googlegroups.com
Still no luck, after renaming the image files to the order in which I need them and creating a new project so I can import them in the correct order from the start I still did not manage to create the correct panorama. The preview shows everything correct (containing a lot of masked images). When I export the panorama however some of the masked images seem to be lost ie not used. Also the order of the image seems to be different from the order defined in the UI. 

Is it possible to preserve the intermediate tiff files the hugin produces so I can blend the tiff files myself? Even better, is it possible to have hugin output a script that I can run manually to see if I can create the panorama myself?

Hugin version: 2011.0.1
Mac OSX 10.6.8

Darius 


Bruno Postle

unread,
Jul 15, 2012, 5:27:09 PM7/15/12
to Hugin ptx
On Sun 15-Jul-2012 at 14:41 +0200, Darius Blaszyk wrote:
>
> Is it possible to preserve the intermediate tiff files the hugin
> produces so I can blend the tiff files myself?

Yes, in the Stitcher tab you can choose to keep the 'remapped
images'.

> Even better, is it possible to have hugin output a script that I
> can run manually to see if I can create the panorama myself?

The stitching process is managed by 'make'. I seem to remember that
the OS X GUI doesn't create a Makefile when you save the project, so
you need to use the pto2mk to create a Makefile, which you can then
process on the command-line: http://wiki.panotools.org/Pto2mk

--
Bruno

Jan Martin

unread,
Jul 15, 2012, 5:28:39 PM7/15/12
to hugi...@googlegroups.com
Just gave it a test on Ubuntu 64 bit with hugin 2011.5.0.d5f0b74cc78b.
All present. Works as it should.

dex Otaku

unread,
Jul 16, 2012, 7:58:22 AM7/16/12
to hugi...@googlegroups.com
I do this all the time - reorder images to force a particular area as dominant while stitching - with Hugin on Windows.  

The current version [2011.4, used last week in exactly this fashion] and previous versions going back as far as whatever was current in 2004-5 [I have done this with every version available since then] have all worked correctly for this, for me.  

Not sure what to suggest to you, Darius.

Darius Blaszyk

unread,
Jul 16, 2012, 9:02:27 AM7/16/12
to hugi...@googlegroups.com
Can you have a look to the test project I uploaded to dropbox? Tell me if you get the same output in the final render as you get in the preview.

I've been testing on windows and mac. Will try ubuntu 32bit now.

Regards, Darius


Darius Blaszyk

unread,
Jul 16, 2012, 9:06:21 AM7/16/12
to hugi...@googlegroups.com
Can I download somewhere daily snapshots? I've tried to build hugin myself, but dependency issues prevent me building a recent version. I also checked graphicall.org. Could I suggest you guys upload development versions there?

Regards, Darius

Stefan Peter

unread,
Jul 16, 2012, 9:16:06 AM7/16/12
to hugi...@googlegroups.com
Dear Darius

On 16.07.2012 15:06, Darius Blaszyk wrote:
> Can I download somewhere daily snapshots?

Please have a look at https://launchpad.net/~hugin/+archive/nightly.

With kind regards

Stefan Peter

--
In theory there is no difference between theory and practice. In
practice there is.


Darius Blaszyk

unread,
Jul 16, 2012, 9:43:37 AM7/16/12
to hugi...@googlegroups.com
Thanks! I'll switch over to linux later on again and try there. In the mean time I found a message from enblend that is worrying me...

enblend: warning: input images to small for coarse mask; switching to fine mask
enblend: info: loading next image: pano0000.tif 1/1
enblend: info: loading next image: pano0001.tif 1/1
enblend: info: loading next image: pano0002.tif 1/1
enblend: info: loading next image: pano0003.tif 1/1
enblend: info: loading next image: pano0004.tif 1/1
enblend: images do not overlap - they will be combined without blending
enblend: use the "-l" flag to force blending with a certain number of levels
enblend: info: loading next image: pano0005.tif 1/1
enblend: images do not overlap - they will be combined without blending
enblend: use the "-l" flag to force blending with a certain number of levels
enblend: info: loading next image: pano0006.tif 1/1
enblend: images do not overlap - they will be combined without blending
enblend: use the "-l" flag to force blending with a certain number of levels
enblend: info: loading next image: pano0007.tif 1/1
enblend: info: loading next image: pano0008.tif 1/1
enblend: info: loading next image: pano0009.tif 1/1
enblend: info: loading next image: pano0010.tif 1/1
enblend: info: loading next image: pano0011.tif 1/1
enblend: info: loading next image: pano0012.tif 1/1
enblend: info: loading next image: pano0013.tif 1/1
enblend: info: loading next image: pano0014.tif 1/1
enblend: info: loading next image: pano0015.tif 1/1
enblend: info: loading next image: pano0016.tif 1/1
enblend: warning: some images are redundant and will not be blended
enblend: info: writing final output

It's especially the last message (redundant images) that worries me. Does this mean that enblend autonomously decides to throw away some images? I guess so, but what can be done about it?

Regards, Darius



Bruno Postle

unread,
Jul 16, 2012, 4:17:14 PM7/16/12
to Hugin ptx
On Mon 16-Jul-2012 at 15:43 +0200, Darius Blaszyk wrote:
> Thanks! I'll switch over to linux later on again and try there. In
> the mean time I found a message from enblend that is worrying me...

> enblend: warning: some images are redundant and will not be blended
>
> It's especially the last message (redundant images) that worries
> me. Does this mean that enblend autonomously decides to throw away
> some images? I guess so, but what can be done about it?

This means that a photo completely overlaps. It isn't possible to
place a seam in this situation, so enblend discards the photo, i.e.
the output already has this part of the image covered.

It suggests that you have stacked images, but are not using the
option to enable exposure fusion of stacks.

--
Bruno
Reply all
Reply to author
Forward
0 new messages