enfuse: feature proposal to evaluate 'technical' qualities
kfj
I'd like to point you to a feature proposal I've made for enfuse, and
I'd be curious to hear what you think of it:
https://bugs.launchpad.net/enblend/+bug/927509
Kay
Robert Krawitz
In regards focal length of source image: this would have been very
useful to me when preparing this image:
http://rlk.smugmug.com/Other/Landscapes/4851912_XB4SmT#!i=450968307&k=6dotV
(read the writeup)
I'd also like to see consideration given to combining the blending and
fusing steps. I've experimented with both blend-fuse and fuse-blend
workflows (exposure fused from stacks and exposure fused from any
arrangement -- and no, I don't remember which is which) and find that
both approaches work better in some cases than in others. Blending
exposure layers followed by fusing produces a more uniform fused
panorama, but the blend seams may be different in the different exposure
layers, leading to ghosting (not just for moving object). This happens,
I think, because most of my panoramas are hand-held, and when I do use a
tripod it isn't with a panorama head, so there are perspective issues
that are resolved differently in each layer. If I fuse exposure layers
first and then blend the stacks, the ghosting goes away but I get odd
color/tonal contrasts across the blend seams.
What I think I'd like would be to blend followed by fuse, but to use the
same blending seams for each exposure layer. I realize this would be a
very big change from how things are done now.
--
Robert Krawitz <r...@alum.mit.edu>
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
kfj
> In regards focal length of source image: this would have been very
> (read the writeup)
This sounds very familiar to me. I have developed a few tricks to deal
with multi-lens panoramas. The first thing you need is lots, and I
mean lots of good control points. That's why I wrote the woa plugin,
which warps the images, looks for CPs and then unwarps their
coordinates. This usually gives me such an even spread and good
quality of CPs, even between images from different lenses, that the
optimizer produces very good results. The next plugin which I find
very useful is the crop-cp plugin, which looks at the crop area of the
panorama (as set in the preview) and throws out all CPs either inside
or outside it. This allows me to throw out all CPs which aren't really
crucial for the match (forground, for example - let the stitcher deal
with it best it can). Once I've lots of CPs in useful places left, I
optimize for 'everything but translation' and also do a photometric
optimization. Then I can proceed to stitch each set of images
separately, and I have to do the final composition in another tool, as
well. Lots of work, but, for example in mountaintop 360 degree
panoramas, the extra crispness around the horizon can be worth it.
BTW - a panorama head is a good thing - if most of my photography
wasn't done somewhere in the mountains I'd sure carry on all the time,
and they aren't even dear. I've built my own which was fun and it does
the trick, but out in the wild I rely on a walking stick and a
technique I've evolved over time which works well enough for natural
subjects.
Having tools like enfuse deal with a situation like the one you
describe would be very welcome, hence my proposal. Especially the
layering is annoying for me, because in cinepaint I usually get
annoyed very quickly by how awkward everything is (maybe I've just not
done it enough...), the gimp only does 8 bits, digiKam just isn't
quite there yet and I can't accustom myself to fotoxx either... but at
least on Linux I was able write the plugin interface and the plugins I
need most.
Kay
Bruno Postle
>
> What I think I'd like would be to blend followed by fuse, but to
> use the same blending seams for each exposure layer. I realize
> this would be a very big change from how things are done now.
If you set the enblend --no-optimize parameter then the seams will
be in a consistent location, though they won't exactly line-up
unless your stacks are perfect. The seam optimisation isn't so
important if you are using masks.
--
Bruno
Robert Krawitz
> On 9 Feb., 15:44, Robert Krawitz <r...@alum.mit.edu> wrote:
>
>> In regards focal length of source image: this would have been very
>> useful to me when preparing this image:http://rlk.smugmug.com/Other/Landscapes/4851912_XB4SmT#!i=450968307&k...
>> (read the writeup)
>
> This sounds very familiar to me. I have developed a few tricks to deal
> with multi-lens panoramas. The first thing you need is lots, and I
> mean lots of good control points. That's why I wrote the woa plugin,
> which warps the images, looks for CPs and then unwarps their
> coordinates. This usually gives me such an even spread and good
> quality of CPs, even between images from different lenses, that the
> optimizer produces very good results. The next plugin which I find
> very useful is the crop-cp plugin, which looks at the crop area of the
> panorama (as set in the preview) and throws out all CPs either inside
> or outside it. This allows me to throw out all CPs which aren't really
> crucial for the match (forground, for example - let the stitcher deal
> with it best it can). Once I've lots of CPs in useful places left, I
> optimize for 'everything but translation' and also do a photometric
> optimization. Then I can proceed to stitch each set of images
> separately, and I have to do the final composition in another tool, as
> well. Lots of work, but, for example in mountaintop 360 degree
> panoramas, the extra crispness around the horizon can be worth it.
I'll have to try this next time I do one of those. This isn't really my
panorama season now. Extra sharpness in more important areas was
exactly my reason for the one above.
> BTW - a panorama head is a good thing - if most of my photography
> wasn't done somewhere in the mountains I'd sure carry on all the time,
> and they aren't even dear. I've built my own which was fun and it does
> the trick, but out in the wild I rely on a walking stick and a
> technique I've evolved over time which works well enough for natural
> subjects.
For the things I shoot panos of, I'm not sure how much it would really
help. In a typical situation with grass or the like in the foreground,
with a lot of high frequency texture but no low frequency, it doesn't
matter even if things are way off, as long as the background is good.
One of my panos (from a low mountain top, with our dog in the lower left
foreground) it really would have helped (I wound up having to do a fair
bit of manual work to fix up a big crack in the rock).
> Having tools like enfuse deal with a situation like the one you
> describe would be very welcome, hence my proposal. Especially the
> layering is annoying for me, because in cinepaint I usually get
> annoyed very quickly by how awkward everything is (maybe I've just not
> done it enough...), the gimp only does 8 bits, digiKam just isn't
> quite there yet and I can't accustom myself to fotoxx either... but at
> least on Linux I was able write the plugin interface and the plugins I
> need most.
Fotoxx looks like it's really just for simple things. It has an
interesting approach to panorama stitching, but it's a lot less flexible
than Hugin, and by now I've done enough panos to establish a good
workflow in Hugin. Your crop control points plugin is fantastic, and
the last few panos I did it saved me a lot of time. Combining enfuse
and enblend (enmeld?) would solve my last big problem with extended
dynamic range panoramas. This is an example (look at the sky near the
horizon):
http://rlk.smugmug.com/Other/Landscapes/4851912_XB4SmT#!i=1079376498&k=Gyg2x
GIMP really needs to stop messing around with single window mode and the
like, and get its act together with high bit depth.
Gnome Nomad
> GIMP really needs to stop messing around with single window mode and the
> like, and get its act together with high bit depth.
It sure does. Are they still insisting that no one needs 48-bit color -
then wondering why the pro graphics market considers GIMP a joke?
--
Gnome Nomad
gnome...@gmail.com
wandering the landscape of god
http://www.cafepress.com/otherend/
kfj
> Combining enfuse
> and enblend (enmeld?) would solve my last big problem with extended
> dynamic range panoramas. This is an example (look at the sky near the
I suppose you mean there's a bit of low-frequency vaiation in the sky
colour? Not too bad, though.
> GIMP really needs to stop messing around with single window mode and the
> like, and get its act together with high bit depth.
actually drove me to put up with cinepaint which I had to compile
myself (it was in such bad nick that I had to fix an error in the
source code within seconds of starting the compile but then it ran
through), the documentation is awful, and the UI is awkward. Their
attitude isn't particularly gentle or user-friendly, it's sort of take-
it-or-leave-it. But it does 16bit and is fast.
I'd much prefer gimp, though. What I end up doing now is to keep
everything in 16bit and then just use gimp to 'mix it down' to the
final version to be used for presenting on-screen, which can't use
more than 8 bits anyway - but it's a crutch.
I see in gimp what seems a common trait in FOSS software. People come
along and contribute great features, but they aren't documented. Every
feature is realized in a slightly different way. Eventually the
software ends up bloated and unmanageable, and necessary changes are
impossible because noone knows how to apply them to the heterogeneous
underlying code, and noone cares for boring mainatinance work, because
all the merit goes to the next guy who introduces a cool new feature.
Eventually some adventurous new project pops up who have realized that
all they need is already out there, and by cleverly putting together a
few building blocks which would have been just what the makers of the
dinosaur project would have created back then if they had had today's
resources, they manage to launch everyone's new darling program.
It looks like the only successful FOSS projects are those which have a
single person driving the thing, best is a BDFL, like Guido van Rossum
for python. Someone has to make rules about what's acceptable and what
is not, and rules are best made by someone who's got deep insight into
the scope, concept and implementation of the project, which is
typically the person who started it. Letting 'the community' decide
what should be done results in what you see in the gimp - and all I've
seen from them recently is littke more than stagnation.
I feel in hugin we have a fundamental problem: the whole thing rests
on libpano, which is a thing from the past and very hard to approach,
since it's largely undocumented (the attitude is 'the code is the
documentation') and it's creator seems to have abandoned it (good
code, though - really, it's a shame it's only C and not more
transparent). On top of that is a layer of C++ which is quite
confusing, because it encapsulates all the libpano library code in a
plethora of objects which is, yet again, sparsely documented (and
looks overdone to me at times), and on top of the C++ layer is another
layer of GUI code, which isn't really separated from the backend, so
that backend functionality has made it's way into the GUI code.
Finally, the whole show relies on helper programs which sometimes
exhibit great inertia when it comes to problems, and the interfacing
with the slave programs is awkward. If you want anything done in
hugin, you may have to penertrate these four different layers. This is
a real show-stopper. It makes it very hard for people to contribute.
Well, I'll stop my rant here and go do something useful (I'm trying to
help introduce a general coordinate remap function into vigra and
vigranumpy after having convinced Ullrich Koethe that it's a good
idea, but vigra's generic code is very demanding, and currently I'm
struggling with the boost.python interface to get the C++ routine,
which works already, to run in python...)
Kay
Robert Krawitz
> On 10 Feb., 03:59, Robert Krawitz <r...@alum.mit.edu> wrote:
>> Combining enfuse
>> and enblend (enmeld?) would solve my last big problem with extended
>> dynamic range panoramas. This is an example (look at the sky near the
>> horizon):http://rlk.smugmug.com/Other/Landscapes/4851912_XB4SmT#!i=1079376498&...
>
> I suppose you mean there's a bit of low-frequency vaiation in the sky
> colour? Not too bad, though.
More than a bit, to my mind. It doesn't look very natural.
>> GIMP really needs to stop messing around with single window mode and the
>> like, and get its act together with high bit depth.
>
> Indeed. It's a big nuisance they aren't getting it together. It
> actually drove me to put up with cinepaint which I had to compile
> myself (it was in such bad nick that I had to fix an error in the
> source code within seconds of starting the compile but then it ran
> through), the documentation is awful, and the UI is awkward. Their
> attitude isn't particularly gentle or user-friendly, it's sort of take-
> it-or-leave-it. But it does 16bit and is fast.
>
> I'd much prefer gimp, though. What I end up doing now is to keep
> everything in 16bit and then just use gimp to 'mix it down' to the
> final version to be used for presenting on-screen, which can't use
> more than 8 bits anyway - but it's a crutch.
The problem with GIMP -- IMHO -- is that they're letting themselves get
sucked into UI details, while ignoring what's really needed for high-end
graphics work. They put a lot of effort into single window mode to try
to make it feel more comfortable to Photoshop users, but meanwhile GEGL
is lagging.
Cinepaint always crashes on me when I try to use it, and it's so out of
date that I find it impossible to do anything of any sophistication.
Gnome Nomad
As long as they don't support 48-bit color, they won't get many
Photoshop users.
> Cinepaint always crashes on me when I try to use it, and it's so out of
> date that I find it impossible to do anything of any sophistication.
Haven't tried Cinepaint in years.
I'm doing more panos now as 16-bit TIF, then converting the final
product down to 8-bit using RawTherapee.