Am 03.03.21 um 13:27 schrieb yuv:
On Wed, 2021-03-03 at 10:32 +0100, 'Kay F. Jahnke' via hugin and other
free panoramic software wrote:
With regard to bundling with Hugin:
It is in fact completely new technology. Potentially disruptive.
I have not touched panorama photography for ages, so forgive me if I am
missing something. If it is so disruptive, why not adding to pv the
missing functions from Hugin rather than the other way around?
In a way this is what I've been doing. pv started out as a simple
panorama viewer demo to demonstrate how my library (vspline) was
well-suited for geometric transformations. And then it turned out that
the technology I had developed and which I was using to write the first
version was very well suited to do other image processing jobs. I do a
lot of stuff with images - not only panoramas - and one thing which had
always annoyed me was the break I had between panoramas and 'normal'
images: when a panorama showed in my image viewer, I had to tell the
image viewer to 'open it with the panorama viewer'. And the pano viewer
and the image viewer would have different controls - with panoramas I
like using QTVR mode, and you don't really get that in 'normal' image
viewers. So I added 'normal' image viewing capabilities to pv, in order
to be able to view all images, panoramic or not, with the same software.
And the same UI. And a slide show mode which would show panoramas as
such, with the right projection and FOV read from the metadata. And,
frankly, the image quality most 'normal' viewers provide just isn't
really good enough for my taste. b-splines are simply top notch.
I used a game engine (SFML) for the UI, in fact I decided to implement a
fair amount of 'gamification' and to *not* use a traditional GUI library
like wxWidgets or Qt - instead I programmed a simple 'immediate mode
GUI' with just a few rows of buttons and left the remainder of the UI to
be done with mouse gestures and keystrokes, like a computer game. This
enabled me to 'have nothing between me and my images' - no menus, no
dialog boxes, no popup windows. Of course one has to 'learn to fly' to
enjoy it fully.
So now I could view images/panoramas just fine. What if I wanted to
share them? Would be nice to have a snapshot facility. And when doing
snapshots, why not make them in the background with a very good
interpolator, to several times the screen's size? Turned out to be quite
easy with what I already had.
Oh, I can do snapshots! How about I add viewing and snapshots in
different target projections? I might as well display in e.g. spherical
and when I do a snapshot of that, it's another spherical, maybe with a
fixed horizon or brightness or black point or white balance... and why
only snapshots, why not throw a bit more image processing in the works?
how about HDR? I added HDR blending and live viewing of brackets, so one
can 'explore' the shadows or the clouds by simply varying brightness
(try a horizontal secondary-button click-drag gesture) - and without
having to first create HDR output, but with the *option* to export the
blended bracket to openEXR with a simple keystroke.
Hey, so I can HDR-blend! Maybe I can even do exposure fusion!? How about
just running a B&A image splining algorithm in the background to create
an exposure-fused snapshot? Bingo!
Now, having the B&A code, how about I just feed it spatial masks instead
of brightness-related ones? The code to stitch images should be
precisely the same, give or take a few tweaks... it works!
It all fell into place naturally. No need to take code from somewhere
else. Look at my implementation of the B&A algorithm, and compare it to
'traditional' approaches, and judge for yourself:
https://bitbucket.org/kfj/pv/src/master/pv_combine.cc
Compared to traditional code, this is alien technology. It's all written
using the functional paradigm, you simply compose SIMD-capable functors
and feed them to transform functions, filling in arrays as the functors
are 'rolled out' with efficient multithreading. Once you get used to
work with that technology, you don't want traditional code anymore.
That's why I think it may be disruptive, and why I prefer to code stuff
myself, using vspline.
And in both cases, what is the main obstacle to move functionality from
pv to Hugin or from Hugin to pv?
So I just can't see much point of trying to move code from hugin to pv.
I have programmed everything new, from scratch, using multithreaded SIMD
code on the CPU. If I want to, I can shell out to helper programs
myself, that's no big deal, but it's much faster to work within the same
process and keep the data in memory. Hugin is great for getting the
registration right, and it does the job of providing a GUI for panotools
well. But when it comes to adding capabilities to pv, I prefer to use my
own, modern code base. It's more fun like that as well, and I admit that
I like having the say of what is done and what isn't. pv and hugin
function very well side-by-side - I've even experimented with code where
other programs can signal pv to perform a refresh - I don't get the
reaction time faster than, say, 100msec, so it's not enough to control
animations frame by frame, but for an 'external preview' it's perfectly
fine. All that a software like hugin needs to know is pv's PID and then
it can signal pv to update it's image, as if the user had pressed 'F1'.
No need to integrate further, really.
Hugin and pv are *complementary*.
If memory serves me well, the current preview mode in Hugin was born as
a project to improve the existing preview. Turned out that a complete
replacement was not possible/desirable and so the two lived side-by-
side in the same package. The difference here is that pv started life
in a separate GUI toolkit, or am I mistaken?
So, no tool kit but an 'immediate mode GUI' -
https://en.wikipedia.org/wiki/Immediate_mode_GUI - SFML did not provide
one, but the community had a few hints ready, so I took it from there
and wrote the GUI myself as well. That was fun, too, and I did hope it
would lure some users to my lair... and not having a fat dependency for
the GUI toolkit makes pv lean.
Personally, I don't use the GUI much, apart from starting slideshows or
setting numerical values precisely - or for 'override arguments' -
command line arguments 'injected' at run time to modify the current
viewing cycle. But it does no harm having it.
Kay
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/cefa581a-2ad1-e1c7-3a56-6623adbc7c0c%40yahoo.com.
