On 23.04.24 22:21, Maarten Verberne wrote:
I did a small test, my first impression is that it's quicker.
If your panoramas are not very large and you have enough memory, using
lux should be faster, because it can keep everything in memory and does
not need temporary files. It's also fully multithreaded and exploits the
SIMD units of modern CPUs. The nona/enblend toolchain can use the GPU,
though, which may be faster for some of the processing.
in the pto states that jpg compression should be 100% (no compression)
lux does not look at these settings in the PTO. It only looks at a few
data in the PTO and ignores the rest. The default compression rate for
JPEGs in lux is 90%, if you want a different compression, you must tell
lux on the command line, e.g. with --snapshot_compression=100 if you
want 100%. Here's a quote from the lux documentation:
please be aware of the fact that lux only processes a subset of
PTO format:
- orientation (yaw, pitch, roll only, *not* translation)
- horizontal field of view
- exposure value
- projection (only those projections known to lux, and not 'mosaic')
- lens correction parameters
- vignetting control parameters
- source image cropping
- source image masks
- stacks (in animated sequences, only the 'stack parent' is displayed)
but the resulting jpg files are a factor 4 smaller in size than with my
nona/enblend combo and actually have a filesize close to a single
original jpg image of the 2.
this might be due to the fact that nona first generates very large tiff
files, but i'm not sure if there might be something else.
Try with 100% compression and see if the difference is still large. lux
and nona/enblend use completely different processing, lux does not use
panotools. When you have the 100% output from lux, look at it critically
(e.g. is the resolution and sharpness good enough for you, are the
colours okay, is the blending correct) - don't expect a drop-in
replacement. lux may be better or worse for a given image set, and
output from lux can be quite different from what you get from the
panotools tool chain, e.g. due to the fact that lux does not use seam
optimization but stitches with seams derived from a data model
resembling a spherical voronoi digram.
i still need to do a full test to see how they actually look and the
script runs, but like i wrote, that's for this weekend
Good luck!
--
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/fd0498ac-b579-4d83-a70b-535218af2465%40yahoo.com.
