lux 1.2.0 released

[kfj]

Dear all!

I've finally released a new lux version, after a lot of work on the program. Linux users already had 'tasters' of what's now in version 1.2.0, there are two big changes:

- I wrote a new GUI using Dear ImGui

- I am now using OpenImageIO for image input

The new GUI should make it much easier to handle the large amount of options and settings, and pretty much everything can now be done graphically, rather than having to resort to command line options. The new GUI also has plenty of tool tips, so one can approach the functionality without having to switch between the program and the documentation all the time. I hope this helps to make the program more attractive. The mouse and keyboard commands are unchanged.

Using OpenImageIO for image input pulls in a lot of other libraries via plugins and linkage, so the number of dependencies has grown dramatically, but I think it's worth it. lux can now open a large variety of image files, including camera RAWs (using libraw, which is similar to dcraw) and videos as sequences of single images (using ffmpeg). Some of the image formats which can now be visualized are quite new (e.g. HEIF/HEIC ), and they were one of the reasons why I switched to OIIO - the newer formats weren't supported by libvigraimpex.

Under the hood there's the same fast rendering engine using multithreaded SIMD code, the only change is that automatic rendering quality for animations is now on by default. And, needless to say, there were many small bug fixes and tweaks, hopefully all for the better!

There are binaries available for Linux (in AppImage format) Windows (portable and installable version) and for intel-based macs - a version for mac silicon will hopefully materialize soon, until then, mac silicon users can run the intel code with Rosetta, which works quite well. Enjoy!

[David W. Jones]

Thanks, always good to have an improved GUI.

I ran the appimage from the command line, it gave me a window to open files. I went to open a PTO file, and got a blank black screen. Nothing happened. Nothing displayed. When I pressed Escape, the window blank display went away and I saw this in the command line window:

OpenImageIO exited with a pending error message that was never
retrieved via OIIO::geterror(). This was the error message:
OpenImageIO could not find a format reader for "/home/david/data/MyPhotos/Rabbit Island Vertical Pano/RabbitIslandVerticalPano-2013092220130922.pto". Is it a file format that OpenImageIO doesn't know about?

So the new Lux can't open PTO files anymore?

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/9e7eb818-5e7e-41bf-8d31-dd25ccd36f74n%40googlegroups.com.

-- 
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com
My password is the last 8 digits of π.

[kfj]

On Sunday, April 21, 2024 at 9:26:56 PM UTC+2 GnomeNomad wrote:

Thanks, always good to have an improved GUI.

I ran the appimage from the command line, it gave me a window to open files. I went to open a PTO file, and got a blank black screen. Nothing happened. Nothing displayed. When I pressed Escape, the window blank display went away and I saw this in the command line window:

OpenImageIO exited with a pending error message that was never
retrieved via OIIO::geterror(). This was the error message:
OpenImageIO could not find a format reader for "/home/david/data/MyPhotos/Rabbit Island Vertical Pano/RabbitIslandVerticalPano-2013092220130922.pto". Is it a file format that OpenImageIO doesn't know about?

So the new Lux can't open PTO files anymore?

It should. The error message you get is nothing to worry about - I pass every file to OIIO first to see if it can open it, and when it fails it saves this error message which is never retrieved and displayed at program exit. Maybe I should clean up better before terminating lux - this is misleading behaviour. Thanks for pointing it out!

Considering the failure to open your PTO, I wonder: do the images have an alpha channel? I checked the PTO display, and I saw there is an issue with panoramas with images with alpha channel. Most embarrassing - looks like I have a bug to fix. Did you try other PTOs? Maybe you can post the PTO file, then I can see if I can reproduce your problem. This would help me fix the bug.

[David W. Jones]

On 4/21/24 19:29, 'kfj' via hugin and other free panoramic software wrote:

On Sunday, April 21, 2024 at 9:26:56 PM UTC+2 GnomeNomad wrote:

Thanks, always good to have an improved GUI.

I ran the appimage from the command line, it gave me a window to open files. I went to open a PTO file, and got a blank black screen. Nothing happened. Nothing displayed. When I pressed Escape, the window blank display went away and I saw this in the command line window:

