lux 1.2.2 released

[kfj]

Sorry everybody who downloaded 1.2.0. There was a bug in it which prevented it from displaying PTO files with images with alpha channel correctly - just viewing images is fine. So I decided to do a bug fix release. Please download 1.2.2 from https://bitbucket.org/kfj/pv/downloads/

@GnomeNomad, this also fixes the error message when lux terminates.

[David W. Jones]

Thanks. No error messages when it terminates.

It still has difficulty displaying the old PTO, but I created a new one
using current Hugin, using the original images, and Lux has the same
problem with it. I checked in Hugin, the images from my friend's
camera-that-he's-so-proud-of come in with a 5.75deg field of view. I
think I'll stick with my Sony.

Looks like the Lux GUI consists solely of a file selector?

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

[kfj]

It still has difficulty displaying the old PTO, but I created a new one

using current Hugin, using the original images, and Lux has the same
problem with it. I checked in Hugin, the images from my friend's
camera-that-he's-so-proud-of come in with a 5.75deg field of view. I
think I'll stick with my Sony. 

 

5.75 degrees fov sounds like a very long tele indeed.

Looks like the Lux GUI consists solely of a file selector?

What makes you think that? Maybe you haven't tried to access the menu? Just move the mouse to the top margin of the window (or full screen). The menu is usually hidden to show you nothing but your image - both the old and new GUI only show when you move to near the top of the screen.

 

I uploaded a debian package for debian 12 stable. It might be usable for other debian-based distros.

[David W. Jones]

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

It still has difficulty displaying the old PTO, but I created a new one

using current Hugin, using the original images, and Lux has the same
problem with it. I checked in Hugin, the images from my friend's
camera-that-he's-so-proud-of come in with a 5.75deg field of view. I
think I'll stick with my Sony. 

 

5.75 degrees fov sounds like a very long tele indeed.

Too long ago for me to remember. I think his present camera goes up to 600mm. It doesn't have interchangeable lens, just a single quite nice lens with a wide zoom range.

Looks like the Lux GUI consists solely of a file selector?

What makes you think that? Maybe you haven't tried to access the menu? Just move the mouse to the top margin of the window (or full screen). The menu is usually hidden to show you nothing but your image - both the old and new GUI only show when you move to near the top of the screen.

Didn't know that at all. When moving around in an image, I'm usually too busy chasing it to notice that anything popped up. Move the mouse fast in a direction, the image zooms off and keeps zooming off after the mouse stops. At least on my system. Even worse when I use my graphics tablet!

Sorry, ages ago, I worked for a company that sold TrueVision Targa image capture boards for IBM ATs. They came with graphics software known as TIPS (Targa Image Processing System). It had what I consider just about the perfect UI for image-focused work. No menu bar, no window, just your image. Left mouse button was for clicking, dragging, selecting. Right mouse button popped up the menu tree of options available (depending on selection in effect, etc).

So I clicked right button expecting a menu to pop up. Don't know if it's my bad, but it still seems a thought. I noticed that right click does other things in Lux, so maybe ctrl-right-click to bring up the menu, starting wherever the mouse pointer is?

 

I uploaded a debian package for debian 12 stable. It might be usable for other debian-based distros.

Thanks, downloaded, tried it. It installed over the 1.1.6 that was there before. Trying to run lux in a terminal gave me this:

lux: error while loading shared libraries: libexiv2.so.28: cannot open shared object file: No such file or directory

Bookworm comes with libexiv2-27. I have that installed. I guess the libexiv2 version your package is looking for is -28?

[kfj]

On Tuesday, April 23, 2024 at 9:27:49 AM UTC+2 GnomeNomad wrote:

So I clicked right button expecting a menu to pop up. Don't know if it's my bad, but it still seems a thought. I noticed that right click does other things in Lux, so maybe ctrl-right-click to bring up the menu, starting wherever the mouse pointer is?

You can always simply look at the lux documentation, where all mouse gestures and key commands are explained in great detail - the section in the README is titled 'User Interface'. Find the documentation here.

The UI is made so that you can interact with the view with gestures and usually don't have to use the menu, unless you need to change settings or do 'something special'. Once you get the hang of it, it allows you to view (and present) your images fluidly, doing most of the view control with the mouse, and the occasional keystroke. Admittedly, performance with touchpads is not optimal, so if you use lux on a laptop, it's a good idea to connect a physical mouse. I recommend you read the docu - some of the mouse gestures are quite specific and hard to figure out by trial-and-error, e.g. the brightness and zoom level gestures.

 

I uploaded a debian package for debian 12 stable. It might be usable for other debian-based distros.

Thanks, downloaded, tried it. It installed over the 1.1.6 that was there before. Trying to run lux in a terminal gave me this:

lux: error while loading shared libraries: libexiv2.so.28: cannot open shared object file: No such file or directory

Bookworm comes with libexiv2-27. I have that installed. I guess the libexiv2 version your package is looking for is -28?

