lux for Linux as AppImage

[kfj]

Dear all!

So far, I've been offering debian packages for lux, specifically built for several distros and versions. This took quite some time, so I was on the look-out for an alternative. For now, I've settled on AppImage - building the bundle was reasonably painless, and the resulting single-file artifact runs on the linux installations I have floating about, namely debian 11 and 12, and ubuntu 22.04 and 23.04. I built the artifact on the debian 11 system, because the recommendation is to build rather on an older system - I stopped myself from installing something even older just for the purpose.

The AppImage 'promise' is that an AppImage should run on a wide variety of distros, so I'd be curious to hear from users of other linux distros whether they can in fact run this one! Running an AppImage is simple:

• Download it
• set the execute permission
• run it like any other executable

You can download my lux AppImage from here. Please note that this is for AMD/intel 64 bit systems only! It's built from lux master, which is slightly ahead of 1.1.6 proper.

If you're interested in the build process, it's script-driven, and the relevant build script is in the scripts folder off the pv repo's root, requiring only two helper programs and one additional file (the AppRun script, needed here to provide the font file path at run-time).

Kay

[David W. Jones]

So sad to hear this. I've never been able to get AppImages, Flatpaks et al to work on my Debian 11 system. And the idea of a whole huge AppImage just for one pretty small application like Lux just seems like way overkill.

Oh, well.

--
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/9107b0dd-dbe2-440f-a168-1210c9e2935bn%40googlegroups.com.

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

[Kay F. Jahnke]

On 14.07.23 00:04, David W. Jones wrote:

> So sad to hear this. I've never been able to get AppImages, Flatpaks et
> al to work on my Debian 11 system. And the idea of a whole huge AppImage
> just for one pretty small application like Lux just seems like way overkill.
>
> Oh, well.

What is this silly lament? Did you try? Actually, I can tell that you
did not, because the download counter on my download page is still zero.
So you just seem to have preconceived notions. And what do you mean by
'huge'? The AppImage weighs in at 11.7 MB, which is less than the MacOS
dmg and the windows installer (both 13.8). In fact, these latter two use
a similar technology to the AppImage. The AppImage I distribute was
actually built on debian 11, so here's a good chance for you to get your
first AppImage to run on your system. Just a hint: after downloading,
you have to set the execute permission. Then just execute it.

I'm also not sure what you mean by 'a pretty small application'. You
surely can't mean it's functionality, so maybe you mean it's size? The
Linux binary is 25 MB, and the packaging shrinks the data to less than
half, even though it bundles a fair amount of libraries with it.

[kfj]

Ooops... misread the download counter - fourteen so far. So maybe you did try?

[Harry van der Wolf]

Hi,

i tried it on my Chromebook under the builtin linux which is Debian 11. I tried creating a pano, viewing a pano and did some bracketing. That all works fine. I completely stopped with panos and bracketing so I had to take some old series.

One remark: when specifying files or a single pano on the command line, it doesn't accept spaces in paths or file names. Not even when I enclose them in double or single quotes.

And the remark about the app image being  "big". Those persons do not understand that you can create a universal 64bit intel for many platforms in one go which saves the developer a lot of time when developing open-source for his users (aa\nd him/herself of course). One developer can support a lot of users in one app image build run. Obviously they still work from floppy disks as modern systems have huge amounts of disk space. And then they produce a single (tif) pano of 200~250 MB based on raw/tif images of 20~50 MB each. And when you record a 4k movie at a 100 MBps you have a video of 1GB after a minute. 

What is that compared to a "small" appImage?

I have had the same questions/remarks for two of my appImages where users simply only look at their own environment without even looking at the "shocking" size of the images and videos they produce.

Harry

Op vr 14 jul 2023 om 08:44 schreef 'kfj' via hugin and other free panoramic software <hugi...@googlegroups.com>:

--
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/1d48568d-30b7-410c-8c47-4f216f516351n%40googlegroups.com.

[Kay F. Jahnke]

On 14.07.23 09:29, Harry van der Wolf wrote:

> i tried it on my Chromebook under the builtin linux which is Debian 11.
> I tried creating a pano, viewing a pano and did some bracketing. That
> all works fine. I completely stopped with panos and bracketing so I had
> to take some old series.