OpenImageIO exited with a pending error message that was never
retrieved via OIIO::geterror(). This was the error message:
OpenImageIO could not find a format reader for "/home/david/data/MyPhotos/Rabbit Island Vertical Pano/RabbitIslandVerticalPano-2013092220130922.pto". Is it a file format that OpenImageIO doesn't know about?

So the new Lux can't open PTO files anymore?

It should. The error message you get is nothing to worry about - I pass every file to OIIO first to see if it can open it, and when it fails it saves this error message which is never retrieved and displayed at program exit. Maybe I should clean up better before terminating lux - this is misleading behaviour. Thanks for pointing it out!

Thanks.

Considering the failure to open your PTO, I wonder: do the images have an alpha channel?

No, the source images are JPGs and don't support transparency/alpha channel.

I checked the PTO display, and I saw there is an issue with panoramas with images with alpha channel. Most embarrassing - looks like I have a bug to fix. Did you try other PTOs?

I checked a version of the PTO that uses the same images. That rendered fine. It was created in 2021 using Hugin.

The problematic PTO file was created in 2013 using Hugin. Hugin doesn't complain about either of them.

Maybe you can post the PTO file, then I can see if I can reproduce your problem. This would help me fix the bug.

Attaching the old problematic one (RabbitIslandVerticalPano-2013092220130922.pto) and the newer non-problematic one (P1000364-P1000361.pto).

I don't know if the list will let them through.

[kfj]

Thanks for posting the PTO. I also got a black screen from it. The problem is that the visible content is outside of the viewing area. If you zoom out a good bit or start lux with --hfov_view=90, you'll see the images (which have quite small hfov of 14 degrees) near the top of the view. The pitch values in your PTO are larger than the hfov (17.4024521555217), and so the visible content is placed in an area which is not inside the viewing area.

I can see how this is confusing - maybe I should add code to center the view to a point somewhere inside the collection of images to avoid showing a blank screen.

Thanks for reporting back!

[David W. Jones]

Ah, thanks. I tried dragging around in the blank window but couldn't remember how to zoom in/out. Centering the viewing area sounds like a good idea.

It  might be a bug in whatever version of Hugin I was using in 2013. I have another PTO that I had made with the same version, and got panoramas with mismatched items (like velvet ropes that crossed multiple images), produced using the Auto Alignment feature. Later versions of Hugin with the same function had no such disjoints.

Cool. Lux is fast. I'd still prefer a Debian Linux native version to the AppImage, and movement within the image that isn't counterintuitive for me, but it's getting better.

--

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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/a024055c-93f5-4c82-b949-f58f3e6789fen%40googlegroups.com.

[Maarten Verberne]

thanks kfj, a better GUI is always great.
what david wrote about pto not working is only with specific image
formats? I'm guessing with JPG the template.pto file still works?


Although Thomas once showed me how i could do my stitching via the GUI,
that method appeared a lot slower and more complicated for me. so after
that test i forgot how to do that and went back to my cmd files.

however, i never solved and am thus missing the exif data mapped to the
output image in my CMD script and for that reason alone i would accept
the extra time the gui costs...if i can run multiple instances of the
gui simultanious.


If that's possible, what would be the best step-by-step method for me to
try stitching thousands of sets of pictures?
if somebody can help me out with that i would love to try Hugin 1.2 new gui.


the way i work now has little input from me after creating the folder
and file set and can keep my pc busy for weeks, depending on how many
days are processed without a windows update that i forgot to block ;)

my setup consists (WIN7/10/11) of sets of dated folders (left and
right), with jpg images numbered from 1 onwards.
On another disk I create a list of dated folders with each a CMD file
and a PTO file.

the CMD file is simple, it checks if the images exists and with
nona/enblend it stitches them together with use of the pto file, ups the
file number with one and tries again.

i also have another script that starts one after another CMD file in the
dated folders...just because i was fed up with starting each day
seperately.

The real great part of the cmd files is that i can run up to 3
simultanious cmd scripts within my processors 8 core capacity, making it
almost 3 times as speedy that one gui running one folder set.

