I use hugin for producing panoramic photos and thought I could use lux as a
quick way to make jpgs using the hugin-produced .PTOs and original (sub)images.
For 2D output rectilinear quickly becomes unwieldy as the size increases, and
for architecural images spherical is really not a good choice.
I see, so it's about stitching a PTO file and producing an image which
'looks nice' as a whole, rather than being good to view with a panorama
viewer. For that purpose, using hugin/enblend is probably the better
choice, but the process (create remapped partials first, then stitch
them) is indeed a bit circuitous, compared to lux' integrated process.
When I look at the way how lux handles a PTO file specifying an
unhandled projection (like Panini) in the p-line, I admit it's
'ungraceful' - the p-line is only relevant for stitching, lux could
display the PTO in any of the target projections it can handle, and a
failure would only be necessary if the user actually requested stitching
to the p-line, like when pressing 'Shift+E' or using --stitch=yes. I'll
keep that in mind for the next version. Thank you for your input, sorry
I can't be more helpful right now.
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/f710128b-8b23-a8d1-21fe-59fcfaa5560c%40yahoo.com.