I'm glad I got you back into it ;)
Thanks for trying it out!

> One remark: when specifying files or a single pano on the command line,
> it doesn't accept spaces in paths or file names. Not even when I enclose
> them in double or single quotes.

Ah, so you get that as well. I had similar problems yesterday, then
forgot about it. Maybe I need to do some finessing in the AppRun script;
I simply pass on arguments with $@. Thanks for pointing me to this
issue. Luckily, when selecting images with lux' own file-select dialog
(press 'F'), white space in the file name isn't a problem.

> And the remark about the app image being  "big". Those persons do not
> understand that you can create a universal 64bit intel for many
> platforms in one go which saves the developer a lot of time
> when developing open-source for his users (aa\nd him/herself of course).
> One developer can support a lot of users in one app image build run.
> Obviously they still work from floppy disks as modern systems have huge
> amounts of disk space. And then they produce a single (tif) pano of
> 200~250 MB based on raw/tif images of 20~50 MB each. And when you record
> a 4k movie at a 100 MBps you have a video of 1GB after a minute.
> What is that compared to a "small" appImage?

Indeed, it's next to nothing. The lux AppImage is about as large as some
single (JPG) images from my Canon Powershot G9X Mk. II.

> I have had the same questions/remarks for two of my appImages where
> users simply only look at their own environment without even looking at
> the "shocking" size of the images and videos they produce.

So you use AppImage as well. I like what I've seen from it so far. The
docu is a bit hard to grasp initially, but the process is really quite
simple. I think I'll invest a bit more time to bring my AppImages up to
their standards for AppImageHub and distribute it for Linux like that.
seems like a huge time-saver and should increase lux' visibility.

Kay

[Kay F. Jahnke]

On 14.07.23 09:48, 'Kay F. Jahnke' via hugin and other free panoramic

software wrote:
> On 14.07.23 09:29, Harry van der Wolf wrote:
>
>> One remark: when specifying files or a single pano on the command
>> line, it doesn't accept spaces in paths or file names. Not even when I
>> enclose them in double or single quotes.
>
> Ah, so you get that as well. I had similar problems yesterday, then
> forgot about it. Maybe I need to do some finessing in the AppRun script;
> I simply pass on arguments with $@. Thanks for pointing me to this
> issue. Luckily, when selecting images with lux' own file-select dialog
> (press 'F'), white space in the file name isn't a problem.

Silly me, of course I have to pass the args on with "$@" (with quotes).

I'm just now setting up a VM with ubuntu 18.04 to run a build on the
recommended 'oldest still-supported ubuntu LTS release', then I'll build
the AppImage again there and upload the new build.

Kay

[Kay F. Jahnke]

I fixed the issue with passing filenames with white space on the CL and
built a fresh AppImage on a Kubuntu 18.04 LTS VM, which should make the
AppImage usable on even more platforms. You can download the new
AppImage here:

https://bitbucket.org/kfj/pv/downloads/lux-1.1.6-x86_64.AppImage

Kay

[Harry van der Wolf]

Hi,

Using ./lux-1.1.6-x86_64.AppImage ~/128GB/Afbeeldingen/1JTG/1tifpanos/2003-0713-0608\ zomervakantie-Thisted-0725-0728_Thisted-038-Thisted-051-overall.tif

does work.

Using ./lux-1.1.6-x86_64.AppImage "~/128GB/Afbeeldingen/1JTG/1tifpanos/2003-0713-0608 zomervakantie-Thisted-0725-0728_Thisted-038-Thisted-051-overall.tif"

doesn't work.

Harry

Op vr 14 jul 2023 om 18:13 schreef 'Kay F. Jahnke' via hugin and other free panoramic software <hugi...@googlegroups.com>:

--
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/cd48832f-3a07-bf14-8032-93b5d7d08650%40yahoo.com.

[Harry van der Wolf]

You use:

$APPDIR/usr/bin/lux -w $APPDIR/usr/share/lux/fonts/NotoSans-Regular.ttf "$@"

Please try with:

$APPDIR/usr/bin/lux -w $APPDIR/usr/share/lux/fonts/NotoSans-Regular.ttf ${1+"$@"} &