so for me, after setting up i only need to double click once per cmd
instance and leave my pc alone.


how would i go about 'automatically' stitching all files in the folders.
possibly switching to the next folder set when it runs out of images.
possibly running more than one gui instance/more than one folder set at
once?
who ever thought of that :)

Maarten




Op 21-Apr-24 om 21:26 schreef David W. Jones:

>> There are binaries available <https://bitbucket.org/kfj/pv/downloads>

>> for Linux (in AppImage format) Windows (portable and installable
>> version) and for intel-based macs - a version for mac silicon will
>> hopefully materialize soon, until then, mac silicon users can run the
>> intel code with Rosetta, which works quite well. Enjoy!
>> --
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/hugin-ptx/9e7eb818-5e7e-41bf-8d31-dd25ccd36f74n%40googlegroups.com <https://groups.google.com/d/msgid/hugin-ptx/9e7eb818-5e7e-41bf-8d31-dd25ccd36f74n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
>
> --
> David W. Jones
> gnome...@gmail.com
> wandering the landscape of god
> http://dancingtreefrog.com
> My password is the last 8 digits of π.
>

> --
> A list of frequently asked questions is available at:

> http://wiki.panotools.org/Hugin_FAQ <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+...@googlegroups.com

> <mailto:hugin-ptx+...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/hugin-ptx/282e761b-243b-43a0-bbb3-cdc9c0ffed3a%40gmail.com <https://groups.google.com/d/msgid/hugin-ptx/282e761b-243b-43a0-bbb3-cdc9c0ffed3a%40gmail.com?utm_medium=email&utm_source=footer>.

[kfj]

On Monday, April 22, 2024 at 10:21:07 AM UTC+2 GnomeNomad wrote:

Ah, thanks. I tried dragging around in the blank window but couldn't remember how to zoom in/out. Centering the viewing area sounds like a good idea.

It  might be a bug in whatever version of Hugin I was using in 2013. I have another PTO that I had made with the same version, and got panoramas with mismatched items (like velvet ropes that crossed multiple images), produced using the Auto Alignment feature. Later versions of Hugin with the same function had no such disjoints.

Cool. Lux is fast. I'd still prefer a Debian Linux native version to the AppImage, and movement within the image that isn't counterintuitive for me, but it's getting better.

 

I'll make a debian package on my debian11 install when I get round to it - I'm developing on debian testing, and I'll first hunt down the bug I found with panoramas with images with an alpha channel.

If the only thing which confuses you is the direction in which the view moves when you drag the mouse, you can change that in the 'General Settings': quite near the top there are checkboxes to reverse the primary-button-click-drag direction and the secondary-button-click-drag direction - then commit at the bottom of the panel. If you prefer it that way and want to change the direction permanently, put lines like "reverse_drag=yes" or "reverse_secondary_drag=yes" in your .lux.ini file (in your home folder).

[kfj]

On Monday, April 22, 2024 at 10:29:55 AM UTC+2 mpgve...@gmail.com wrote:

thanks kfj, a better GUI is always great.

You're welcome!

what david wrote about pto not working is only with specific image
formats? I'm guessing with JPG the template.pto file still works?

We've figured it out, the images were outside the viewing area.

the CMD file is simple, it checks if the images exists and with
nona/enblend it stitches them together with use of the pto file, ups the
file number with one and tries again.

batch stitching with lux is quite simple. All lux needs to stitch a PTO is a command line like this:

lux --stitch=yes my.pto

and to stitch several, just pass them all on the command line:

lux --stitch=yes *.pto

The resulting files are named automatically and no metadata are transferred, if you want that, you'll have to employ exiftool.

The real great part of the cmd files is that i can run up to 3

simultaneous cmd scripts within my processors 8 core capacity, making it

almost 3 times as speedy that one gui running one folder set.

With lux, you don't have to do this, because lux multithreads internally, so when it does a stitch, it uses all available CPU cores anyway. You can't gain speed from running several instances.

so for me, after setting up i only need to double click once per cmd
instance and leave my pc alone.

