Am 07.03.21 um 10:05 schrieb Harry van der Wolf:
Sorry. Long mail.
Op za 6 mrt. 2021 om 20:03 schreef yuv
From far away, it looks like there are four alternatives:
(a) do nothing;
(b) distribute pv along Hugin;
(c) integrate pv's functionalities into Hugin; or
(d) integrate Hugin's functionalities into pv.
My vote would be for (b), just like Kay himself also mentions.
That's also what I would propose. The distribution process is already
established, and building pv as yet another binary to 'ride out' with a
hugin bundle should not be too hard - I have already put a lot of work
into making porting easy, as you can see from the fact that we have
proof of build and execution on Linux, macOS, Windows and even on the
Raspi's ARM processor.
Due to my licensing, everyone who complies with the GPLv3 is of course
free to 'rip my code apart' or fork pv, but I think there's not so much
interest for that - maybe after some time. And I like being upstream -
the debacle with hugin's python interface which has never made it far
beyond linux and broke with every new release is a warning to me: I'd
rather be responsible for my own code, remain upstream, and fork out
'release' versions which might be packaged with hugin, if the hugin crew
thinks that's a good idea. Packagers might also simply provide a
'flavour' of hugin which includes pv, and let the user choose which she
picks.
How far is pv from being a replacement to Hugin, and do you see it
going there?
Not there (yet). Hugin has way more tweaking options to create great
looking panos. Translations for example are not supported by pv (yet?),
and neither are masks.
That is correct. Really, pv is a panorama *viewer*, and so far the
stitching and blending capabilities are 'nice to have' extra features.
They are also a playground for my new technology, my library 'vspline'
which does all the 'heavy lifting' in the background - and for it's
application to image processing. I use pv as a showcase of how image
processing applications can profit from vspline, and as a handy test bed
to work on my image processing ideas. I hope that some of my development
work turns out to be attractive to other people so that they may *want*
to use vspline or some of pv's code - for example for blending and
stitching. I'm making an offer.
Having an application out which exhibits desirable features may help
popularize the underlying technology. It's interesting stuff, and it's
sad that so far it's largely ignored - I put a lot of effort into it,
and vspline is now quite mature and stable. Releasing it through debian
makes new versions 'trickle down' quite slowly, that's why I enclude
full vspline source code in pv's repo - vspline is header-only.
Next to that: The Hugin assistant makes things way more easy than
currently in pv. Of course: also getting the most out of Hugin, as in
pv, requires some in-depth knowledge.
Also: pv's goal is to also improve your already created images (or
panoramas).
And to *display* them adequately. With smooth zooms and pans, QTVR-like
control, easy snapshotting, slideshows, etc. pp. - this is pv's core
functionality. Display your images and panoramas. Under a common
surface, with high quality, and an interface which 'puts nothing between
you and your images'. And with many options for experts who want to go
'deeper'.
Conversely, how different is pv from Hugin and how difficult would be
that integration work? I suspect that the use of a different GUI
Toolkit is a major obstacle, but your expertise my intuition wrong?
Which brings us to what I understand is your proposal, to distributed
pv along Hugin. The cost to Hugin are "only" more build/distribution
complexity. Or am I missing something? And it does not seem to be
such a heavy toll, based on Harry's feedback here. Do the benefits to
Hugin's users justify the extra build/distribution complexity? And are
there things that can be done to reduce that complexity, e.g. moving pv
from bitbucket to the same repo as Hugin?
I can't and won't say anything about the difference in code. I leave
that to the experts.
But indeed: I see it as a supplementary tool. At least for the time being.
It can be added to Hugin as an extra app bundle (apple) or as a tool, or
as an extra exe (on windows). Linux is of course the easiest one.
When looking at Hugin, like yuv described, Hugin is really a combination
of all kind of tools.
Enblend and enfuse need to be dragged in (or multiblend for that
matter). libpano13 is often too old and needs to be built as well. Both
on windows and mac almost everything needs to be downloaded and compiled.
For me integration is not one big monolithic binary doing everything,
but a suite consisting of nicely integrated tools via APIs.
I say it again: pv and hugin are complementary. If, eventually, it turns
out that one may benefit from the other in a more direct way (like code
sharing) that can be dealt with later.
hugin and pv code are very different: hugin uses a set of external
helper programs for many things, and is based on a C++ wrap of an old C
library, libpano. It relies on disk storage for intermediate results. pv
is 'monolithic' and keeps everything in memory (limiting the maximum
size of image/pano it can handle) - and everything is programmed afresh
from scratch in C++11, relying on vspline's multithreaded SIMD code.
Please do have a look at vspline's and pv's source code and convince
yourself that it also is well-structured and well-commented - I find
some of hugin's code base hard to access.
If you look at web technology where all kind of technologies need to be
connected, you see that APIs (or interfaces or "command line" parameters
on a local platform, if you like) are the way forward to connect and
integrate different technologies.
pv and hugin do not need to share any API. pv shows images, and PTOs.
PTO format is not exclusive to hugin, but a panotools standard. that's
all the common ground that's needed. pv even has it's own format for
synoptic views (adding, for example, display of 'cubemaps' which
hugin/panotools does not use) - but I wanted to open it up to the
'panotools universe' to make it easy for users: they already have their
panoramas in PTO, so why force them to use my PTO to ini file
translator? PTO is quite easy to parse. And everyone has images!
This also allows for developments (leaps in developments) in the
separate tools as long as the API or interfaces remains consistent.
Adding an extra option will not break anything.
I agree.
I am not a programmer (weel, an amateur at best), but in my work we
bring a lot to the cloud where you have saas, paas, iaas solutions on a
number of platforms (AWS, Microsoft, Google to name the biggest ones)
which you want to talk to each other (in a safe and secure way). Nobody
nowadays does everything in one "tool".
Why not pv also? It uses the same libraries as already necessary for
Hugin and all the tools, with one "extra": Vc, and Vc needs to be of
high enough version. Which means it can be treated like libpano.
I think pv is actually easy to build - compared to software like hugin.
Vc is a bit tricky: it's also a very good library, but like vigra it's
not so widely used, and does not have too much manpower behind it. It's
author, Matthias Kretz, has been part of formulating the upcoming C++
standard std::simd, and he is currently working on producing a good
reference implementation for this standard, and aims at implementing Vc
2.0 using std::simd. I have an experimental pv version out using
std::simd which can use his std::simd implementation, but the standard
has a few shortcomings, which hamper it's use: it omits SIMD
gather/scatter operations and also Vc's combined load/shuffle and
shuffle/store routines, which are very relevant for working with
interleaved data (like pixel arrays). I have coded around these issues,
but the resulting code is definitely slower than using Vc, which has all
these capabilites - and for smooth animations, every millisecond counts,
so I stick with Vc for now.
And with regard to integration: pv started as panorama viewer. In Hugin
you could add as setting: "Open created panorama in pv", just like we do
with another non-C, non WxWidgets, non-integrated tool being exiftool
acting on our created pano from our original images.
Opening pv from Hugin after creation gives you an immediate view on your
results.
And pv can in that case also give you immediate options to tweak your
created panorama.
Let me stress this point, too: with pv, you can directly look at the
PTO, just like at any other image. You don't have to stitch first. You
have the full set of options a panorama viewer offers to inspect the PTO
in great detail. You can set the output projection as you like, and
still zoom and pan etc. - and if you like what you see you can instantly
have 'hard copies' with the press of a single key.
My notion of 'live stitching' is an attempt to even make stitching
unnecessary - if the images fit well, the brightness is correctly
adjusted, and there is a bit of feathering, oftentimes that's perfectly
good enough - and it's instantly available. 'Live stitching' also has a
few advantages: if you have tele shots mixed in with interesting detail,
you can zoom in to the tele shot's full resolution. With stitched panos,
you only ever get the resolution the pano was stitched to. And if the
images vary in brightness, you still have the full range visible - you
can 'peek' into dark shadows or bright clouds, if your take has them -
in a stitched image, stuff gets clipped unless you stitch to HDR. Check
it out, it's great, I'm sure you'll like it. All this talk is academic,
really - Harry and I have made bundles for macOS and Windows, all you
need to to is download and try it. What are you waiting for?
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 hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/0167d2e2-31a8-cff0-986e-8077df472963%40yahoo.com.