Ah, thanks for pointing that out! I used a local build of libexiv2 v. 28, and the dependency slipped into the package. Using libexiv2 v.27 is okay, but there are some (annoying) API changes with v.28 and switching back to v.27 requires some finessing in the build. I'll see to it that the dependency is set to v.27 and rebuild and upload the package. Thanks for testing!

[Harry van der Wolf]

 

I uploaded a debian package for debian 12 stable. It might be usable for other debian-based distros.

Thanks, downloaded, tried it. It installed over the 1.1.6 that was there before. Trying to run lux in a terminal gave me this:

lux: error while loading shared libraries: libexiv2.so.28: cannot open shared object file: No such file or directory

Bookworm comes with libexiv2-27. I have that installed. I guess the libexiv2 version your package is looking for is -28?

Ah, thanks for pointing that out! I used a local build of libexiv2 v. 28, and the dependency slipped into the package. Using libexiv2 v.27 is okay, but there are some (annoying) API changes with v.28 and switching back to v.27 requires some finessing in the build. I'll see to it that the dependency is set to v.27 and rebuild and upload the package. Thanks for testing!

I just wanted to report the same. Also on Debian Bookworm.

I will await the new .deb package. 

The AppImage does not run on my Chromebook with beta linux, which is the reported debian bookworm by the way. It starts flashing and completely blocks everything. But that could be because it is linux running in a sandbox on ChromeOS.

My other laptop is an aarch64 laptop and the deb and App image do not run on it either as they are intel x86_64.

Bye,

Harry

[kfj]

Sorry, debian users, for uploading a package with unresolved dependencies. Here's the updated package which asks for libexiv2 v.27, which is the one currently distributed with bookworm:

https://bitbucket.org/kfj/pv/downloads/lux-1.2.2-x86_64.deb

Please download and install again - if there are any further issues, please let me know!

[kfj]

On Wednesday, April 24, 2024 at 10:58:57 AM UTC+2 hvd...@gmail.com wrote:

The AppImage does not run on my Chromebook with beta linux, which is the reported debian bookworm by the way. It starts flashing and completely blocks everything. But that could be because it is linux running in a sandbox on ChromeOS.

 

Sorry I can't really help with that - I was hoping that the AppImage would run just about everywhere, but there seem to be limits... Sometimes lux starts flashing on start-up if the screen extent is unexpected, and my code just re-tries until it gets what it wants, which may not be the right approach in every case. I do that to circumvent buggy behaviour in gnome which occured after the switch to wayland - I reported the problem, but there was no echo, so I had to program around the bug...

Can you please try and start lux in a window to see if that maybe avoids the flashing? just try

lux -W

This is also easier to shut down if the controls don't work anymore.

My other laptop is an aarch64 laptop and the deb and App image do not run on it either as they are intel x86_64.

That's correct. On macOS, you can run the i86 build via rosetta, but on other OSs, there are no handy emulation layers which instantly kick in automatically. But it would be interesting to see ARM builds for other platforms! You know that the build is quite straightforward for Linux, so if your ARM boxes run linux, it might be as easy as clone the pv repo, cd pv, mkdir build, cd build, cmake .., make. I recommend installing highway as a build-time dependency. On ARM it should make a big difference. Usage of ARM-specific build toolchain should happen automatically - the cmake build detects the host CPU. Packaging as debian package is now quite straightforward; all you have to do is to tell cmake to pick the appropriate package generator. The variables for the generator are already in the CMakeLists.txt. you specify the generator like this:

cmake -DCPACK_GENERATOR=DEB

after that, just say

make package

and cmake should produce the debian package. That's how I made the debian package I just uploaded. Apart from not being signed, it seems to fit in well, and it's much smaller than the AppImages! It also saves me the headache of having to include third party copyright info for all the shared libraries which the AppImage generator I use does not find automatically... but, hey, I want to see users from other distros use lux as well, hence the AppImage approach.

If you can produce a viable debian package for Linux on ARM, I can upload it to my downloads page. I think we did that some time ago when you were building lux on your RasPis.

[Maarten Verberne]

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.

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.

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.

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.

[David W. Jones]

Just grabbed it and tried it out. Works fine on stock Bookworm. Thanks!

[David W. Jones]

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

On Tuesday, April 23, 2024 at 9:27:49 AM UTC+2 GnomeNomad wrote:

So I clicked right button expecting a menu to pop up. Don't know if it's my bad, but it still seems a thought. I noticed that right click does other things in Lux, so maybe ctrl-right-click to bring up the menu, starting wherever the mouse pointer is?

You can always simply look at the lux documentation, where all mouse gestures and key commands are explained in great detail - the section in the README is titled 'User Interface'. Find the documentation here.

Yes, the famous RTFM.

The UI is made so that you can interact with the view with gestures and usually don't have to use the menu, unless you need to change settings or do 'something special'. Once you get the hang of it,

Then it's not nearly intuitive. But it is different.

it allows you to view (and present) your images fluidly, doing most of the view control with the mouse, and the occasional keystroke. Admittedly, performance with touchpads is not optimal, so if you use lux on a laptop, it's a good idea to connect a physical mouse.

