Am 13.03.21 um 13:58 schrieb Harry van der Wolf:
I use a likewise script but then using align_image_stack from the hugin
tools (and optimised the pv command with your command. Thanks).
I replace the lines
pto_gen -p0 -o bracket.pto "$@"
pano_modify -p0 --fov=AUTO --canvas=AUTO -obracket.pto bracket.pto
cpfind --sieve2size=5 -o bracket.pto bracket.pto
autooptimiser -p -o bracket.pto bracket.pto
pano_modify -p0 --fov=AUTO --canvas=AUTO -obracket.pto bracket.pto
(Note: I changed "pano_modify -p0 --fov=AUTO --canvas=AUTO -obracket.pto
bracket.pto" to "pano_modify -p0 --fov=AUTO --canvas=AUTO -o bracket.pto
bracket.pto" in the script.)
with one line:
align_image_stack --gpu -p bracket.pto -v "$@"
This should come out just the same. Using your way would have been more
instructive in my example - I should have thought of that. I just copied
the script I had used to batch-process my brackets from last summer.
when using "time pv_fuse.sh" or "time ais_pv_fuse.sh" (my
align_image_stack version), it is twice as fast and with my
preliminary??tests I do not find differences.
Next to that: I use the same script??with enfuse, meaning
align_image_stack followed by enfuse. Enfuse is currently faster than pv
and does not entirely lock my laptop like pv does. However, the "big
wait" is in the panotools. I don't care about the speed difference
between pv and enfuse.
You can throttle pv by passing --snapshot_threads=...
The default is to use as many threads as there are cores on the machine.
If you want a well-behaved background job and the time it takes is not
an issue, pass 1.
Note also the max amount of memory used by pv versus
align_image_stack/enfuse where ais takes the 0.98GB and enfuse approx.
500MB. All runs using the same five 9.1 megapixel bracketed images and
all creating a jpg instead of an (open)exr image.
One reason why pv uses a lot of memory is because it builds a b-spline
interpolator for *magnifying* views. If your job requires only 1:1 or
less, try passing --build_pyramids=no, which should reduce the memory
footprint and be faster as well. If you want to reduce memory even
further and your job is 1:1 (like here), you can even add
--build_raw_pyramids=no.
And you can also try and omit the separate 'quality' interpolator by
passing ---quality_interpolator_degree=1 - the default of three is to
give you nice magnifications for still images up to single pixels blown
up to screen size :D
But I do admit pv is memory-hungry. There has to be a lot of stuff ready
to use for smooth animations - pan and zoom without stutter and the
likes. pv is - at heart - a viewer, and the stitching and fusing
capabilites are for now just nice-to-have additions.
The next point to consider is mathematics: if I remember correctly,
enfuse uses a highly optimized integer-math implementation of the B&A
image splining algorithm - and it may even offload work to the GPU,
which would explain why it blocks up your system less - pv is CPU only,
and does all calculations in single-precision float, and with pyramid
levels based on cubic b-splines. That's a lot of CPU load, with the SIMD
units running on all threads you put to use.
Some figures:
pv_fuse (using the pano tools and pv)
real 2m16,020s
user 6m3,251s
sys 0m17,520s
3.7GB
ais_pv_fuse.sh (using align_image_stack and pv)
real 1m22,573s
user 4m2,008s
sys 0m16,343s
3.7GB
enfuse.sh (using align_image_stack and enfuse)
real 0m53,653s
user 1m20,007s
sys 0m4,532s
0.98GB
So, for now, pv won't get much faster, but try again with the
memory-savers I proposed above to see if you can squash memory use
significantly. And also keep in mind that I haven't spent a lot of time
tweaking the fusion code - I have it working all right, but especially
the version processing images with alpha channel still has room for
improvement, and I should be able to squash memory use further.
Both pv and enfuse use all 4 cores in my laptop where pv, for whatever
reason, almost completely blocks my laptop.
Try throttling, as explained above.
I will do further tests.
Thanks for your continued interest!
What I'd also like to see is a close look at image quality. I put all
efficiency considerations aside and went for the best image quality I
could produce. And my new alpha-blending code should also produce very
nice results when it comes to manual deghosting - I don't look at the
masks in the PTO yet, but you should now be able to simply feed images
with unwanted content 'erased' to transparency (should even be best with
a feathered brush on the erase tool), and as long as the other images
provide content, the 'ghosts' should become invisible, thanks to the B&A
magic.
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/68569c2c-bbba-bae1-31c0-b28572db2ac2%40yahoo.com.
