Op wo 3 mrt. 2021 om 10:32 schreef 'Kay F. Jahnke' via hugin and other free panoramic software <[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 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. 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. > 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. > > Sorry to make you sad. ;) You have some very good arguments (at least in my eyes). 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. > 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. Harry -- 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/CAGARPpsXyKha3V%2BzZ0%2BBvE_cmjuq82urgOG4nUUT9%2Bvo1w2S1g%40mail.gmail.com.