Should be the same with lux batch stitching, but you should rather set up a script which does the batch stitch in one folder, then moves to the next and does it there, etc - running them in parallel won't speed it up and use much more memory. Try it out and tell me how it worked for you. Of course the results lux produces are not identical to what nona+enblend produce and you may not be happy with the result. And lux needs lots of memory - if the panoramas are large, it may not be a good idea to stitch them with lux.

[Maarten Verberne]

> batch stitching with lux is quite simple. All lux needs to stitch a PTO
> is a command line like this:
> lux --stitch=yes my.pto
> and to stitch several, just pass them all on the command line:
> lux --stitch=yes *.pto
> The resulting files are named automatically and no metadata are
> transferred, if you want that, you'll have to employ exiftool.

the command line is like this, with use of gpu for nona:

set nona="%ProgramFiles%\Hugin\bin\nona.exe"
set enblend="%ProgramFiles%\Hugin\bin\enblend.exe"

%nona% -g -o out -m TIFF_m template.pto
%Rfolder%/%date%/IMG_%imagenr%.JPG %Lfolder%/%date%/IMG_%imagenr%.JPG
echo Done Nona
%enblend% -o %outputname%-IMG_%imagenr%.JPG --compression %jq%
out0000.tif out0001.tif
echo Done Enblend, next file?

and lux replaces both nona and enblend?
something like?

set lux="%ProgramFiles%\Hugin\bin\lux.exe"

%lux% -g --stitch=yes %Rfolder%/%date%/IMG_%imagenr%.JPG
%Lfolder%/%date%/IMG_%imagenr%.JPG template.pto -o
%outputname%-IMG_%imagenr%.JPG


I know it's in hugin, but never understood how to employ exiftool via
cmd and f.i. copy the left image exif data to the enblend output file.

> With lux, you don't have to do this, because lux multithreads
> internally, so when it does a stitch, it uses all available CPU cores
> anyway. You can't gain speed from running several instances.

ah, you really think? as far as i can tell it already uses multicore in
the current setup, but since loading and writing takes time and even
when processing only one or 2 cores go above 60%, there was in my
opinion time enough to try to run more scripts.

> Should be the same with lux batch stitching, but you should rather set
> up a script which does the batch stitch in one folder, then moves to the
> next and does it there, etc - running them in parallel won't speed it up
> and use much more memory. Try it out and tell me how it worked for you.
> Of course the results lux produces are not identical to what
> nona+enblend produce and you may not be happy with the result. And lux
> needs lots of memory - if the panoramas are large, it may not be a good
> idea to stitch them with lux.

i don't have any memory issues (yet), and i feel in a daring mood :)
I will try single and multi instances out and let you know, this might
take some time though....

[Kay F. Jahnke]

On 22.04.24 11:21, Maarten Verberne wrote:
>
> the command line is like this, with use of gpu for nona:
>
> set nona="%ProgramFiles%\Hugin\bin\nona.exe"
> set enblend="%ProgramFiles%\Hugin\bin\enblend.exe"
>
>     %nona% -g -o out -m TIFF_m template.pto
> %Rfolder%/%date%/IMG_%imagenr%.JPG %Lfolder%/%date%/IMG_%imagenr%.JPG
>     echo Done Nona
>     %enblend% -o %outputname%-IMG_%imagenr%.JPG --compression %jq%
> out0000.tif out0001.tif
>     echo Done Enblend, next file?

For lux, you need a PTO file as input if you want to stitch. I don't now
about the templates and things you're using.

> and lux replaces both nona and enblend?
> something like?
>
> set lux="%ProgramFiles%\Hugin\bin\lux.exe"
>
> %lux% -g --stitch=yes %Rfolder%/%date%/IMG_%imagenr%.JPG
> %Lfolder%/%date%/IMG_%imagenr%.JPG template.pto -o
> %outputname%-IMG_%imagenr%.JPG

So, first you have to make the PTO - there are panotools scripting
programs to make one from a set of images - and then you feed the PTO to
lux. But it does replace the 'warping' with nona and the merging with
enblend.

