How to reduce the size of the final panorama ? Fast previews ?

589 views
Skip to first unread message

WaterWolf

unread,
Sep 13, 2010, 12:56:28 PM9/13/10
to hugin and other free panoramic software
Hello,

I'm quite new to hugin but so far I've generally been getting
excellent results creating standard panoramas.

Recently I tried creating one of those 360 degree 'little planet'
stereographic projections that you can find in the gallery on the
hugin homepage. So I went out into my garden and took a 360 degree
matrix of images. It took 42 images to cover the whole garden.

I loaded them into hugin, created a stereographic projection and then
tried to generate the image. Nona took about an hour to run but
enblend needed 17 hours to complete. The resulting image was 800mp and
took up 3gb of disk space (photoshop took half an hour just to open
the file).

So issue 1: The resulting image is unnecessarily large for my purposes
and so took much longer to generate than it needed to. What is the
best way of reducing the size of the final image and speeding up the
process? It would also be nice to be able to generate quick (ie less
than an hour) previews of images before generating the final version.
I tried reducing the size of my input images but then panomatic wasn't
able to find control points and a lot of resulting image groups were
unconnected - it would take hours to connect them manually. I had
reduced the image size to 800x 600, is this too small?

Issue 2: Although the general sticth / blend of the final image was
great there were some major glitches introduced by enblend in the form
of lots of horizontal lines. I haven't seen this issue in any of my
other panoramics. This appears to be the same issue as was seen here:
http://groups.google.com/group/hugin-ptx/browse_thread/thread/94215a777d68d7fe/719c28c6d8a86276?lnk=gst&q=horizontal+lines#719c28c6d8a86276
The general conclusion in the thread seems to be that the problem is
somehow related to image resolution.

By the way, I'm using the 2010.1 svn.5161 build that I got from
http://lemur.dreamhosters.com/hugin/. Where is the best place to get
the latest windows builds from?

Anyway, thanks for any help you can give,
David.

Yuval Levy

unread,
Sep 13, 2010, 5:42:35 PM9/13/10
to hugi...@googlegroups.com
Hi,

On September 13, 2010 12:56:28 pm WaterWolf wrote:
> So issue 1: The resulting image is unnecessarily large for my purposes
> and so took much longer to generate than it needed to. What is the
> best way of reducing the size of the final image and speeding up the
> process? It would also be nice to be able to generate quick (ie less
> than an hour) previews of images before generating the final version.
> I tried reducing the size of my input images but then panomatic wasn't
> able to find control points and a lot of resulting image groups were
> unconnected - it would take hours to connect them manually. I had
> reduced the image size to 800x 600, is this too small?

weird - CP detection should run without problems at this size - in fact it was
not too long ago that autopano was automatically reducing images to a similar
size when detecting.

purely for a preview, you can change the output size in Hugin's stitcher tab.

if you already did the job of stitching full size and you want a smaller one,
use ImageMagick:

convert input.tif -resize 50% output.jpg


> Issue 2: Although the general sticth / blend of the final image was
> great there were some major glitches introduced by enblend in the form
> of lots of horizontal lines. I haven't seen this issue in any of my
> other panoramics. This appears to be the same issue as was seen here:
> http://groups.google.com/group/hugin-ptx/browse_thread/thread/94215a777d68d
> 7fe/719c28c6d8a86276?lnk=gst&q=horizontal+lines#719c28c6d8a86276 The
> general conclusion in the thread seems to be that the problem is somehow
> related to image resolution.

from my experience, these issues happen when memory is low and image size is
large in relationship to it. Might have been a memory leak somewhere.
Projects that I stitched about a year ago with enblend 3.2 showed the issue on
a 2GB laptop and no issue on an 8GB desktop. With enblend 4.0 even a 2GB
machine works through them successfully (although: it's no longer the now
defunct laptop, but it is a nettop).


HTH
Yuv

signature.asc

Bruno Postle

unread,
Sep 13, 2010, 5:58:36 PM9/13/10
to hugin and other free panoramic software
On Mon 13-Sep-2010 at 09:56 -0700, WaterWolf wrote:
>
>Recently I tried creating one of those 360 degree 'little planet'
>stereographic projections that you can find in the gallery on the
>hugin homepage. So I went out into my garden and took a 360 degree
>matrix of images. It took 42 images to cover the whole garden.
>
>I loaded them into hugin, created a stereographic projection and then
>tried to generate the image. Nona took about an hour to run but
>enblend needed 17 hours to complete. The resulting image was 800mp and
>took up 3gb of disk space (photoshop took half an hour just to open
>the file).

Yes stereographic images have different resolution areas in
different parts of the image, so if you set a large field of view
Hugin will create very large output such that there is no loss of
detail.

There are two things you can do:

1. Change the pixel width and height of the panorama to something
manageable in the Stitcher tab.

2. Don't stitch directly to stereographic projection. You should
stitch a 'standard' equirectangular panorama, this can then be
loaded into a new project as a single input photo, and it is then
easy to create any number of different projections and views.

--
Bruno

WaterWolf

unread,
Sep 17, 2010, 11:59:43 AM9/17/10
to hugin and other free panoramic software
Thanks for the advice

I tried reducing the input images to 800 x 600 again with imagemagick
in case the other image resizing tool I was using had caused problems
but it came up with the exact same results. Because I'm creating a 360
degree image there are lots of pictures that are mostly grass and
things like that. I can only guess that reducing the image size must
reduce the image detail enough so that panomatic can no longer find
the control points in the fine detail.

So the only solution I've found so far is to begin to generate the
image in hugin and then cancel it after nona has run. Then I run
imagemagick to shrink the output files from nona to a more managable
size. Then I run enblend manually against the shrunk files.

This is producing good results and is a lot faster but is still a bit
time consuming. 1 hour nona + 1 hour imagemagick + 30mins enblend
(once the file size of a tif goes beyond 300mb, whatever process is
working on it runs out of memory space (3gb) and starts hammering the
hard drive instead).

The final image no longer has strange artifacts in it (it looks rather
good in fact!) so I think the issue must relate to the size of images
being processed. I've been using the latest version of enblend all
along so the issue can't have been fixed yet.

When you say "output size" and "pixel width and height" are you
referring to the "Panorama Canvas Size" in the sticher tab? How do
these fields work? I tried changing them but whenever I pressed the
Create Panorama button they seemed to be reset to some automatically
calculated values.

Thanks, David.

Bart van Andel

unread,
Sep 18, 2010, 11:27:33 AM9/18/10
to hugin and other free panoramic software
On 17 sep, 17:59, WaterWolf <waterw...@gmail.com> wrote:
> When you say "output size" and "pixel width and height" are you
> referring to the "Panorama Canvas Size" in the sticher tab? How do
> these fields work? I tried changing them but whenever I pressed the
> Create Panorama button they seemed to be reset to some automatically
> calculated values.

You should be able to set the desired output width and height in the
"Stitcher" tab, under "Panorama Canvas Size". To create the panorama
using these settings, you can use the "Stitch now!" button on the same
tab. I don't know what the "Create Panorama" button on the "Assistant"
tab is supposed to do, besides creating the panorama. It may be
programmed to first automatically guess the panorama output size
(based on the input files and the other output options), in which case
the values you've entered will indeed be overwritten.

Anyway normally you wouldn't need to resize the input images before
feeding them into Hugin. The rendering process takes care of resizing
for you when writing the intermediate files which are fed to Enblend,
or whatever blending program you're using.

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