On 24.04.24 18:19, mpgve... wrote:
had some time and did some testing comparing enblend/nona vs lux.
these results are from the same system with the same set of images,
....results on your system are different ;)
image quality was good, sometimes a bit better, sometimes a bit less,
depending on lighting conditions that make the need for blending important.
Nice to hear you're happy with the image quality! I suppose the size
issue has sorted itself out with specifying the compression?
i didn't like that lux out of the box worked with a preview full screen,
it made it impossible to use the system (without a 2nd monitor) while it
was running.
try this:
lux --fullscreen=no --window_width=320 --window_height=200 --stitch=yes
*.pto
then you'll only get a small window displaying the current PTO in the
headline and showing a view to the currently stitched PTO which does not
take much CPU time. You can even pass -n to show nothing but the lux
logo. I'd like to figure out a way to run without a visible window, but
with lux being a viewer, a lot depends on the window and it's hard to do
without it.
while i run nona -g(pu) this only has an speed advantage if i start more
than one script, i gives the system time to sync those operations and
creates more headroom on the cpu for that 3rd script running.
Looks like lux is coming out quite well. I see that the call to exiftool
eats up a lot of time. This comes as no surprise, because AFAICT
exiftool doesn't simply modify the metadata in the image but makes a copy.
i set one instance Nona -g/Enblend/Exif at 100, the other values are
related to that.
Lux/Exif is just a bit faster than 2 instances of Nona -g/Enblend/Exif
running the same set.
When part of the work can be delegated to the GPU, that's usually the
fastest way to go. lux is completely CPU-based. If you want to push your
system to the limit, it may even be possible to have lux and
nona/enblend run in parallel: lux will push the CPU to the limit, and
nona/enblend can access the GPU where they can. You can tell lux to use
only a specific number of threads for rendering, so if you have four
cores, you could use --snapshot_threads=3 to leave one core free to
handle the CPU load of the other processes and have lux render with
three threads.
Thanks for sharing your insights! Depending on the precise nature of
your stitches, you may be able to slash processing time with lux. What
you get is the defaults, but lux is very configurable.
--
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/1f440708-bee2-4f3b-ae63-0bd53a190c4a%40yahoo.com.
