Am 03.03.21 um 13:33 schrieb Harry van der Wolf:
Op wo 3 mrt. 2021 om 10:32 schreef 'Kay F. Jahnke' via hugin and other
free panoramic software <[email protected]
<mailto:[email protected]>>:
> The current Hugin builders on Mac are Niklas Mischkulnig and Bob
> Campbell. All credits to them (not to me).
Maybe they'll take note of pv and become interested in the mac
version -
after all the branch is already there and you demonstrated that it's
dead easy to create a binary. Sadly, my work so far has not got much
attention.
It should not be too difficult to add it to the Hugin bundle package.
The hugin package consists of 4 separate bundles (Hugin.app,
HuginStitchProject.app, PTBatcherGUI.app, calibrate_lens_gui.app).
If this is not "allowed", it is not too difficult either to build a
separate pv bundle. Not difficult (if you know how to do it), but quite
some work.
I'd much prefer if I did not have to do this myself. When I offered my
library, vspline, to debian, they said to me: 'if you want your software
to show up in debian anytime soon, you'll have to packge it yourself'.
Gulp. So I sat myself down and learned debian packaging, found a mentor,
made mistakes, learned more... it took *months*. I remember a time when
you could excite people by offering them good software - people would
say 'hey that looks great, we'll package it' - nowadays even the search
engines only find what 1000000 social media users have 'liked',
relevance does not seem to be an issue anymore, and everyone already has
everything, why would they even look at what you've made? I felt my work
was relevant, so I did the debian packaging myself, but I would much
rather have spent my time coding.
Anybody out there?
I would use macports for this over homebrew. Homebrew uses as much as
possible the libraries available on the system. Macports tries to build
as many libraries itself as it can and only uses the real system
libraries. That macports build process on installing takes much longer
as it will build more libraries. Homebrew uses libiconv, libexpat, libz,
liblzma, etcetera from MacOS. Macports builds these itself.
For a "my system only", homebrew is a more convenient, easier and faster
way to install new ports.
Macports gives you more portabality and MacOS "cross-version"
compatibility if you bundle an app.
Macports was the choice I made when I first ported pv to the mac. And it
had all the dependencies. But it is asking a lot from users. To just be
able to use macports at all, I had to first install xcode, which takes
very long indeed, and you may have a notion of your typical mac user...
they want some nice shiny icon in the store to click on, rather than
having to go through installing first xcode, then macports, then git and
clang++ and Vc, and finally load a port file...
Note: Mac bundles do have the Info.plist setting
<key>NSHighResolutionCapable</key>
<string>True</string>
The latest Hugin build had issues with this and those were apparently
just solved by Bob and Niklas (one of the other conversations about the
hugin mac build).
I only have that old Macbook Pro and can't test high resolution
functionality of pv.
My friend who's done the last few test builds on a fat iMac, complained
about the GUI looking funny on his retina display. So I added code which
makes it adapt to the desktop size, and you can also simply scale and
move it with mouse gestures. After that he did not complain anymore and
only said that everything works, but he's a busy man and does not spend
too much of his time testing my software.
Of course if pv is rendering to a 5K screen in native resolution (which
is what it does per default) animations may stutter, because it's hard
to get 60fps at that size. But you can just tell pv to lower resolution
for animated sequences (once the animation, like a zoom or pan, stops,
it will switch to full resolution still images) - so pv works well with
high resolution, and because it does not depend on a GUI library, but
instead renders the GUI itself with a bit of openGL code, the screen can
be any resolution. No problem.
Now it's my turn to be 'a bit sad'. I've spent about seven man years
creating a b-spline library and a beautiful, powerful panorama viewer
which now can even do some stitching and exposure fusion on top of
everything else. It would be sad to just rip it apart and take a few
bits as helper programs for hugin.
> ...
Sorry to make you sad. ;)
You have some very good arguments (at least in my eyes).
Thanks
Like in all Open Source projects: "if you feel an itch, scratch it". You
simply did what many other developers did (and what I did myself).
Look-alike packages can still have different origins, different goals
and different appliances (and based on your arguments: different
technology).
And I did not know of all the effort you already put into it.
The biggest part was my library, vspline. That's the real achievement,
and it does not 'just' calculate every thinkable type of b-spline, but
it has extremely efficient multithreaded code to 'roll out' SIMD-capable
functors over n-dimensional arrays. The trouble is that it's novel, and
not so easy to grasp, because all the novel concepts interact tightly,
and it's hard to find a way into it, because everything interacts with
everything else. Without vspline, I could never have hoped to get 60fps
of geometrically transformed frames from the CPU.
Now for the attempt to port pv to ARM. I have prepared the branch I
announced yesterday, and you can try if it compiles on your Raspi:
git checkout native
make
This will try to build three targets: pv_scalar, pv_vspsimd and
pv_vcsimd - you can also build them separately if you like, it's a
phony
'all' target compiling the lot. The first one makes no attempt at using
SIMD code, the second one used vspline's 'implicit' SIMD code, and
the arry
third uses Vc. I think the first two will build on the Raspi, the third
may or may not.
While typing this mail, I compiled your new code on my RPi4 server. All
3 versions compile fine, but as they use (Open)GL code, they won't run
in a VNC window and I didn't setup X on my server.
I will do the same on my other RPi4 with a monitor connected, but I
don't have time for it now.
Now, that makes me happy :D
ARM isn't merely a different platform, but a different architecture
altogether, and to get a build first go is just great! I am so glad
about clang++. It sure makes my code a lot faster than g++ - I suppose
it handles the functional paradigm better, and even if I type-erase my
functors it can still compose them into the fastest configuration
possible. And it's there on many platforms and architectures and just
compiles the same code everywhere, as far as I have seen it. So, my
gratitude goes to the makers of clang++, and also to the giants on whose
shoulders I'm standing, namely Ullrich Köthe, the original author of
vigra, whose thesis finally convinced me of generic programming, and
Matthias Kretz, the author of Vc, whose thesis made me realize that
there is more to SIMD than simply using a few intrinsics and that SIMD
programming is a state of mind - and that's mentioning just the two who
I have to thank most.
Thank you for trying the ARM build, and let's hope that the binary
actually *works*... Hope to hear about that soon-ish.
I couldn't have done it without openGL, either. SFML provides access to
openGL functionality with very little fuss, and it's cross-platform as
well, so I can leave all the nitty-gritty to it. Great software. Highly
recommended.
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/10a52e4b-8036-3833-507c-67656db6b8c6%40yahoo.com.