> I know it's in hugin, but never understood how to employ exiftool via
> cmd and f.i. copy the left image exif data to the enblend output file.

You'll have to refer to exiftool decumantation for that.

> i don't have any memory issues (yet), and i feel in a daring mood :)
> I will try single and multi instances out and let you know, this might
> take some time though....

Just make a single PTO first, see how it stitches with lux, and if you
get the knack of it, you can try several in one go. Good luck!

[David W. Jones]

On 4/21/24 22:33, 'kfj' via hugin and other free panoramic software wrote:

On Monday, April 22, 2024 at 10:21:07 AM UTC+2 GnomeNomad wrote:

Ah, thanks. I tried dragging around in the blank window but couldn't remember how to zoom in/out. Centering the viewing area sounds like a good idea.

It  might be a bug in whatever version of Hugin I was using in 2013. I have another PTO that I had made with the same version, and got panoramas with mismatched items (like velvet ropes that crossed multiple images), produced using the Auto Alignment feature. Later versions of Hugin with the same function had no such disjoints.

Cool. Lux is fast. I'd still prefer a Debian Linux native version to the AppImage, and movement within the image that isn't counterintuitive for me, but it's getting better.

 

I'll make a debian package on my debian11 install when I get round to it - I'm developing on debian testing, and I'll first hunt down the bug I found with panoramas with images with an alpha channel.

I'm on Debian Bookworm (12).

If the only thing which confuses you is the direction in which the view moves when you drag the mouse, you can change that in the 'General Settings': quite near the top there are checkboxes to reverse the primary-button-click-drag direction and the secondary-button-click-drag direction - then commit at the bottom of the panel. If you prefer it that way and want to change the direction permanently, put lines like "reverse_drag=yes" or "reverse_secondary_drag=yes" in your .lux.ini file (in your home folder).

Hmm, didn't readily see any place to set that in the GUI. But thanks for the info.

[Maarten Verberne]

>
> For lux, you need a PTO file as input if you want to stitch. I don't now
> about the templates and things you're using.

so instead of one pto per folder, so it can get the warping settings
identical over all files, i need one pto per image file set?

> So, first you have to make the PTO - there are panotools scripting
> programs to make one from a set of images - and then you feed the PTO to
> lux. But it does replace the 'warping' with nona and the merging with
> enblend.
>

all those similar pto files just for the imagenumber does sound a bit
excessive.
but hey, if that's the way.

>
> You'll have to refer to exiftool decumantation for that.

I did, but i wasn't clever enough to make it work. let's leave it there ;)

> Just make a single PTO first, see how it stitches with lux, and if you
> get the knack of it, you can try several in one go. Good luck!
>

i've just downloaded lux 1.2, but one imageset is no test for me, so i'm
going ahead with making a bunch of pto files.
only than can i compare different light conditions throughout the day
and see how it runs as i would use it.

[Kay F. Jahnke]

On 22.04.24 12:29, Maarten Verberne wrote:

> all those similar pto files just for the imagenumber does sound a bit
> excessive.
> but hey, if that's the way.

There's nothing stopping you from modifying the PTO files as text files
with any old text processing tool. But lux needs a PTO file which does
not contain any placeholders or such.

I'll take your post as an inspiration, though, and think about ways how
to make templating possible with lux. I already have some (undocumented)
code which I think could be bent to the task - I'll post again if I can
figure something out. It will probably need additional command line
parameters or a .lux file wrapping the .pto

>> You'll have to refer to exiftool decumantation for that.
>
> I did, but i wasn't clever enough to make it work. let's leave it there ;)

Yes, exiftool is quite a mouthful. This is another thing on my list -
I'd like to have settings in lux which pick a given set of attributes
from the source file(s) and move them to the target. I already handle
EXIF metadata (you can have a selection displayed in the status line),
but so far the only metadata I write to the output are the ones
describing the geometry and cropping of the image. In my scripting, I
use something like this to propagate the metadata:

exiftool -overwrite_original \
-tagsFromFile "$SOURCE" \
-All:All \
'-DateTimeOriginal>FileModifyDate' \
"$TARGET"

