Hi group!
Back from a few weeks of trekking in Italy I am processing the accumulated
imagery. Anticipating need for HDR-able material (for a project of mine
I've not published yet) I had taken most of the individual images for my
panoramas as AEB brackets. But my own new project was nowhere near ready,
so for now I was stuck with what I had, good old hugin. I set to work using
a plugin to create the stacks of three images I usually take, using a Canon
EOS450D. I tried to get the plugin to be distributed with hugin some time
ago, but it wasn't compliant with the API and was therefore rejected - but
it worked for me, so I kept it to myself and used it, nevermind it was
doing what it was doing in a way which was somehow forbidden. All was well,
and I managed to create a few halfway decent panoramas, but I ran into
problems with the readymade package I was using: it had the hardcoded
default of considering everything a stack which overlaps 70% or more
(outputStacksMinOverlap) - the mechanism which is used to assemble the
images for exposure fusion, instead of using the stacks which are defined
in hugin (to use a two-step CPG on). I had previously modifies this value
in my personal version of hugin, but with an OS update my edits had
disappeared into digital nirvana. So I traced down the responsible bit in
the sources again (the default value is in
.../hugin.hg/src/hugin_base/panodata/PanoramaOptions.h), changed it from .7
to .85 (this works for me), and recompiled... ... ...
Finally it was done and by that time I had also figured out that an extant
panorama carries the threshold value in the pto file, where it will remain
unimpressed by a change of the default (which makes sense) but short of
changing the pto with a text editor I found no way to change it (which
doesn't make sense). So anyway, the value is towards the end of the pto and
looks something like this:
#hugin_outputStacksMinOverlap 0.85
All on needs to do is change the value and restart hugin with the modified
pto.
Whichever way, I now had the overlap issue sorted, and the stacks hugin
sent to enfuse for fusing were the same as the stacks I had defined using
my plugin, nevermind they were made up by a different mechanism... I still
feel there should be an option to use the stacks defined in the pto instead
of the outputStacksMinOverlap mechanism - maybe there is one but I haven't
found it.
Now hugin (at least in a reasonably recent incarnation) has a nifty
feature: one can select a bunch of images (not in the openGL preview - that
selection is a different selection) but in the images tab in the main
window - probably only in expert mode, I don't know the other ones - and
then rightclick, go via stacks and enter a stack size. I entered three and
lo and behold, there were now the stacks of three images, like what my
plugin made. I thought, oh great, here I can even enter the number of
images per stack (I had refrained from using a python-wx dialog in my
plugin to inquire for the number of images per stack and instead hardcoded
the value in the prototype, and then, when it was rejected, left it like
that since I hardly ever use anything else) - so I decided to forget about
my plugin and use the nice stacking feature instead. The next few panoramas
were very frustrating. No matter what number of control points I had, where
I placed or deleted them, I just couldn't get them right - the images would
never quite fit, but instead be a few pixels off here and there. I though
I'd just not worked properly - it was all freehand on top of a Leki stick,
as I usually do, but I hadn't done any in the winter so I thought my skill
had just atrophied for lack of exercise...
I slept over it. I looked at the faulty panoramas again. Finally I had the
good idea to look at the image positions. And there I saw that I had shot
myself in the foot: by abandoning my plugin for hugin's more convenient
stacking feature I had created different stacks: the stacks I now had were
position-linked, and I had plain forgotten that this happens when assigning
stacks with hugin, while my plugin creates stacks which are not
position-linked! Somewhere in the old interface there was a way to
position-unlink stacks. Of course noone would guess that stacks which are
deliberately fed to the CPG to create CPs to position the images properly
would be position-linked by default... maybe I should have read the
manual... but there once was a way to unlink the positions in the GUI, I'm
quite sure. Try as I might, though, I just couldn't find it now. Is it
still there? I's quite possible to do it by manipulating the pto, again,
but that's fiddly. Nevermind that, I found a simple way of working around
the issue: Since the stacks, produced by my plugin or by hugin's stacking
feature, are totally irrelevant once the two-step CPG is done (unless one
wants and uses position-linked stacks, of course), one can just throw them
away, with
