Hugin and common problems with enblend, fails to process 360 pano
Jaroslav
1) enblend fails when the images are shot with too much overlap,
remove that feature from enblend
"enblend: excessive overlap detected; remove one of the images"
Does anybody have a corrected version of enblend?
I got the sources and found a discussion here with a link to the code
segment, but do I really have to do it myself?
Anybody has an experience compiling enblend sources on Win32?
2) enblend basically goes to hell with bigger panoramas.
I have 42 images (4000x3000 8bit JPG), 14 stacks with 3 pics.
It's a 360x36° pano, it goes all the way to enblend where it fails.
~~~~~~~~~~
"C:/_app/_graphic_2D/Hugin/bin/enblend" -w -f32933x2684+0+351 -o
"IMG_0443-IMG_0535_reduced_hdr.exr" -- "IMG_0443-
IMG_0535_reduced_stack_hdr_0000.exr" "IMG_0443-
IMG_0535_reduced_stack_hdr_0001.exr" "IMG_0443-
IMG_0535_reduced_stack_hdr_0002.exr" "IMG_0443-
IMG_0535_reduced_stack_hdr_0003.exr" "IMG_0443-
IMG_0535_reduced_stack_hdr_0004.exr" "IMG_0443-
IMG_0535_reduced_stack_hdr_0005.exr" "IMG_0443-
IMG_0535_reduced_stack_hdr_0006.exr" "IMG_0443-
IMG_0535_reduced_stack_hdr_0007.exr" "IMG_0443-
IMG_0535_reduced_stack_hdr_0008.exr" "IMG_0443-
IMG_0535_reduced_stack_hdr_0009.exr" "IMG_0443-
IMG_0535_reduced_stack_hdr_0010.exr" "IMG_0443-
IMG_0535_reduced_stack_hdr_0011.exr" "IMG_0443-
IMG_0535_reduced_stack_hdr_0012.exr"
enblend: warning: no usable resolution found in first image "IMG_0443-
IMG_0535_reduced_stack_hdr_0000.exr";
enblend: warning: will use 300 dpi
enblend: info: loading next image: IMG_0443-
IMG_0535_reduced_stack_hdr_0000.exr 1/1
enblend: out of memory
enblend: bad allocation
enblend: info: remove invalid output image "IMG_0443-
IMG_0535_reduced_hdr.exr"
enblend: warning: could not remove invalid output image "IMG_0443-
IMG_0535_reduced_hdr.exr": No such file or directory
make: *** [IMG_0443-IMG_0535_reduced_hdr.exr] Error 1
~~~~~~~~~~
What I have figured out is that the enblend bundled with Hugin does
not use disk cache probably or at least -m -b parameters do not work.
The binaries are way larger, maybe OpenMP, than standard enblend 4
release. So I tried enblend 4 release, but it failed as well, ran it
from command line with the above command from the log. Took several
hours, ate few GB on the harddrive while processing and the result is
a 25MB EXR. The file is too small, and when opened it has a very small
part of the image, it has some little artifact, the rest is black
where the panorama should have be with some white borders the should
have been cut off IMHO. The resolution of the image appears to be
correct, 32000x3600 approximately.
~~~~~~~~~~~~~~~~~~~~~
D:\_Hugin>enblend -m 512 -b 1024 -w -f32933x2683+0+503 -o "IMG_0443-
IMG_0535_re
duced_hdr.exr" -- "IMG_0443-IMG_0535_reduced_stack_hdr_0000.exr"
"IMG_0443-IMG_0
535_reduced_stack_hdr_0001.exr" "IMG_0443-
IMG_0535_reduced_stack_hdr_0002.exr" "
IMG_0443-IMG_0535_reduced_stack_hdr_0003.exr" "IMG_0443-
IMG_0535_reduced_stack_h
dr_0004.exr" "IMG_0443-IMG_0535_reduced_stack_hdr_0005.exr" "IMG_0443-
IMG_0535_r
educed_stack_hdr_0006.exr" "IMG_0443-
IMG_0535_reduced_stack_hdr_0007.exr" "IMG_0
443-IMG_0535_reduced_stack_hdr_0008.exr" "IMG_0443-
IMG_0535_reduced_stack_hdr_00
09.exr" "IMG_0443-IMG_0535_reduced_stack_hdr_0010.exr" "IMG_0443-
IMG_0535_reduce
d_stack_hdr_0011.exr" "IMG_0443-IMG_0535_reduced_stack_hdr_0012.exr"
enblend: warning: no usable resolution found in first image "IMG_0443-
IMG_0535_reduced_stack_hdr_0000.exr";
enblend: warning: will use 300 dpi
enblend: info: loading next image: IMG_0443-
IMG_0535_reduced_stack_hdr_0000.exr 1/1
enblend: info: loading next image: IMG_0443-
IMG_0535_reduced_stack_hdr_0001.exr 1/1
enblend: info: loading next image: IMG_0443-
IMG_0535_reduced_stack_hdr_0002.exr 1/1
enblend: info: loading next image: IMG_0443-
IMG_0535_reduced_stack_hdr_0003.exr 1/1
enblend: info: loading next image: IMG_0443-
IMG_0535_reduced_stack_hdr_0004.exr 1/1
enblend: info: loading next image: IMG_0443-
IMG_0535_reduced_stack_hdr_0005.exr 1/1
enblend: info: loading next image: IMG_0443-
IMG_0535_reduced_stack_hdr_0006.exr 1/1
enblend: info: loading next image: IMG_0443-
IMG_0535_reduced_stack_hdr_0007.exr 1/1
enblend: info: loading next image: IMG_0443-
IMG_0535_reduced_stack_hdr_0008.exr 1/1
enblend: info: loading next image: IMG_0443-
IMG_0535_reduced_stack_hdr_0009.exr 1/1
enblend: info: loading next image: IMG_0443-
IMG_0535_reduced_stack_hdr_0010.exr 1/1
enblend: info: loading next image: IMG_0443-
IMG_0535_reduced_stack_hdr_0011.exr 1/1
enblend: info: loading next image: IMG_0443-
IMG_0535_reduced_stack_hdr_0012.exr 1/1
enblend: info: writing final output
D:\_Hugin>
~~~~~~~~~~~~~~~~~~~~~
So, how to stitch a big 360 panorama with Hugin? On a Win32 with 2GB
ram and lots of disk space.
Because the standard release certainly does not work with such things
well :(
Or what software do I need to work with lots of big images like this?
Are there any commercial alternatives that work? I don't have
especially good experience with Kolor Autopano Giga as well, full of
errors too.
And how do I tonemap a HDR pano that will be that huge? Is there any
software that will handle it, or will it all just stupidly die out of
memory?
Now I'm trying to do the same panorama just from 4 times smaller
images, will see how that goes.
Jaroslav
Hugin to HDR EXR, but it is not correct, see for yourself:
http://i.imgur.com/7JxKh.jpg
(Exposure, gamma, converted to 8bit and JPG)
Autopano Giga basically calculates indefinitely, got stuck somewhere,
hate that software.
With full size images it just yells something like out of memory and
refuses to process, I wonder how do they do the Giga panoramas with it
then...
Any ideas why HUGIN and enblend fails to do the 360 panoramas?
The HDR stacks look ok, just one has small black area in the very
light part, so the pictures should be ok that are fed into enblend.
Or where can I at least report bugs in enblend or Hugin?
I'll try different outputs and formats, but it's annoying and takes
time. Don't they test and debug these tools at all?
kfj
> Any ideas why HUGIN and enblend fails to do the 360 panoramas?
Sorry I can't help you here - I'm on Linux and I'm not doing HDR, but
your description of what you are trying to do on a 2G Windows machine
sounds like asking for trouble - you're right insofar as enblend
should use swap space if it can't manage with the memory it has, but I
think it doesn't, and a quick rule-of-thumb calculation I did told me
that your anticipated result would take up just under 2G - by itself.
> Or where can I at least report bugs in enblend or Hugin?
I can help you here: try
https://bugs.launchpad.net/enblend/+bugs
Just to dampen any high hopes you might have, in my experience
reporting bugs there may take a long time to produce a response, let
alone a solution... but it's definitely worth a try.
> I'll try different outputs and formats, but it's annoying and takes
> time.
You could try and create parts of the panorama sequentially, like left
third, middle third and right third, if you have to create a very big
image.
IMHO, doing HDR and tonemapping the image is really only necessary for
very special purposes. Usually the results you get from using enblend
on the stacks are more pleasing to the eye than tonemapped HDRs. That
way, the processing is possible with less memory consumption - even if
you work in, say, 16 bit TIFF, you still need only about half of what
HDR takes.
> Don't they test and debug these tools at all?
Who is 'they'? We're in FOSS world here. To me 'they' is the guys who
SELL you software that doesn't work, and 'us' is the guys who are
trying to get a good thing going without commercial constraints - and
without commercial rewards either. So it's 'us' debugging and testing
the stuff, and you're welcome to join in. If you're unhappy with what
we have to offer, make it better by getting involved or throw your lot
with the next best free open source panorama package (and when you
find one that's so good you want to settle with it, drop us a line ;-)
Kay
Jaroslav
> your description of what you are trying to do on a 2G Windows machine
> sounds like asking for trouble - you're right insofar as enblend
> should use swap space if it can't manage with the memory it has, but I
> think it doesn't, and a quick rule-of-thumb calculation I did told me
> that your anticipated result would take up just under 2G - by itself.
The enblend bundled in Hugin is some modified or at least recompiled
version of enblend 4, it does not have disk cache.
I switched it for the original enblend 4 and that does have disk cache
and the -m -b parameters work.
The panorama from reduced images looks the same on both enblend 4
versions. Version 3.2 looks better, shows more in the output panorama
but still has the same errors on the same places, but the black area
is smaller.
2GB ram should not be a problem, unless the program tries to do
something that the OS doesn't allow (allocating too much memory),
otherwise the OS will just swap it, there is enough space for that.
> I can help you here: try
>
> https://bugs.launchpad.net/enblend/+bugs
Thanks, I'll give it a try if I pin point something down precisely.
> > I'll try different outputs and formats, but it's annoying and takes
> > time.
>
> You could try and create parts of the panorama sequentially, like left
> third, middle third and right third, if you have to create a very big
> image.
I' trying to get a correct result with a smaller amount if images,
removing parts of the panorama.
Or how can I split the panorama into more parts/jobs? I saw some
gigatile around here mentioned to split it into more jobs.
I was trying to find something about making and browsing huge giga
panoramas, seems like I ran into problems even with just a small HDR
panorama :(
> IMHO, doing HDR and tonemapping the image is really only necessary for
> very special purposes. Usually the results you get from using enblend (ENFUSE)
> on the stacks are more pleasing to the eye than tonemapped HDRs. That
> way, the processing is possible with less memory consumption - even if
> you work in, say, 16 bit TIFF, you still need only about half of what
> HDR takes.
Yes fused outputs work here.
I was making a small panorama only 160° and the HDR was quite some
trouble as well but all outputs were correct, just my trouble with
masks.
Fused output is weird sometimes, or in some parts and I have no
control over it.
I don't know what the problem with enblend is, LDR is usually ok if I
remove the overlapping images but HDR produces errors (black areas) in
the output without any warnings. And that is for a 1000x750 images 1/4
of the full size. The images fed into enblend are correct, no black
areas.
> > Don't they test and debug these tools at all?
>
> Who is 'they'? We're in FOSS world here. To me 'they' is the guys who
> SELL you software that doesn't work, and 'us' is the guys who are
> trying to get a good thing going without commercial constraints - and
> without commercial rewards either. So it's 'us' debugging and testing
> the stuff, and you're welcome to join in. If you're unhappy with what
> we have to offer, make it better by getting involved or throw your lot
> with the next best free open source panorama package (and when you
> find one that's so good you want to settle with it, drop us a line ;-)
They = developers of the tools.
I don't mind joining in or debugging the problems I encounter, but is
there any documentation of the code? That's usually the biggest issue
with open source, no documentation :(
I already got one idea, putting the images into stacks automatically,
it's "real fun" clicking a hundred of images into stacks...
Or should I just ignore stacks with HDR and don't use
align_image_stack.exe? I doubt that.
kfj
> I don't mind joining in or debugging the problems I encounter, but is
> there any documentation of the code? That's usually the biggest issue
> with open source, no documentation :(
Sadly this is true. The only documentation on how to use the software
is in the panotools wiki, but noone seems to have bothered to document
the code much or present a technical outline of what is where and why.
The situation is worsened by the fact that the core library hugin
relies on, libpano, isn't really documented either. Just for the
laugh: today I posted to their (libpano's) developer mailing list and
I saw that the last post was three months ago by a guy asking 'where
is the documentation'. He didn't even get an answer. I must be mad
throwing my lot with such a bunch... but some of the software is
excellent ;-)
> I already got one idea, putting the images into stacks automatically,
> it's "real fun" clicking a hundred of images into stacks...
> Or should I just ignore stacks with HDR and don't use
> align_image_stack.exe? I doubt that.
I wrote a python plugin which does precisely that (putting the images
into stacks), but so far the python interface is only readily
available for some Linux users. The python interface code works under
Windows as well, but AFAIK none of the packagers has created an
installer which contains it, so if you want the code you have to
compile yourself, which is a tall order under Windows. This is the
status quo after the code has been made to run under Windows sometime
this spring. So I can't help you here, either - I'm quite frustrated
myself that my code (I wrote the python interface) is withheld from
the wider public because of some statically-linked-versus-dynamically-
linked argument, if that really is what it is...
I asked here for help with some finer points in the stacking code so
that I could make a really nice plugin, but I didn't get a reply to
that post, either. So it's sitting here half ready and works for me,
but I've given up any hope for help with the code. It's read the code
or wait for others to provide what you need.
If you're capable of doing stuff on the command line - pto files are
plain text files and you can just use text processing tools to adapt
the stack numbers in the pto.
Kay
Bruno Postle
>The situation is worsened by the fact that the core library hugin
>relies on, libpano, isn't really documented either. Just for the
>laugh: today I posted to their (libpano's) developer mailing list and
>I saw that the last post was three months ago by a guy asking 'where
>is the documentation'. He didn't even get an answer. I must be mad
>throwing my lot with such a bunch... but some of the software is
>excellent ;-)
The situation with libpano13 is that people come and go and work on
it when they have a feature or a bug to fix. It is mature so there
isn't much pressure to change it, though there are lots of people
who can commit code. I've done the recent releases whenever there
was some reason to get improvements out to the users.
Basically: if you are working on adding vectorisation then you _are_
the libpano13 developers ;-)
Don't be surprised if you don't get much feedback. If you want the
patch committed, you need to say it is ready, or ask for commit
access. If there are changes that are important for Hugin then we
can coordinate releases.
--
Bruno
kfj
> The situation with libpano13 is that people come and go and work on
> it when they have a feature or a bug to fix. It is mature so there
> ...
> Basically: if you are working on adding vectorisation then you _are_
> the libpano13 developers ;-)
Point taken. But how about extending the notion of 'mature'? To me,
maturity in software doesn't only mean running without crashing and
doing what is intended, but it also includes a cleanly defined
interface and documentation. I have dug into libpano's code every now
and then and whenever I made the effort to figure out what it's doing,
I found it does it quite well indeed. But it was always a big effort.
Library code without documentation isn't worth half what it would be
worth with it. I only have that much time to spare for working on it,
and if I have to spend 90% of my time figuring out what it does, I can
only spend 10% on improving it. Not documenting code puts a spanner in
a project's work and actively discourages others from participating:
most people who consider participating will look at it, say 'oh my
god' and turn elsewhere.
> Don't be surprised if you don't get much feedback. If you want the
> patch committed, you need to say it is ready, or ask for commit
> access. If there are changes that are important for Hugin then we
> can coordinate releases.
Fair enough. I am yet far from committing a patch, as I haven't really
made up my mind on how to deal with strided data and what other code
there might be which would lend itself easily to vectorization. One of
the problems I have in assessing the situation is the lack of a proper
interface to the library - in my experience usually library libXYZ has
something like XYZ.h which defines what functions and types are
available, and in libpano it's all in various header files - it looks
like the library was only a second thought and initially all the
panotools were just statically linked.
Wouldn't it be a noble aim for the libpano developers (and here I mean
those who already know the code) to share their knowledge? I know that
Mr. Dersch seems to be out of the picture - I suppose he has started
the tradition of just coding the stuff never mind anyone else - but
maybe some of those who take care of libpano now have gained
sufficient insight to improve on his 'documentation'?
Kay
Bruno Postle
>
> Wouldn't it be a noble aim for the libpano developers (and here I
> mean those who already know the code) to share their knowledge? I
> know that Mr. Dersch seems to be out of the picture
You imagine that there is a team of panotools developers waiting to
jump into action. In practice the libpano13 on sourceforge is
basically Dersch's library with bug fixes, portability fixes,
versioning, and some expansion of pre-existing features - Such as
the new projections.
For the reasons you mention, but also because it is a more suitable
place to add 'higher-level' code, new panorama features tend to get
added to the Hugin codebase - Where documentation is better, if not
consistently so.
--
Bruno