>> Just make a single PTO first, see how it stitches with lux, and if you
>> get the knack of it, you can try several in one go. Good luck!
>>
>
> i've just downloaded lux 1.2, but one imageset is no test for me, so i'm
> going ahead with making a bunch of pto files.
> only than can i compare different light conditions throughout the day
> and see how it runs as i would use it.

Making PTO files with scripting tools from the hugin toolset is not
difficult. I use pto_gen, cpfind and autooptimiser. I prefer making a
new PTO for every batch of images, to be sure the registration is
correct. And when I fuse stacks, I use align_image_set, which can also
expert PTOs.

[Maarten Verberne]

Op 23-Apr-24 om 8:11 schreef 'Kay F. Jahnke' via hugin and other free
panoramic software:

> On 22.04.24 12:29, Maarten Verberne wrote:
>
>> all those similar pto files just for the imagenumber does sound a bit
>> excessive.
>> but hey, if that's the way.
>
> There's nothing stopping you from modifying the PTO files as text files
> with any old text processing tool. But lux needs a PTO file which does
> not contain any placeholders or such.

i already experimented with that :)
just made almost 10.000 pto files this morning.
alas it'll still take until this weekend before i'm able to test.

>
> I'll take your post as an inspiration, though, and think about ways how
> to make templating possible with lux. I already have some (undocumented)
> code which I think could be bent to the task - I'll post again if I can
> figure something out. It will probably need additional command line
> parameters or a .lux file wrapping the .pto
>

since this method would entail generating a million extra pto files, i
would obviously welcome it.
and that might be a lot, but also take into account that with
nona>enblend, the system creates and destroys twice as many temp images
and i have no problem accepting that.

so what's best is probably personal and i might be the only one
interested in templating the filename.

>
> Yes, exiftool is quite a mouthful. This is another thing on my list -
> I'd like to have settings in lux which pick a given set of attributes
> from the source file(s) and move them to the target. I already handle
> EXIF metadata (you can have a selection displayed in the status line),
> but so far the only metadata I write to the output are the ones
> describing the geometry and cropping of the image. In my scripting, I
> use something like this to propagate the metadata:
>
>     exiftool -overwrite_original \
>              -tagsFromFile "$SOURCE" \
>              -All:All \
>              '-DateTimeOriginal>FileModifyDate' \
>              "$TARGET"
>

thanks, much appreciated. i'll see if i can make this work.

>
> Making PTO files with scripting tools from the hugin toolset is not
> difficult. I use pto_gen, cpfind and autooptimiser. I prefer making a
> new PTO for every batch of images, to be sure the registration is
> correct. And when I fuse stacks, I use align_image_set, which can also
> expert PTOs.
>

for me, the text editing way is much easyer because i only have the
folder and image number that i need to change and i can automate that.

[Kay F. Jahnke]

On 23.04.24 09:35, Maarten Verberne wrote:
>
> for me, the text editing way is much easyer because i only have the
> folder and image number that i need to change and i can automate that.

When I fuse brackets, I also put each bracket in a separate folder. Then
I run a script which visits all these folders and runs align_image_stack
there, producing a file 'bracket.pto' in that folder. Then I can either
call lux right then to fuse the bracket, or defer until later.
Maybe you can use a similar scheme.

[Maarten Verberne]

thanks a lot,
i'm always struggling with delayed expansion, so i put it all on one line :)
i just tested this on a file and although
'-DateTimeOriginal>FileModifyDate' gave a Error: File not found
by removing that, the error was gone without me missing out on exif data.
in windows, the exif data time shows up as 'date taken', giving the
original timestamp.
made a few runs on files i created earlyer without exif and i must say,
it's pretty timeconsuming.



Op 23-Apr-24 om 8:11 schreef 'Kay F. Jahnke' via hugin and other free
panoramic software:

[Maarten Verberne]

I did a small test, my first impression is that it's quicker.
in the pto states that jpg compression should be 100% (no compression)

they have the same resolution, so that's fine.
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.

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

[Kay F. Jahnke]

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!