I do use a physical mouse. I also have a graphics tablet on the laptop. I don't use the touchpad, I really, really, really don't like them!

I recommend you read the docu - some of the mouse gestures are quite specific and hard to figure out by trial-and-error, e.g. the brightness and zoom level gestures.

Zoom in and out using my mouse wheel works exactly as expected.

[Kay F. Jahnke]

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.

[kfj]

On Thursday, April 25, 2024 at 12:26:59 AM UTC+2 GnomeNomad wrote:

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

The UI is made so that you can interact with the view with gestures and usually don't have to use the menu, unless you need to change settings or do 'something special'. Once you get the hang of it,

Then it's not nearly intuitive. But it is different.

 

Yes. I take the liberty to do something new. But then it's no *that* new - the view control is inspired by QTVR mode in 360cities, which I prefer over their default mode. I just took it a step further, adding mouse gestures for brightness control and zoom and tinkering with the zoom mode. You see, lux is a bit like a computer game. In games, you also have to learn the controls to reach the next level, otherwise it's 'game over' before you even get to see anything interesting.

Zoom in and out using my mouse wheel works exactly as expected

 

Did you notice that the mouse wheel scroll is a 'focused zoom' which keeps the mouse position in the same place when you zoom? Nice to quickly zoom onto something off-center. Though I often just secondary-click on the feature I'm interested in (centers the view there) then press '2' a couple of times to zoom quickly (and '3' to zoom out). On the other hand, zooming with a vertical secondary-button click-drag is a centered zoom, but once you're used to the gesture, it gives you very precise control over the speed of the zoom (the further you drag the faster). If you don't like the focus mode, try the --scvd_focused_zoom and --scw_focused_zoom options to change their behaviour. And then you can also zoom with the plus and minus keys on the keypad or with Z/Shift+Z. Did you try the magnifying glass? (press 'I' (the letter igh)). I also often use the '1' key to get a 100% view. And if you get 'lost' just press Return ;-)

[Maarten Verberne]

Op 25-Apr-24 om 9:00 schreef 'Kay F. Jahnke' via hugin and other free
panoramic software:

> Nice to hear you're happy with the image quality! I suppose the size
> issue has sorted itself out with specifying the compression?
>

indeed, the compression setting solved that.

> try this:
>
> lux --fullscreen=no --window_width=320 --window_height=200 --stitch=yes
> *.pto

sweet

> 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.
>

yes, i was suprised too that exiftool takes up a significant amount of
time, but i still like to have the original time taken in the images. so
that stays.

>
> 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.

only nona uses the gpu for a bit, so there is really little gain to be
had from moving to the gpu..the reason i do it is because it appears to
help syncronise scripts when running more than one and like i wrote,
creates a bit extra headroon on the cpu. but with a single instance
there is hardly any difference in time needed to complete.

i am thinking about taking a closer look at what light conditions were
best for enblend or lux so i could potentially use both depending on
what image, but that would entail manual sorting the images beforehand.
so i don't think i will use them next to each other in the end, i have
to make a choice.

>
> 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.
>

considering my setup, lux wouldn't slash my time, in fact it would be a
bit slower since i normally run 3 scripts simultanious.
and i wouldn't have to create all those extra pto files.
however, if i have just one group of images to render, lux beats it
hands down.
so i'm going to focus on those images with troubling light conditions
and see if i can find a winner there, because for me how it looks is
more important than speed....up until a certain point, that is.

[Maarten Verberne]

one other thing i found by accident.
if you start a series, like with
lux --stitch=yes *.pto

and you interrupt (esc) and it restarts itself.
it will ask you the first 2 images if you want to skip or overwrite with
no option to do this for all files found and after that it will go and
overwrite whatever comes next.
not that it matters much in time, since it already loaded the files
before lux discovers that the outputfile already exists.

[Maarten Verberne]

maybe not true, it creates a second instance of the same image with a
different lux added number.

Op 25-Apr-24 om 10:59 schreef Maarten Verberne:

[kfj]

'Messing' with a lux batch job is probably not such a good idea ;-)

Overwriting existing image files is only allowed with an okay from the user, and to give that, you have to have lux open, and see the little dialog. I admit this isn't a very good solution for batch jobs. batch jobs are kind of experimental - I use them when I have e.g. a set of brackets to fuse and I know that the batch can simply run it's course, but to make them suitable for the 'broader public' could do with a bit of tweaking. If you want to stop lux when it's running a batch job, better kill it from the task manager.

On Thursday, April 25, 2024 at 11:00:06 AM UTC+2 mpgve...@gmail.com wrote:

one other thing i found by accident.
if you start a series, like with
lux --stitch=yes *.pto

and you interrupt (esc) and it restarts itself.

...

[Maarten Verberne]

if you don't try, you'll never know ;)

Op 25-Apr-24 om 11:44 schreef 'kfj' via hugin and other free panoramic
software: