Am 02.03.21 um 13:53 schrieb Harry van der Wolf:
Op di 2 mrt. 2021 om 11:43 schreef 'Kay F. Jahnke' via hugin and other
Since you're the one who's building hugin on the mac, maybe you can
give
me a hint on how to write a 'port file' to provide a pv package for
macports? Is that hard? And is it hard to provide a package which users
can simply download from the app store? I proposed to bundle pv with
hugin, because it would make a good addition to the suite, what do
you say?
Kay
I was not correct, or at least not clear enough, in my answer. I did
take over from Ippei Ukai, but also mentioned I abandoned Mac in
2012/2013 or so. I simply never threw my 2008 macbook away.
At that time I also maintained the macports build of hugin and
enblend/enfuse, but that is now also long, long ago. But I will have a
look at it.
Sorry, I did not read your mail properly. I can sympathize with leaving
the mac universe. I've been a linux early adopter as well - working on
unix networks in the nineties changed my views as to what an OS should
be like and I started out with Xenix, then slackware Linux on my home
PC. Later on I used Windows for some time, with CygWin to have a POSIX
environment. Then it was back to Linux again, happy as you are. I keep a
W10 install on one of my Thinkpads to run windows builds of pv, so that
I can distribute Windows binaries to people who don't want to build
themselves.
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.
I certainly do not have an Apple M1 and will not buy one either. I am a
happy Linux user since 1993 (early adapter) and simply wandered off for
a couple of years, both to Apple and Windows.
I must admit that the M1 is very attractive, though. It might be
worthwhile to just buy a small machine with this chip - I'd like a
macbook air, because I don't have an up-to-date laptop - my newest
thinkpad is eight years old or so.
Making a package for the MacOS app store is a different thing.
You have to register as a developer at Apple. I did a complete rant some
days ago about how I hate how Apple does things, but also realised at
that time that I had registered around 2008, when I took over from
Ippei. And yes, that still worked.
I wouldn't want to do that if I can help it - that's why I was hoping to
piggyback on the hugin suite. I still think it would make a nice
addition. Where is the good cross-platform FOSS panorama viewer in the
hugin package? I was frustrated because I could not find one, so I wrote
one. I hear others use 'Panini' but I never managed to get it to work
for me. So here's pv.
- So, you have to register at Apple as a developer giving quite some info.
- You have to offer your bundle to Apple where Apple checks for
malware/Apple standards/"other things". That is actually a good thing,
but will take time and sometimes your bundle is rejected while you know
it is perfectly fine. I have a java app which I also packaged as a MacOS
bundle. Apart from the fact that I won't release it via the apple store,
it will not be accepted either as it is built outside Xcode thereby
lacking some controls/standards (and Apple spyware?).
I wouldn't be surprised...
With regard to bundling with Hugin:
I agree with Thomas that where possible we should integrate. You already
explained the big differences in code, so that might not be possible. I
can't judge that as I'm not a C/C++ programmer.
It is in fact completely new technology. Potentially disruptive. It's
probably not too hard to extract the blending and fusing code into a
separate program, but the beauty of pv is in the total integration of
all components - you simply load your PTO file into pv like any other
image, adjust the view until you have what you want, and press 'P' to
have a panorama rendered in the background. No intermediate images on
disk, no helper programs. Once the stitch is rendered, you can simply
open pv's file select dialog (press 'F') and load the freshly-made
panorama in the same session. Same goes for exposure fusions or HDR merges.
As it is all open source, it might still be possible to
migrate/integrate it. And otherwise: could it be possible to call pv
from hugin to run it as enblend replacement. Just like multiblend can
be called from hugin (with a simpler command set) as enblend replacement?
Also: panomatic was first an external tool and most of it is now
integrated in cpfind.
I hope we see the same for pv blending/fusing functionality if it really
is an improvement.
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. Think of pv as a 'preview on
steroids'. There was a discussion in this group whether it wouldn't make
sense to work more from the preview window. pv is my answer to this
discussion: its what used to be called 'wysiwig'. Pretty much everything
happens immediately, you see all parameter changes 'live'. The only
things which I can't show 'live' are exposure fusions and stitches,
because the B&A algorithm takes a lot of time. I may be able to tweak it
so that I can produce a few frames per second showing stitches and
fusions live, but for now they are rendered by a background thread to a
file on disk. For playing with my stitching and fusion code, this should
be good enough for now.
I even made it easy to use it as a preview for hugin and the likes: if
you work on a panorama in hugin, you can just have a pv window open to
the same PTO. as soon as you save the PTO in hugin, you can simply press
'F1' in pv and it will update to the changes in the PTO. I see pv rather
as a third 'preview' window which hugin etc. can use alongside the other
two, which are good for some tasks where my code is not - I don't handle
all panotools projections, I don't deal with control points, I can't
switch individual imageson and off... - but I sure can give a good view
at the PTO.
My personal point of view is to help where I can if "something" can mean
an improvement for all of us. And if it is mature try to integrate it.
If my code turns out to be good, I'd be happy to see it used by others.
I just don't want to go fiddling with other people's software to force
my new stuff in. Integration into extant software is better done by the
original authors, who know their way around their code. As far as pv and
it's new components are concerned, I want to stay upstream and focus on
innovation.
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
third uses Vc. I think the first two will build on the Raspi, the third
may or may not. If any of the targets build, you should have a
functional pv variant to run on the same machine which it was built on
(it uses --march=native). If the target using Vc builds, it should be
the fastest. Please try it out and let me know how it went!
When I build the 'native' branch targets on my desktop machine, the
performance difference is quite noticeable. My standard test is a
1000-frame automatic pan over a full spherical panorama. The per-frame
rendering times I get are roughly like this:
- pv_vcsimd: 7.1 msec
- pv_vspsimd: 12.4 msec
- pv_scalar: 15.5 msec
So the Vc version is more than twice as fast as the scalar one, and the
'implicit SIMD' version comes out in the middle.
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/35b2bd51-2929-1e39-5729-30734a8fb3b7%40yahoo.com.
