Dear group! A few weeks ago, a friend of mine managed a pv build on an intel mac using macports. He sent me a build log, and I have included the instructions in my bitbucket repo. So now pv can run on Linux, MS Windows and MacOS. The mac build is simple, it comes down to this:
- sudo port install vigra -python38 - sudo port install sfml - sudo port install exiv2 - git clone https://bitbucket.org/kfj/pv - cd pv - git checkout mac - make Mac users, please give it a shot, and report what you think! Since pv has matured nicely and all major platforms are now supported, how about including it in the hugin or hugin-tools package? This would give hugin users immediate access to a panorama viewer which is the same across all platforms. I'd also welcome packagers to produce standalone pv installers/installable packages. Where MS Windows is concerned, pv depends on MinGW/msys2, which is probably not very common, so I could provide an msys2-built binary and the necessary DLLs, if someone would want to build a windows installer but does not have an MinGW/msys2 environment. Kay kfj schrieb am Mittwoch, 8. April 2020 um 11:32:01 UTC+2: > On 06.04.20 15:56, Carlos Eduardo G. Carvalho (Cartola) wrote: > > > > - Its performance is a little bit worse than Panini, which I usually > > use. The image flow is slower (my machine is an i7 from 2013 without an > > Nvidia) > > Three more things concerning performance: > > - per default, pv uses bilinear interpolation for moving images. If you > want to squash animation rendering times even further and do not mind > aliasing, you can use nearest neighbour interpolation for moving images > instead: > > --fast_interpolator_degree=0 > > - per default, pv does it's internal calculations in linear RGB and > converts the result to sRGB before sending it to the GPU. This is > mathematically correct, but takes time. You can switch to processing in > sRGB, which is okay for simply viewing images, with this option: > > --process_linear=false > > - also per default, pv checks if the input image has an alpha channel. > If so, it tests if any pixels at all have transparency. If so, alpha > processing is switched on. Even if there is only a single pixel with an > alpha value of 254, this will trigger alpha processing, which also takes > time. You can force alpha processing off: > > --alpha=no > > I was surprised to find that some of my panoramas done with hugin had > pixels with transparency, even though I had used automatic cropping. > Seems the automatics don't exclude all pixels with a little transparency > (espacially in the corners). So keep this in mind. > > Performance comparisons are a dicey issue, a lot of stuff may go on > behind the scenes, and you may end up comparing apples and pears. > > I'd be surprised to see CPU-based rendering code which is significantly > faster than pv, as long as the mathematical operations are the same. > It's very highly optimized. > > 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/f2251959-7f8b-43e0-936d-a1182422e47fn%40googlegroups.com.