Harry

Op vr 14 jul 2023 om 20:28 schreef Harry van der Wolf <hvd...@gmail.com>:

[Kay F. Jahnke]

On 14.07.23 20:28, Harry van der Wolf wrote:

> Using ./lux-1.1.6-x86_64.AppImage
> ~/128GB/Afbeeldingen/1JTG/1tifpanos/2003-0713-0608\
> zomervakantie-Thisted-0725-0728_Thisted-038-Thisted-051-overall.tif
> does work.
>
> Using ./lux-1.1.6-x86_64.AppImage
> "~/128GB/Afbeeldingen/1JTG/1tifpanos/2003-0713-0608
> zomervakantie-Thisted-0725-0728_Thisted-038-Thisted-051-overall.tif"
> doesn't work.
>

On 14.07.23 20:40, Harry van der Wolf wrote:

> You use:
> $APPDIR/usr/bin/lux -w $APPDIR/usr/share/lux/fonts/NotoSans-Regular.ttf "$@"
>
> Please try with:
> $APPDIR/usr/bin/lux -w
> $APPDIR/usr/share/lux/fonts/NotoSans-Regular.ttf ${1+"$@"} &

I have doubts whether the tilde will work as expected inside the double
quotes. If you use /home/... instead of the tilde, embedded ws is no
problem with "$@". According to this:

https://unix.stackexchange.com/questions/151850/why-doesnt-the-tilde-expand-inside-double-quotes

inside double quotes, the tilde has no special meaning, so the second
invocation you attempt will try and find file names containing literal
tilde characters. If you try your invocation containing a tilde inside
double quotes with plain lux, it won't work either. I think your second
invocation (the one labeled 'doesn't work') is incorrect in the first place.

There are two good ways to deal with complicated file paths with lux:

1. cd to the folder and use relative names instead

2. echo the files and use lux in streaming mode:

ls ~/awful\ folder\ with\ spaces/*.JPG | lux -

Note the trailing '-' in lux' argument list. This switches it to
'streaming mode' where it accepts image file names from stdin. If these
names contain ws, it's no problem.

Knowing streaming mode is good anyway - I often work up a set of images
in a folder, which then contains mixed file names like IMG_1234.JPG,
IMG_1234_IMG_1236.jpg and IMG_1234.lux.1.jpg. Then I make a file list, like

ls *.JPG *.jpg | sort > file.lst

Then, later on, to look at the image, I do

lux - < file.lst

For a slide show, throw in arguments like

--show_status_line=no --slide_interval=4 --slideshow_on=yes

Streaming mode is a cool tool to go through entire directory trees, as
well. Try:

find ~/Pictures -name '*.jpg' -print | lux -d1 -

All of the above should work with the AppImage instead of plain lux' as
well. The AppImage makes an attempt to 'blend in' an behave exactly as
the contained binary would.

Kay

[David W. Jones]

On 7/13/23 21:48, 'Kay F. Jahnke' via hugin and other free panoramic software wrote:

And the remark about the app image being "big". Those persons do not 
understand that you can create a universal 64bit intel for many 
platforms in one go which saves the developer a lot of time 
when developing open-source for his users (aa\nd him/herself of 
course). One developer can support a lot of users in one app image 
build run. 

So it exists solely for the convenience of the developer? Or, rather, 
the convenience of the developer outweighs that of the much larger 
number of users?

Obviously they still work from floppy disks as modern systems have 
huge amounts of disk space. And then they produce a single (tif) pano 
of 200~250 MB based on raw/tif images of 20~50 MB each. And when you 
record a 4k movie at a 100 MBps you have a video of 1GB after a minute.
What is that compared to a "small" appImage?

Well, just to put somethings to rest about this before I proceed to 
ignore it.

My system has an i9 processor, 64GB RAM, 2TB of fast NVME SSD, and 
NVidia graphics. In addition, I have 14TB of storage in my file server. 
Not a floppy disk in sight on either system.

So I'm not choosing to refuse to put the effort into AppImages, flatpaks 
and other such developer conveniences because my system is under-powered 
or anything.

I'm choosing not to bother with them because I would rather spend my 
disk space on my images, which are more important to me.

Regarding lux. The non-appimage version runs here, with its 
non-intuitive way of handling mouse movements and image banding that 
bugs the heck out of me.

I think lux would be more useful as a library usable by other programs 
(like Hugin, Krita, GIMP, Blender, Inkscape) to tap GPU power for 
remapping and rendering.

But, anyway, have fun!

[Kay F. Jahnke]

On 16.07.23 04:19, David W. Jones wrote:

> Regarding lux. The non-appimage version runs here, with its
> non-intuitive way of handling mouse movements and image banding that
> bugs the heck out of me.

Maybe your user experience can be improved? I feel that a UI close to
360cities' QTVR mode is the best way to interact with, especially, full
sphericals. Admittedly, this may take some time to learn if one isn't
already familiar with it. What you mean with image banding I have no idea.

There once was a time when users felt they were part of a community.
They would work with a program, and if something irked them or they had
ideas what could be made better they would contact the developers and
tell them. For developers, this feedback was valuable, because they
often don't interact with the software from a user's point of view,
because they are 'too much inside' the program and it's inner workings.
And there were others in the community who'd help with technicalities
like packaging, to keep such administrative tasks off the back of the
developers, so that they could concentrate on the software's functionality.

So why am I using past tense? Because I feel these times have passed.
I've been developing lux for several years now, and I feel there is no
community feedback - apart from a few posts full of harsh critcism
giving my program a bad name. I've seldom heard from anyone who actually
said they liked something I made - they all just download it and I have
no idea what happens then. Do they try it once then throw it away
because they don't get it? Keep using it all the time so happily they
never even think about it? They sure seem to take it for granted that
someone would sit down and off-handedly re-implement the Burt&Adelson
image splining algorithm in their spare time and have no problem with
ignoring the fact because, hey, it's been implemented before and we have
used that for years why would we change...

And everyone takes for granted that, on top of developing the software,
I do all the documentation, packaging, distribution and maintenance as
well. Only if something is amiss, there may be a faint echo along the
lines of 'your program is crap, xy does this much better' if their
attention span isn't so short that they immediately proceed to the next
promising stimulus.

If you have specific points in the user interface you'd like to discuss,
why don't you just ask? It's quite possible that some things you'd like
to have are already there and can be had by changing a few parameters.
And, if not, how about asking for a feature? Rather than just
complaining in a thread about a different issue (AppImages) that the UI
bothers you. I feel you tend to give negative criticism. Can you
recommend a good multi-platform panorama viewer which does everything to
your liking?

> I think lux would be more useful as a library usable by other programs
> (like Hugin, Krita, GIMP, Blender, Inkscape) to tap GPU power for
> remapping and rendering.

This is actually a good point. I don't agree lux would be more useful
that way, but I think that some of my back-end code would come in handy
in some of the programs you mention. But the core feature of lux is that
it's rendering on the CPU, not the GPU.

There are always two aspects to using a library: the library provides
features, a program uses them. I can make a beautiful library to no
effect if noone uses it. Since you mention hugin, I proposed to make lux
part of the hugin bundle. No interest. The proposal was shot down. So
how do you think the hugin crew would react if I proposed to them to use
functionality of a hypothetical lux library? I can't see that happening.

Kay

[Kay F. Jahnke]

Until now, I've only released new lux binaries when I released a new
version, or if there was a 'special' reason - like a new experimental
build. With my switch to AppImage, I'll offer more recent AppImages
which are made straight from the master branch - not quite 'nightlies',
but builds reflecting the status quo right when they are made. You can
find these builds here:

https://bitbucket.org/kfj/pv/downloads/lux-master-x86_64.AppImage

The one I just uploaded already fixes a bug in lux 1.1.7, which produced
a 'hanging' thread when lux was terminated due to an unrecoverable error.

[kfj]

I've released lux 1.1.8 which has the bug fix mentioned in the last post, and better support for making AppImages.

The new version can be downloaded here:

https://bitbucket.org/kfj/pv/downloads/lux-1.1.8-x86_64.AppImage

This version was built on ubuntu 20.04, because 18.04 is no longer supported. I hope this does not break use on older systems.