lux - FOSS multiplatform image and panorama viewer
453 views
Skip to first unread message
kfj
Apr 13, 2021, 5:59:29 AM4/13/21
to hugin and other free panoramic software
Dear all!
My viewer 'pv' has been renamed to 'lux', and it's seen a lot of development recently. There are two important changes:
- lux now builds with CMake, and readymade binaries are available for download
- lux can now do stitching and exposure fusion
Special thanks go to Kornel for the work on the CMakeLists.txt, and to Harry for providing code to make mac bundles and testing my exposure fusion code, and I'd also like to thank all of you who have accompanied the development process with helpful suggestions and bug reports.
You can find bundles for mac OS and windows, and a simple debian package, on the project's download page. There's also documentation in HTML format, and online on the project's bitbucket page.
The binaries currently on offer are all version 1.0.8, which has seen a good deal of testing and should be reasonably stable.
Kay
kfj
Jun 4, 2021, 1:16:04 PM6/4/21
to hugin and other free panoramic software
Dear all!
I've just released lux 1.0.9. This version does not introduce much new functionality, the focus was more on usability and stability. I've uploaded a debian package and a windows bundle to the project's download page:
Hopefully, a mac bundle will be available soon.
Kay
David W. Jones
Jun 4, 2021, 11:31:32 PM6/4/21
to hugi...@googlegroups.com
Well, here's what happened when I tried to install it here on Debian 11:
Preparing to unpack lux-1.0.9-0git-Linux.deb ...
Unpacking lux (1.0.9-0git) ...
dpkg: dependency problems prevent configuration of lux:
lux depends on libc6 (>= 2.29); however:
Version of libc6:amd64 on system is 2.28-10.
lux depends on libexiv2-27 (>= 0.25); however:
Package libexiv2-27 is not installed.
lux depends on libgcc-s1 (>= 4.0); however:
Package libgcc-s1 is not installed.
lux depends on libstdc++6 (>= 9); however:
Version of libstdc++6:amd64 on system is 8.3.0-6.
lux depends on libvigraimpex11 (>= 1.11.1+dfsg); however:
Package libvigraimpex11 is not installed.
dpkg: error processing package lux (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
lux
On 6/4/21 7:16 AM, 'kfj' via hugin and other free panoramic software wrote:
> Dear all!
>
> I've just released lux 1.0.9. This version does not introduce much new
> functionality, the focus was more on usability and stability. I've
> uploaded a debian package and a windows bundle to the project's download
> page:
>
> https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0git-Linux.deb
> https://bitbucket.org/kfj/pv/downloads/lux_for_windows_1.0.9.zip
>
> Hopefully, a mac bundle will be available soon.
>
> Kay
>
> On Tuesday, April 13, 2021 at 11:59:29 AM UTC+2 kfj wrote:
>
> Dear all!
>
> My viewer 'pv' has been renamed to 'lux', and it's seen a lot of
> development recently. There are two important changes:
>
> - lux now builds with CMake, and readymade binaries are available
> for download
>
> - lux can now do stitching and exposure fusion
>
> Special thanks go to Kornel for the work on the CMakeLists.txt, and
> to Harry for providing code to make mac bundles and testing my
> exposure fusion code, and I'd also like to thank all of you who have
> accompanied the development process with helpful suggestions and bug
> reports.
>
> You can find bundles for mac OS and windows, and a simple debian
> package, on the project's download page
> <https://bitbucket.org/kfj/pv/downloads/>. There's alsodocumentation
> <https://bitbucket.org/kfj/pv/downloads/README.html> in HTML format,
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com
My password is the last 8 digits of π.
Preparing to unpack lux-1.0.9-0git-Linux.deb ...
Unpacking lux (1.0.9-0git) ...
dpkg: dependency problems prevent configuration of lux:
lux depends on libc6 (>= 2.29); however:
Version of libc6:amd64 on system is 2.28-10.
lux depends on libexiv2-27 (>= 0.25); however:
Package libexiv2-27 is not installed.
lux depends on libgcc-s1 (>= 4.0); however:
Package libgcc-s1 is not installed.
lux depends on libstdc++6 (>= 9); however:
Version of libstdc++6:amd64 on system is 8.3.0-6.
lux depends on libvigraimpex11 (>= 1.11.1+dfsg); however:
Package libvigraimpex11 is not installed.
dpkg: error processing package lux (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
lux
On 6/4/21 7:16 AM, 'kfj' via hugin and other free panoramic software wrote:
> Dear all!
>
> I've just released lux 1.0.9. This version does not introduce much new
> functionality, the focus was more on usability and stability. I've
> uploaded a debian package and a windows bundle to the project's download
> page:
>
> https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0git-Linux.deb
> https://bitbucket.org/kfj/pv/downloads/lux_for_windows_1.0.9.zip
>
> Hopefully, a mac bundle will be available soon.
>
> Kay
>
> On Tuesday, April 13, 2021 at 11:59:29 AM UTC+2 kfj wrote:
>
> Dear all!
>
> My viewer 'pv' has been renamed to 'lux', and it's seen a lot of
> development recently. There are two important changes:
>
> - lux now builds with CMake, and readymade binaries are available
> for download
>
> - lux can now do stitching and exposure fusion
>
> Special thanks go to Kornel for the work on the CMakeLists.txt, and
> to Harry for providing code to make mac bundles and testing my
> exposure fusion code, and I'd also like to thank all of you who have
> accompanied the development process with helpful suggestions and bug
> reports.
>
> You can find bundles for mac OS and windows, and a simple debian
> package, on the project's download page
> <https://bitbucket.org/kfj/pv/downloads/README.html> in HTML format,
> and online on the project's bitbucket page
> <https://bitbucket.org/kfj/pv>.
>
> The binaries currently on offer are all version 1.0.8, which has
> seen a good deal of testing and should be reasonably stable.
>
> Kay
--
> The binaries currently on offer are all version 1.0.8, which has
> seen a good deal of testing and should be reasonably stable.
>
> Kay
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
Jun 5, 2021, 4:37:05 AM6/5/21
to hugi...@googlegroups.com
Am 05.06.21 um 05:31 schrieb David W. Jones:
The dependencies are the same as they have been throughout lux 1.0.8;
this issue is not new with 1.0.9:
I've probably misled you by simply stating that I made a 'debian
package': I develop lux on ubuntu, here I use ubuntu ubuntu 20.04.2 LTS,
which should differ quite a bit in the set of packages and their
versions to your debian 11, which is also quite brand-new and has not
been released yet. What surprises me is that dpkg can't get hold of
common packages like libexiv2, libgcc and libstdc++, but these may be
naming problems, where the ubuntu naming scheme differs from debian's.
In general, you can't rely on ubuntu-built packages to run on debian.
I'll change the name of the packages I offer for download to make clear
what the target distro is, to help other users avoid this pitfall. As
far as ubuntu goes, basing on 20.04 LTS is quite conservative, and the
dependencies should work on newer non-LTS distros as well - ubuntu
users, please report back! For now, there are two debian packages I can
offer:
https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0-debian10-i32.deb
https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0git-ubuntu20.04-amd64.deb
As you can see, the debian 10 package is 32 bits - I currently don't
have a 64bit install of debian 10 handy, but I just did the CMake build
here on the debian10 32bit system to verify that it builds and installs
without problems, so I thought I might as well put it up for download.
The ubuntu20.04 amd64 package is the same as what I had offered before
as the 1.0.9 'Linux' package, only with a clearer name. Sorry for the
confusion.
How about you build a debian package on your machine? Then we can have a
look at what your system puts into the .deb. Just follow the steps in
'Building lux with cmake' given on the bitbucket page. Then I can put
your package online if you like, to help other debian 11 users. To build
a debian package, you have to invoke cmake with -DCPACK_BINARY_DEB=ON
during cmake configuration, and to build the package you have to say
'make package'.
Are you dd or involved with the debian project? How about you help
bringing lux to debian? With an actively maintained lux package on
debian, we might rely on it trickling down to ubuntu and other
debian-based distros - I've done this successfully with the vspline
debian package, but that's already quite a bit of work, and I've shunned
going through the laborious process for yet another package - especially
as I don't have dd status and have to bother my mentor whenever I have a
new version.
@Kornel: Is there a way to provide 'linux bundles' which include all
shared libraries, as I make them for the Windows stickware version? Can
CMake output flatpak or a similar format which works on more distros?
The CMake package build produces a package named
'lux-1.0.9-0git-Linux.deb', can we influence the naming of the package?
It might be good to have 'ubuntu' or 'debian' in the package name rather
than 'Linux', and also the version, like 20.04, and the architecture,
like amd64 - I've done the naming of the two packages I just put up for
download manually.
Kay
> Well, here's what happened when I tried to install it here on Debian 11:
>
> Preparing to unpack lux-1.0.9-0git-Linux.deb ...
> Unpacking lux (1.0.9-0git) ...
> dpkg: dependency problems prevent configuration of lux:
> lux depends on libc6 (>= 2.29); however:
> Version of libc6:amd64 on system is 2.28-10.
> lux depends on libexiv2-27 (>= 0.25); however:
> Package libexiv2-27 is not installed.
> lux depends on libgcc-s1 (>= 4.0); however:
> Package libgcc-s1 is not installed.
> lux depends on libstdc++6 (>= 9); however:
> Version of libstdc++6:amd64 on system is 8.3.0-6.
> lux depends on libvigraimpex11 (>= 1.11.1+dfsg); however:
> Package libvigraimpex11 is not installed.
>
> dpkg: error processing package lux (--install):
> dependency problems - leaving unconfigured
> Errors were encountered while processing:
> lux
Thanks for reporting back!
>
> Preparing to unpack lux-1.0.9-0git-Linux.deb ...
> Unpacking lux (1.0.9-0git) ...
> dpkg: dependency problems prevent configuration of lux:
> lux depends on libc6 (>= 2.29); however:
> Version of libc6:amd64 on system is 2.28-10.
> lux depends on libexiv2-27 (>= 0.25); however:
> Package libexiv2-27 is not installed.
> lux depends on libgcc-s1 (>= 4.0); however:
> Package libgcc-s1 is not installed.
> lux depends on libstdc++6 (>= 9); however:
> Version of libstdc++6:amd64 on system is 8.3.0-6.
> lux depends on libvigraimpex11 (>= 1.11.1+dfsg); however:
> Package libvigraimpex11 is not installed.
>
> dpkg: error processing package lux (--install):
> dependency problems - leaving unconfigured
> Errors were encountered while processing:
> lux
The dependencies are the same as they have been throughout lux 1.0.8;
this issue is not new with 1.0.9:
I've probably misled you by simply stating that I made a 'debian
package': I develop lux on ubuntu, here I use ubuntu ubuntu 20.04.2 LTS,
which should differ quite a bit in the set of packages and their
versions to your debian 11, which is also quite brand-new and has not
been released yet. What surprises me is that dpkg can't get hold of
common packages like libexiv2, libgcc and libstdc++, but these may be
naming problems, where the ubuntu naming scheme differs from debian's.
In general, you can't rely on ubuntu-built packages to run on debian.
I'll change the name of the packages I offer for download to make clear
what the target distro is, to help other users avoid this pitfall. As
far as ubuntu goes, basing on 20.04 LTS is quite conservative, and the
dependencies should work on newer non-LTS distros as well - ubuntu
users, please report back! For now, there are two debian packages I can
offer:
https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0-debian10-i32.deb
https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0git-ubuntu20.04-amd64.deb
As you can see, the debian 10 package is 32 bits - I currently don't
have a 64bit install of debian 10 handy, but I just did the CMake build
here on the debian10 32bit system to verify that it builds and installs
without problems, so I thought I might as well put it up for download.
The ubuntu20.04 amd64 package is the same as what I had offered before
as the 1.0.9 'Linux' package, only with a clearer name. Sorry for the
confusion.
How about you build a debian package on your machine? Then we can have a
look at what your system puts into the .deb. Just follow the steps in
'Building lux with cmake' given on the bitbucket page. Then I can put
your package online if you like, to help other debian 11 users. To build
a debian package, you have to invoke cmake with -DCPACK_BINARY_DEB=ON
during cmake configuration, and to build the package you have to say
'make package'.
Are you dd or involved with the debian project? How about you help
bringing lux to debian? With an actively maintained lux package on
debian, we might rely on it trickling down to ubuntu and other
debian-based distros - I've done this successfully with the vspline
debian package, but that's already quite a bit of work, and I've shunned
going through the laborious process for yet another package - especially
as I don't have dd status and have to bother my mentor whenever I have a
new version.
@Kornel: Is there a way to provide 'linux bundles' which include all
shared libraries, as I make them for the Windows stickware version? Can
CMake output flatpak or a similar format which works on more distros?
The CMake package build produces a package named
'lux-1.0.9-0git-Linux.deb', can we influence the naming of the package?
It might be good to have 'ubuntu' or 'debian' in the package name rather
than 'Linux', and also the version, like 20.04, and the architecture,
like amd64 - I've done the naming of the two packages I just put up for
download manually.
Kay
Harry van der Wolf
Jun 5, 2021, 5:25:05 AM6/5/21
to hugi...@googlegroups.com
This happens more often with manually installing debian packages.
So you do a "sudo dpkg -i lux-<version>.dpkg" and get this error.
What you now should do is a:
"sudo dpkg --configure -a"
followed by:
"sudo apt-get -f install"
That should fix it.
And if you had done a simple DuckDuckGo/Google search, you would have found that as well as it is as old as the world (well, almost as old).
This could be solved by creating a flatpack or appimage which has everything "inside".
Harry
Op za 5 jun. 2021 om 10:37 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/86b8821a-479b-7b8b-1619-43df02b157c1%40yahoo.com.
Kornel Benko
Jun 5, 2021, 5:43:21 AM6/5/21
to hugi...@googlegroups.com
Am Sat, 5 Jun 2021 10:36:55 +0200
schrieb "'Kay F. Jahnke' via hugin and other free panoramic software"
<hugi...@googlegroups.com>:
...
But I can provide a debian package (based on ubuntu 19) if needed.
$ dpkg -s lux
Package: lux
Status: install ok installed
Priority: optional
Section: universe/graphics
Installed-Size: 12741
Maintainer: Kay F. Jahnke <kfjah...@gmail.com>
Architecture: amd64
Version: 1.0.9-0git
Depends: libc6 (>= 2.15), libgcc1 (>= 1:3.0), libsfml-graphics2.4, libsfml-system2.4 (>=
2.4.2+dfsg-4~), libsfml-window2.4 (>= 2.4.1~), libstdc++6 (>= 6)
Description: lux - a free open source image and panorama viewer
.
lux can show -normal- images, panoramas in various formats
and PTO files made with software like hugin. It can also do
simple stitching and blending jobs. You can find documentation
at the bitbucket site: https://bitbucket.org/kfj/pv
$ ldd `which lux` | egrep 'libexiv|libgcc|libstdc|libvigra'
libvigraimpex.so.11 => /usr/local/lib/libvigraimpex.so.11 (0x00007ff05ae5d000)
libexiv2.so.27 => /usr/lib/libexiv2.so.27 (0x00007ff05a210000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff059c68000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff0596b2000)
I suppose that libvigraimpex.so.11 may make problems though.
Kornel
schrieb "'Kay F. Jahnke' via hugin and other free panoramic software"
<hugi...@googlegroups.com>:
...
> @Kornel: Is there a way to provide 'linux bundles' which include all
> shared libraries, as I make them for the Windows stickware version? Can
> CMake output flatpak or a similar format which works on more distros?
Too dangerous, even if that were possible.
> shared libraries, as I make them for the Windows stickware version? Can
> CMake output flatpak or a similar format which works on more distros?
But I can provide a debian package (based on ubuntu 19) if needed.
$ dpkg -s lux
Package: lux
Status: install ok installed
Priority: optional
Section: universe/graphics
Installed-Size: 12741
Maintainer: Kay F. Jahnke <kfjah...@gmail.com>
Architecture: amd64
Version: 1.0.9-0git
Depends: libc6 (>= 2.15), libgcc1 (>= 1:3.0), libsfml-graphics2.4, libsfml-system2.4 (>=
2.4.2+dfsg-4~), libsfml-window2.4 (>= 2.4.1~), libstdc++6 (>= 6)
Description: lux - a free open source image and panorama viewer
.
lux can show -normal- images, panoramas in various formats
and PTO files made with software like hugin. It can also do
simple stitching and blending jobs. You can find documentation
at the bitbucket site: https://bitbucket.org/kfj/pv
$ ldd `which lux` | egrep 'libexiv|libgcc|libstdc|libvigra'
libvigraimpex.so.11 => /usr/local/lib/libvigraimpex.so.11 (0x00007ff05ae5d000)
libexiv2.so.27 => /usr/lib/libexiv2.so.27 (0x00007ff05a210000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff059c68000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff0596b2000)
I suppose that libvigraimpex.so.11 may make problems though.
Kornel
Gunter Königsmann
Jun 5, 2021, 6:06:11 AM6/5/21
to hugi...@googlegroups.com, Kornel Benko
Why dangerous?
Kind regards,
Gunter.
Kind regards,
Gunter.
--
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/20210605114315.061ff6ba%40admin1-desktop.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Harry van der Wolf
Jun 5, 2021, 7:11:09 AM6/5/21
to hugi...@googlegroups.com
Hi Kay, all,
I created a Lux 1.0.9 app bundle for MacOS and a Lux 1.0.9 distributable binary version for MacOS.
The first one for the GUI lovers, the 2nd for the command line lovers.
Links via a PM. To be added (if you want to) to your bitbucket download section.
Harry
Op vr 4 jun. 2021 om 19:16 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/79f6491e-c2e3-464f-8603-e1a4691f5444n%40googlegroups.com.
Kay F. Jahnke
Jun 5, 2021, 11:30:54 AM6/5/21
to hugi...@googlegroups.com
Am 05.06.21 um 13:10 schrieb Harry van der Wolf:
https://bitbucket.org/kfj/pv/downloads/LUX-1.0.9-MacOS.dmg
https://bitbucket.org/kfj/pv/downloads/LUX-1.0.9-distributable-MacOS.zip
Kay
>
> I created a Lux 1.0.9 app bundle for MacOS and a Lux 1.0.9 distributable
> binary version for MacOS.
> The first one for the GUI lovers, the 2nd for the command line lovers.
Thanks, Harry! I copied the files to the download page:
> I created a Lux 1.0.9 app bundle for MacOS and a Lux 1.0.9 distributable
> binary version for MacOS.
> The first one for the GUI lovers, the 2nd for the command line lovers.
https://bitbucket.org/kfj/pv/downloads/LUX-1.0.9-MacOS.dmg
https://bitbucket.org/kfj/pv/downloads/LUX-1.0.9-distributable-MacOS.zip
Kay
David W. Jones
Jun 7, 2021, 3:28:58 AM6/7/21
to hugi...@googlegroups.com
I think the last time I had a working PV (before name change to lux) on
my system, I had to compile it myself.
Sorry, I don't do flatpack or appimage. I've tried both with a couple of
different apps, with complete lack of success, and no interest in
figuring out why they didn't work.
Doesn't compiling something to use static libs also include everything
inside the app?
On 6/4/21 11:24 PM, Harry van der Wolf wrote:
> This happens more often with manually installing debian packages.
>
> So you do a "sudo dpkg -i lux-<version>.dpkg" and get this error.
> What you now should do is a:
> "sudo dpkg --configure -a"
> followed by:
> "sudo apt-get -f install"
>
> That should fix it.
> And if you had done a simple DuckDuckGo/Google search, you would have
> found that as well as it is as old as the world (well, almost as old).
>
> This could be solved by creating a flatpack or appimage which has
> everything "inside".
>
> Harry
>
> Op za 5 jun. 2021 om 10:37 schreef 'Kay F. Jahnke' via hugin and other
> free panoramic software <hugi...@googlegroups.com
> <mailto:hugi...@googlegroups.com>>:
> <https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0-debian10-i32.deb>
> https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0git-ubuntu20.04-amd64.deb
my system, I had to compile it myself.
Sorry, I don't do flatpack or appimage. I've tried both with a couple of
different apps, with complete lack of success, and no interest in
figuring out why they didn't work.
Doesn't compiling something to use static libs also include everything
inside the app?
On 6/4/21 11:24 PM, Harry van der Wolf wrote:
> This happens more often with manually installing debian packages.
>
> So you do a "sudo dpkg -i lux-<version>.dpkg" and get this error.
> What you now should do is a:
> "sudo dpkg --configure -a"
> followed by:
> "sudo apt-get -f install"
>
> That should fix it.
> And if you had done a simple DuckDuckGo/Google search, you would have
> found that as well as it is as old as the world (well, almost as old).
>
> This could be solved by creating a flatpack or appimage which has
> everything "inside".
>
> Harry
>
> Op za 5 jun. 2021 om 10:37 schreef 'Kay F. Jahnke' via hugin and other
> free panoramic software <hugi...@googlegroups.com
> https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0git-ubuntu20.04-amd64.deb
Kay F. Jahnke
Jun 7, 2021, 4:01:39 AM6/7/21
to hugi...@googlegroups.com
Am 07.06.21 um 09:28 schrieb David W. Jones:
> I think the last time I had a working PV (before name change to lux) on
> my system, I had to compile it myself.
You did, indeed, because at that time there were no readymade binary
packages for linux. Building is now easier, due to the build process
with cmake. If you've managed the 'old' build, the new one is going to
be easy. Please refer to the documentation. And then you can build a
.deb which works for you and for debian11 in general, and you can share it.
> Sorry, I don't do flatpack or appimage. I've tried both with a couple of
> different apps, with complete lack of success, and no interest in
> figuring out why they didn't work.
Harry's comment about using flatpack or appimage was not directed at
you, but simply stating the fact that these two methods of installation
avoid issues with incompatible or inaccessible libraries, because they
provide an environment where the necessary shared library infrastructure
is provided bundled with the installation medium.
We're trying to provide installable debian packages for users who don't
want to experiment with these 'novel' methods, but since you use a
flavour of Linux which isn't so common among end-users, it's slightly
more difficult to help you get going. Did Harry's hint not work for you?
> Doesn't compiling something to use static libs also include everything
> inside the app?
It, does, but it produces enormous bloat. And if anything relevant in
one of the libraries changes, you have to recompile, redistribute, and
make all users reinstall. Linux has decided against this, and for good
reasons.
Kay
> I think the last time I had a working PV (before name change to lux) on
> my system, I had to compile it myself.
packages for linux. Building is now easier, due to the build process
with cmake. If you've managed the 'old' build, the new one is going to
be easy. Please refer to the documentation. And then you can build a
.deb which works for you and for debian11 in general, and you can share it.
> Sorry, I don't do flatpack or appimage. I've tried both with a couple of
> different apps, with complete lack of success, and no interest in
> figuring out why they didn't work.
you, but simply stating the fact that these two methods of installation
avoid issues with incompatible or inaccessible libraries, because they
provide an environment where the necessary shared library infrastructure
is provided bundled with the installation medium.
We're trying to provide installable debian packages for users who don't
want to experiment with these 'novel' methods, but since you use a
flavour of Linux which isn't so common among end-users, it's slightly
more difficult to help you get going. Did Harry's hint not work for you?
> Doesn't compiling something to use static libs also include everything
> inside the app?
one of the libraries changes, you have to recompile, redistribute, and
make all users reinstall. Linux has decided against this, and for good
reasons.
Kay
Harry van der Wolf
Jun 7, 2021, 6:09:53 AM6/7/21
to hugi...@googlegroups.com
Op ma 7 jun. 2021 om 10:01 schreef 'Kay F. Jahnke' via hugin and other free panoramic software <hugi...@googlegroups.com>:
Am 07.06.21 um 09:28 schrieb David W. Jones:
> Sorry, I don't do flatpack or appimage. I've tried both with a couple of
> different apps, with complete lack of success, and no interest in
> figuring out why they didn't work.
Harry's comment about using flatpack or appimage was not directed at
you, but simply stating the fact that these two methods of installation
avoid issues with incompatible or inaccessible libraries, because they
provide an environment where the necessary shared library infrastructure
is provided bundled with the installation medium.
Indeed. I already had a look at an AppImage as I had made two before. In this case there is something with libc6 that need to be patched, where you normally use the lib6c from the system.
aferrero2707 used that same patch for the Hugin app image, but I did not dive into it yet.
As Kay mentions: using cmake to compile lux makes it now much easier.
> Doesn't compiling something to use static libs also include everything
> inside the app?
It, does, but it produces enormous bloat. And if anything relevant in
one of the libraries changes, you have to recompile, redistribute, and
make all users reinstall. Linux has decided against this, and for good
reasons.
Yeah, well.
With a statically compiled binary you have everything in there that end users do not have on their system. So that's more space effective. For developers it is of course not, but they are less than 0,01% once a package really gets used by an end community.
An AppImage or Flatpack is squash compressed. It delivers a 13~15MB release.
Upon starting it is uncompressed to a tmp folder and is then ~40MB (and actually that should even be slightly larger with the extra patching). This tmp folder is of course removed when you close the app.
When I compile lux on Debian, it is 18MB (!) and that is with uncompressed libraries even more.
So actually a static binary or an AppImage or Flatpack (never did that one) is actually more space effective "all the time" for end users. And only when running the AppImage it temporarily takes slightly more space. Especially for those users who do not have the development installed, a static binary or AppImage is more space effective.
On the other hand: Who cares nowadays with bigger SDs?
My camera makes 14MB images and if I bulk shoot I have even up to 200MB of images for one sequence. A day of "bird shooting" gives me often 3~5 GB of images/videos (and afterwards mostly less than 1~2% remains).
4K movies from my camera are 250MB to >1GB (and I'm not even talking about persons who download movies or series up to 30GB)
So who cares whether an app is 18MB (uncompressed lux), 13MB (compressed app image) or 35MB?
I do think that AppImages (and Flatpacks) are indeed the way forward now that Linux more and more gets an "end user" platform.
Next to that: I do have a Chromebook with Linux Beta on it. Every user can install that. I use it all the time (I hate fans in my laptops) and do all my development on that Chromebook in Linux Beta.
The java app images I make and lux debs I make can simply be installed in that Linux beta (by default Debian but you can install any major distro).
If Chomebook users (considering them even more as end users) start to use AppImages in Linux beta, makes it even more attractive to use these.
But that's my personal view.
Harry
Kay F. Jahnke
Jun 8, 2021, 12:50:42 PM6/8/21
to hugi...@googlegroups.com
Building on Frederic da Vitoria's initial version, I've put together a
script file for inno setup (see https://jrsoftware.org/isinfo.php) which
can create a windows-10-compatible installer for lux. The .iss file can
be found in the 'scripts' section. If my information is correct,
extension associations can't be changed in W10 by checking the relevant
boxes in the installer, instead the extension associations are presented
as an offer when a file with the associated extension is first
doubleclicked - so I removed these entries from the installer's dialog box.
The installer will install an association to the .lux extension which
I'm moving to (from .ini which is still valid) and lux will be offered
as standard app for several image types (jpg, tif, .png, .bmp, .exr) and
for .pto files. It's likely that a windows system doesn't have
associations for some of these extensions (especially .pto, .lux and
.exr), in which case the doubleclick should even work without the dialog.
Lux may be installed user-only or all-users (which requires admin
privileges) and optionally a desktop icon can be installed. That's about
it for functionality. I built an installer for lux 1.0.9, which you can
find here:
https://bitbucket.org/kfj/pv/downloads/lux_1.0.9_setup.exe
To uninstall, use the system settings 'Apps' subsection and look for
'lux', which will also remove all extension associations.
Thanks, Frederic, for doing the initial work and starting the process of
building the installer with inno setup - apart from the bother with the
changed extension associations under W10, which I finally found
explained in the FAQ, I pretty much took over your initial work, with
added header for licensing and copyright and a few adaptations to the
folder structure o my system. Would you like to be put in as author as
well? If so, please indicate how I should mention you.
Kay
script file for inno setup (see https://jrsoftware.org/isinfo.php) which
can create a windows-10-compatible installer for lux. The .iss file can
be found in the 'scripts' section. If my information is correct,
extension associations can't be changed in W10 by checking the relevant
boxes in the installer, instead the extension associations are presented
as an offer when a file with the associated extension is first
doubleclicked - so I removed these entries from the installer's dialog box.
The installer will install an association to the .lux extension which
I'm moving to (from .ini which is still valid) and lux will be offered
as standard app for several image types (jpg, tif, .png, .bmp, .exr) and
for .pto files. It's likely that a windows system doesn't have
associations for some of these extensions (especially .pto, .lux and
.exr), in which case the doubleclick should even work without the dialog.
Lux may be installed user-only or all-users (which requires admin
privileges) and optionally a desktop icon can be installed. That's about
it for functionality. I built an installer for lux 1.0.9, which you can
find here:
https://bitbucket.org/kfj/pv/downloads/lux_1.0.9_setup.exe
To uninstall, use the system settings 'Apps' subsection and look for
'lux', which will also remove all extension associations.
Thanks, Frederic, for doing the initial work and starting the process of
building the installer with inno setup - apart from the bother with the
changed extension associations under W10, which I finally found
explained in the FAQ, I pretty much took over your initial work, with
added header for licensing and copyright and a few adaptations to the
folder structure o my system. Would you like to be put in as author as
well? If so, please indicate how I should mention you.
Kay
T. Modes
Jun 8, 2021, 1:17:02 PM6/8/21
to hugin and other free panoramic software
kfj schrieb am Dienstag, 8. Juni 2021 um 18:50:42 UTC+2:
It's likely that a windows system doesn't have
associations for some of these extensions (especially .pto, .lux and
.exr), in which case the doubleclick should even work without the dialog.
If Hugin installer is used, it register the pto files with Hugin.
I would appreciate if you would keep this association intact instead of unconditional overwrite it.
Frederic Da Vitoria
Jun 8, 2021, 3:22:11 PM6/8/21
to hugin-ptx
Le mar. 8 juin 2021 à 18:50, 'Kay F. Jahnke' via hugin and other free panoramic software <hugi...@googlegroups.com> a écrit :
Building on Frederic da Vitoria's initial version, I've put together a
script file for inno setup (see https://jrsoftware.org/isinfo.php) which
can create a windows-10-compatible installer for lux.
Er, sorry but no, I didn't do anything here, except answering when it was not really needed :-)
Frederic Da Vitoria
(davitof)
Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org
(davitof)
Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org
Kay F. Jahnke
Jun 9, 2021, 3:04:59 AM6/9/21
to hugi...@googlegroups.com
Am 08.06.21 um 19:17 schrieb T. Modes:
It doesn't. I think simply overwriting existing associations is no
longer possible with windows 10 - especially unconditional overwrites
simply aren't allowed anymore.
It was my impression that on Windows 10 a new association with an
extension results in a dialog when a file with this extension is next
doubleclicked, and the dialog offers the user to choose a new
association as the standard or keep the old one. Only if the association
was *not present previously*, the new program will open a file with this
extension when it's doubleclicked *without an intervening dialog*. When
I tested the installer, I saw this behaviour on my windows 10 pro 20H2
install. Did you actually test the installer and observe a different
behaviour? What system are you using?
My intention is to have this bahaviour: if the .pto extension is already
assigned (like, to hugin), and lux is installed afterwards, the first
doubleclick on a .pto after the installation of lux should result in a
dialog which offers the user to keep this association or change it to
another candidate. After the choice is made, the next time someone
doubleclicks on a .pto, it's opened with the application the user has
selected. I think this is perfectly reasonable. Other Windows users,
please comment.
Thomas, you're good with windows. Why don't you help lux along? It would
be easy for you the help make the installer do precisely the right
thing, you know about stuff like the registry, which is alien to me as a
linux person. I've published the .iss script on bitbucket, and if you
find fault with it, why don't you change it? You can send in a patch,
and I'll consider it - and so can everyone else. The file is in the
scripts section:
https://bitbucket.org/kfj/pv/src/master/scripts/lux_setup.iss
If you have a better idea for an installer, you're also very welcome. I
did consider nullsoft, because I could use cpack's NSIS module, it's
only that Frederico came up with the inno setup idea, and it's an
independent project, I liked the script-driven approach, so I went along
with the suggestion. I do in fact prefer my own 'bundles' which are
stickware and require no installation, but you know how windows users are...
Try lux - it's really a very nice program! You don't have to use it for
stitching or exposure fusion or focus stacking or deghosting - all the
synoptic work is optional. Primarily it's an image and panorama
*viewer*. It makes an ideal companion for hugin, but it's new technology
makes it hard to give stuff back to hugin and panotools. I'm not trying
to take anything away from the hugin project - it's just that I don't
get much help or feedback from the hugin project, so I go ahead best as
I can. I tried to get the people on hugin-ptx interested in my program,
even when it was in it's early stages of development. My postings were
usually quickly shot down with something someone did not like about it,
then the threads died down and my effort was ignored for another year or
two until I tried again. What was I supposed to do but carry on
developing as I saw fit? I'd much rather have someone else doing the
windows builds and installers, but even though Frederico started the
.iss for inno setup, it's ended up with me again to make it run okay. I
bet you know how it is if one has to do just about everything.
Here's the code for the .pto association in the .iss script:
Root: HKA; Subkey: "Software\Classes\.pto\OpenWithProgids"; ValueType:
string; ValueName: "{#MyAppName}.pto"; ValueData: ""; Flags:
uninsdeletevalue
Root: HKA; Subkey: "Software\Classes\{#MyAppName}.pto"; ValueType:
string; ValueName: ""; ValueData: "Lux Panorama Viewer"; Flags:
uninsdeletekey
Root: HKA; Subkey: "Software\Classes\{#MyAppName}.pto\DefaultIcon";
ValueType: string; ValueName: ""; ValueData: "{app}\{#MyAppIconName},0"
Root: HKA; Subkey:
"Software\Classes\{#MyAppName}.pto\shell\open\command"; ValueType:
string; ValueName: ""; ValueData: """{app}\{#MyAppExeName}"" ""%1"""
Root: HKA; Subkey:
"Software\Classes\Applications\{#MyAppExeName}\SupportedTypes";
ValueType: string; ValueName: ".pto"; ValueData: ""
Note the OpenWithProgids registry entry: if I understand this correctly,
it has a list of several applications which can handle the extension.
This is different from the old code, where one could simply overwrite
the relevant registry key(s) to force a new association. I think the new
mode is a compromise: it allows programs to register their extensions to
be immediately effective (like .lux, or .pto when it's not been
associated previously) and still protects existing associations by *only
offering the choice to change* when the extension was already associated.
Kay
longer possible with windows 10 - especially unconditional overwrites
simply aren't allowed anymore.
It was my impression that on Windows 10 a new association with an
extension results in a dialog when a file with this extension is next
doubleclicked, and the dialog offers the user to choose a new
association as the standard or keep the old one. Only if the association
was *not present previously*, the new program will open a file with this
extension when it's doubleclicked *without an intervening dialog*. When
I tested the installer, I saw this behaviour on my windows 10 pro 20H2
install. Did you actually test the installer and observe a different
behaviour? What system are you using?
My intention is to have this bahaviour: if the .pto extension is already
assigned (like, to hugin), and lux is installed afterwards, the first
doubleclick on a .pto after the installation of lux should result in a
dialog which offers the user to keep this association or change it to
another candidate. After the choice is made, the next time someone
doubleclicks on a .pto, it's opened with the application the user has
selected. I think this is perfectly reasonable. Other Windows users,
please comment.
Thomas, you're good with windows. Why don't you help lux along? It would
be easy for you the help make the installer do precisely the right
thing, you know about stuff like the registry, which is alien to me as a
linux person. I've published the .iss script on bitbucket, and if you
find fault with it, why don't you change it? You can send in a patch,
and I'll consider it - and so can everyone else. The file is in the
scripts section:
https://bitbucket.org/kfj/pv/src/master/scripts/lux_setup.iss
If you have a better idea for an installer, you're also very welcome. I
did consider nullsoft, because I could use cpack's NSIS module, it's
only that Frederico came up with the inno setup idea, and it's an
independent project, I liked the script-driven approach, so I went along
with the suggestion. I do in fact prefer my own 'bundles' which are
stickware and require no installation, but you know how windows users are...
Try lux - it's really a very nice program! You don't have to use it for
stitching or exposure fusion or focus stacking or deghosting - all the
synoptic work is optional. Primarily it's an image and panorama
*viewer*. It makes an ideal companion for hugin, but it's new technology
makes it hard to give stuff back to hugin and panotools. I'm not trying
to take anything away from the hugin project - it's just that I don't
get much help or feedback from the hugin project, so I go ahead best as
I can. I tried to get the people on hugin-ptx interested in my program,
even when it was in it's early stages of development. My postings were
usually quickly shot down with something someone did not like about it,
then the threads died down and my effort was ignored for another year or
two until I tried again. What was I supposed to do but carry on
developing as I saw fit? I'd much rather have someone else doing the
windows builds and installers, but even though Frederico started the
.iss for inno setup, it's ended up with me again to make it run okay. I
bet you know how it is if one has to do just about everything.
Here's the code for the .pto association in the .iss script:
Root: HKA; Subkey: "Software\Classes\.pto\OpenWithProgids"; ValueType:
string; ValueName: "{#MyAppName}.pto"; ValueData: ""; Flags:
uninsdeletevalue
Root: HKA; Subkey: "Software\Classes\{#MyAppName}.pto"; ValueType:
string; ValueName: ""; ValueData: "Lux Panorama Viewer"; Flags:
uninsdeletekey
Root: HKA; Subkey: "Software\Classes\{#MyAppName}.pto\DefaultIcon";
ValueType: string; ValueName: ""; ValueData: "{app}\{#MyAppIconName},0"
Root: HKA; Subkey:
"Software\Classes\{#MyAppName}.pto\shell\open\command"; ValueType:
string; ValueName: ""; ValueData: """{app}\{#MyAppExeName}"" ""%1"""
Root: HKA; Subkey:
"Software\Classes\Applications\{#MyAppExeName}\SupportedTypes";
ValueType: string; ValueName: ".pto"; ValueData: ""
Note the OpenWithProgids registry entry: if I understand this correctly,
it has a list of several applications which can handle the extension.
This is different from the old code, where one could simply overwrite
the relevant registry key(s) to force a new association. I think the new
mode is a compromise: it allows programs to register their extensions to
be immediately effective (like .lux, or .pto when it's not been
associated previously) and still protects existing associations by *only
offering the choice to change* when the extension was already associated.
Kay
T. Modes
Jun 10, 2021, 1:18:11 PM6/10/21
to hugin and other free panoramic software
kfj schrieb am Mittwoch, 9. Juni 2021 um 09:04:59 UTC+2:
My intention is to have this bahaviour: if the .pto extension is already
assigned (like, to hugin), and lux is installed afterwards, the first
doubleclick on a .pto after the installation of lux should result in a
dialog which offers the user to keep this association or change it to
another candidate. After the choice is made, the next time someone
doubleclicks on a .pto, it's opened with the application the user has
selected. I think this is perfectly reasonable. Other Windows users,
please comment.
Hugin registers 2 verbs for pto files: open and stitch.
I don't how this interacts with the OpenWithProgID. But this may be a reasonable approach.
Thomas, you're good with windows. Why don't you help lux along? It would
be easy for you the help make the installer do precisely the right
thing, you know about stuff like the registry, which is alien to me as a
linux person. I've published the .iss script on bitbucket, and if you
find fault with it, why don't you change it? You can send in a patch,
and I'll consider it - and so can everyone else. The file is in the
scripts section:
https://bitbucket.org/kfj/pv/src/master/scripts/lux_setup.iss
Sorry, but I don't have experience with this scripts. So I can't help here.
I tested Lux again, but it does not match in my workflow.
When opening a pto file it is slower and takes more memory than Hugins preview. So I'm faster with Hugin.
Also I don't like the self written interface - but that's a matter of taste.
Kay F. Jahnke
Jun 11, 2021, 3:59:10 AM6/11/21
to hugi...@googlegroups.com
Am 10.06.21 um 19:18 schrieb T. Modes:
explain? what are 'verbs' in this context? And with what are they
registered?
> I don't how this interacts with the OpenWithProgID. But this may be a
> reasonable approach.
I think that the installer behaves like I intend (see above). Can you
please confirm that it does not unconditionally overwrite any existing
associations? If it does, something is wrong and I'll have to change it.
> Thomas, you're good with windows. Why don't you help lux along? It
> would
> be easy for you the help make the installer do precisely the right
> thing, you know about stuff like the registry, which is alien to me
> as a
> linux person. I've published the .iss script on bitbucket, and if you
> find fault with it, why don't you change it? You can send in a patch,
> and I'll consider it - and so can everyone else. The file is in the
> scripts section:
>
> https://bitbucket.org/kfj/pv/src/master/scripts/lux_setup.iss
> <https://bitbucket.org/kfj/pv/src/master/scripts/lux_setup.iss>
>
>
> Sorry, but I don't have experience with this scripts. So I can't help here.
But it's easy! You can help, and it's no big deal. The section of the
script which deals with the extension associations merely modifies the
registry. For lux and the .pto extension, this is what happens:
Root: HKA; Subkey: "Software\Classes\.pto\OpenWithProgids"; ValueType:
string; ValueName: "{#MyAppName}.pto"; ValueData: ""; Flags:
uninsdeletevalue
Root: HKA; Subkey: "Software\Classes\{#MyAppName}.pto"; ValueType:
string; ValueName: ""; ValueData: "Lux Panorama Viewer"; Flags:
uninsdeletekey
Root: HKA; Subkey: "Software\Classes\{#MyAppName}.pto\DefaultIcon";
ValueType: string; ValueName: ""; ValueData: "{app}\{#MyAppIconName},0"
Root: HKA; Subkey:
"Software\Classes\{#MyAppName}.pto\shell\open\command"; ValueType:
string; ValueName: ""; ValueData: """{app}\{#MyAppExeName}"" ""%1"""
Root: HKA; Subkey:
"Software\Classes\Applications\{#MyAppExeName}\SupportedTypes";
ValueType: string; ValueName: ".pto"; ValueData: ""
This is plain registry modification, to clarify, I'll 'decode' the first
line for you:
Root: HKA; Subkey: "Software\Classes\.pto\OpenWithProgids"; ValueType:
string; ValueName: "{#MyAppName}.pto"; ValueData: ""; Flags:
uninsdeletevalue
This means:
set HKA's subkey Software\Classes\.pto\OpenWithProgids to contain the
string "Lux Panorama Viewer.pto" and remove it when lux is uninstalled
And, to be less verbose: The second and third one merely register the
app name and icon for the association, the fourth one specifies how to
invoke the executable and the fifth one says that lux does support .pto
files.
So the five lines doing the extension association (as MS suggests it for
W10) are easy to understand: they make a few registry changes. AFAICT
the changes do not 'step on hugin's toes', and this is where you could
help: just look at the registry changes and give me your opinion.
> I tested Lux again, but it does not match in my workflow.
Fair enough.
> When opening a pto file it is slower and takes more memory than Hugins
> preview. So I'm faster with Hugin.
That observation is correct. In order to provide smooth animation, lux
uses interpolators which take up a lot of memory and take time to build.
There are a few flags to lower memory consumption, but especially for
views taking in several images (like, from .pto files), memory
consumption and setup time can be high.
I tried to address your criticism that lux is unresponsive during
startup - now you get the splash screen and the status line tells you
what is loaded and built, and if you lose patience, you can press
'Escape' and it will stop and terminate after processing the current
partial image. So now you can interact (if drastically) and you aren't
confronted with an unresponsive program and a white screen during startup.
Let me remind you: you shouldn't really compare lux to hugin in that
respect: lux is primarily a panorama *viewer*. It has some capabilities
to deal with .pto files, but it really shines where you have a
ready-made panorama to display, like a single full spherical. I made it
to *look at* panoramas. That it can also make panoramas is a new
sideline, which you can simply ignore for now. So stitch your panorama
with hugin/nona/enblend, then *look at the result* with lux.
Lux has capabilites of nona and enfuse and enblend built-in, and to
provide all this capability in one application takes more resources than
hugin's approach of delegating most tasks to external programs: cpfind,
nona, enfuse, enblend, PTBatcher - and then leaving it to the user to
find a panorama viewer to look at the result.
> Also I don't like the self written interface - but that's a matter of taste.
Again, fair enough. I think you refer to the GUI with it's three rows of
buttons. That is indeed not my favourite part either, it's more of a
gate-opener to the 'proper' way of using lux, which is with the keyboard
and with mouse gestures. You get hints to the keys and gestures by
right-click-holding the buttons. Navigation in the image is like QTVR,
so this should be intuitive. When it comes to stitching and fusing, my
GUI admittedly doesn't help much as it is.
Using a small hand-written immediate mode GUI has the advantage of
needing fewer dependencies and producing a smaller executable, but of
course it's hard to produce a user experience similar to what you get
from a well-made wxwidgets or Qt GUI. Internally, all actions are
relayed via small single-purpose functions, which could easily be
triggered from a different coordinating process.
Kay
>
>
> kfj schrieb am Mittwoch, 9. Juni 2021 um 09:04:59 UTC+2:
>
>
> My intention is to have this bahaviour: if the .pto extension is
> already
> assigned (like, to hugin), and lux is installed afterwards, the first
> doubleclick on a .pto after the installation of lux should result in a
> dialog which offers the user to keep this association or change it to
> another candidate. After the choice is made, the next time someone
> doubleclicks on a .pto, it's opened with the application the user has
> selected. I think this is perfectly reasonable. Other Windows users,
> please comment.
>
>
> Hugin registers 2 verbs for pto files: open and stitch.
I don't understand what you mean by 'registers 2 verbs', can you please
>
> kfj schrieb am Mittwoch, 9. Juni 2021 um 09:04:59 UTC+2:
>
>
> My intention is to have this bahaviour: if the .pto extension is
> already
> assigned (like, to hugin), and lux is installed afterwards, the first
> doubleclick on a .pto after the installation of lux should result in a
> dialog which offers the user to keep this association or change it to
> another candidate. After the choice is made, the next time someone
> doubleclicks on a .pto, it's opened with the application the user has
> selected. I think this is perfectly reasonable. Other Windows users,
> please comment.
>
>
> Hugin registers 2 verbs for pto files: open and stitch.
explain? what are 'verbs' in this context? And with what are they
registered?
> I don't how this interacts with the OpenWithProgID. But this may be a
> reasonable approach.
please confirm that it does not unconditionally overwrite any existing
associations? If it does, something is wrong and I'll have to change it.
> Thomas, you're good with windows. Why don't you help lux along? It
> would
> be easy for you the help make the installer do precisely the right
> thing, you know about stuff like the registry, which is alien to me
> as a
> linux person. I've published the .iss script on bitbucket, and if you
> find fault with it, why don't you change it? You can send in a patch,
> and I'll consider it - and so can everyone else. The file is in the
> scripts section:
>
> https://bitbucket.org/kfj/pv/src/master/scripts/lux_setup.iss
> <https://bitbucket.org/kfj/pv/src/master/scripts/lux_setup.iss>
>
>
> Sorry, but I don't have experience with this scripts. So I can't help here.
script which deals with the extension associations merely modifies the
registry. For lux and the .pto extension, this is what happens:
Root: HKA; Subkey: "Software\Classes\.pto\OpenWithProgids"; ValueType:
string; ValueName: "{#MyAppName}.pto"; ValueData: ""; Flags:
uninsdeletevalue
Root: HKA; Subkey: "Software\Classes\{#MyAppName}.pto"; ValueType:
string; ValueName: ""; ValueData: "Lux Panorama Viewer"; Flags:
uninsdeletekey
Root: HKA; Subkey: "Software\Classes\{#MyAppName}.pto\DefaultIcon";
ValueType: string; ValueName: ""; ValueData: "{app}\{#MyAppIconName},0"
Root: HKA; Subkey:
"Software\Classes\{#MyAppName}.pto\shell\open\command"; ValueType:
string; ValueName: ""; ValueData: """{app}\{#MyAppExeName}"" ""%1"""
Root: HKA; Subkey:
"Software\Classes\Applications\{#MyAppExeName}\SupportedTypes";
ValueType: string; ValueName: ".pto"; ValueData: ""
line for you:
Root: HKA; Subkey: "Software\Classes\.pto\OpenWithProgids"; ValueType:
string; ValueName: "{#MyAppName}.pto"; ValueData: ""; Flags:
uninsdeletevalue
set HKA's subkey Software\Classes\.pto\OpenWithProgids to contain the
string "Lux Panorama Viewer.pto" and remove it when lux is uninstalled
And, to be less verbose: The second and third one merely register the
app name and icon for the association, the fourth one specifies how to
invoke the executable and the fifth one says that lux does support .pto
files.
So the five lines doing the extension association (as MS suggests it for
W10) are easy to understand: they make a few registry changes. AFAICT
the changes do not 'step on hugin's toes', and this is where you could
help: just look at the registry changes and give me your opinion.
> I tested Lux again, but it does not match in my workflow.
> When opening a pto file it is slower and takes more memory than Hugins
> preview. So I'm faster with Hugin.
uses interpolators which take up a lot of memory and take time to build.
There are a few flags to lower memory consumption, but especially for
views taking in several images (like, from .pto files), memory
consumption and setup time can be high.
I tried to address your criticism that lux is unresponsive during
startup - now you get the splash screen and the status line tells you
what is loaded and built, and if you lose patience, you can press
'Escape' and it will stop and terminate after processing the current
partial image. So now you can interact (if drastically) and you aren't
confronted with an unresponsive program and a white screen during startup.
Let me remind you: you shouldn't really compare lux to hugin in that
respect: lux is primarily a panorama *viewer*. It has some capabilities
to deal with .pto files, but it really shines where you have a
ready-made panorama to display, like a single full spherical. I made it
to *look at* panoramas. That it can also make panoramas is a new
sideline, which you can simply ignore for now. So stitch your panorama
with hugin/nona/enblend, then *look at the result* with lux.
Lux has capabilites of nona and enfuse and enblend built-in, and to
provide all this capability in one application takes more resources than
hugin's approach of delegating most tasks to external programs: cpfind,
nona, enfuse, enblend, PTBatcher - and then leaving it to the user to
find a panorama viewer to look at the result.
> Also I don't like the self written interface - but that's a matter of taste.
buttons. That is indeed not my favourite part either, it's more of a
gate-opener to the 'proper' way of using lux, which is with the keyboard
and with mouse gestures. You get hints to the keys and gestures by
right-click-holding the buttons. Navigation in the image is like QTVR,
so this should be intuitive. When it comes to stitching and fusing, my
GUI admittedly doesn't help much as it is.
Using a small hand-written immediate mode GUI has the advantage of
needing fewer dependencies and producing a smaller executable, but of
course it's hard to produce a user experience similar to what you get
from a well-made wxwidgets or Qt GUI. Internally, all actions are
relayed via small single-purpose functions, which could easily be
triggered from a different coordinating process.
Kay
Kay F. Jahnke
Jun 23, 2021, 5:14:22 AM6/23/21
to hugi...@googlegroups.com
Dear all!
I'm happy with the level of functionality in lux 1.0.9, and since I've
seen no complaints - either here or as issues on the bitbucket page - I
can only assume that lux users agree ;)
I'm now taking the time to consolidate: I'm going through the various
options (as represented by command line arguments), looking at each in
turn, trying out whether they (still) work as intended, debugging as I
go along, and producing more documentation. I have started on a new HTML
document, which gives a lexical listing of lux options - rather than the
more thematic grouping in the README file - and this is progressing
nicely and has already reached the letter 'F'. You can find the source
code of this document as restructured text in the repo, and an HTML
rendition on my bitbucket.io page:
https://kfj.bitbucket.io/lux_options.html
I'll update the HTML version as lux_options.rst grows. I thought it a
good idea to announce this text early, and I'd like to invite you to
have a look at the text, and to comment on it - especially if I don't
make sense or use my own jargon - as a developer, I may have come to use
terms which make sense for me, but aren't comprehensible without
explanation.
Kay
I'm happy with the level of functionality in lux 1.0.9, and since I've
seen no complaints - either here or as issues on the bitbucket page - I
can only assume that lux users agree ;)
I'm now taking the time to consolidate: I'm going through the various
options (as represented by command line arguments), looking at each in
turn, trying out whether they (still) work as intended, debugging as I
go along, and producing more documentation. I have started on a new HTML
document, which gives a lexical listing of lux options - rather than the
more thematic grouping in the README file - and this is progressing
nicely and has already reached the letter 'F'. You can find the source
code of this document as restructured text in the repo, and an HTML
rendition on my bitbucket.io page:
https://kfj.bitbucket.io/lux_options.html
I'll update the HTML version as lux_options.rst grows. I thought it a
good idea to announce this text early, and I'd like to invite you to
have a look at the text, and to comment on it - especially if I don't
make sense or use my own jargon - as a developer, I may have come to use
terms which make sense for me, but aren't comprehensible without
explanation.
Kay
kfj
Jul 5, 2021, 4:35:35 AM7/5/21
to hugin and other free panoramic software
Dear all!
I've made an intermediate release of lux with a few bug fixes and changes to the docu which have accrued during the past few weeks, during my 'grooming' session, which will continue until the release of lux 1.1.0. The intermediate release has version lux_1.0.9a, downloadable binaries can be found in the Downloads section of the bitbucket repo:
And the README in HTML format was also updated:
The windows installer has seen some work (thanks, Bernd!):
- it's less obtrusive, per default, lux is not launched after installation
- for several extensions, lux can now be chosen as target via the context menu
- SendTo can be used to invoke lux with a selection from the explorer
Kay
kfj
Oct 13, 2021, 4:29:39 AM10/13/21
to hugin and other free panoramic software
Before committing to 1.1.0, I have decided to release another lux binary in the 1.0.9 series, because I have put quite some work into lux since 1.0.9a and I'd like to have the software in use for some time to see if any bugs crop up. My 'grooming session' is now done, and I have documented all options in lux_options.html. Find new binaries on my bitbucket site's download page:
portable windows version: https://bitbucket.org/kfj/pv/downloads/lux_for_windows_1.0.9b.zip
windows installer: https://bitbucket.org/kfj/pv/downloads/lux_1.0.9b_setup.exe
debian package: https://bitbucket.org/kfj/pv/downloads/lux-1.0.9b-amd64.deb
So, what's new? Casual users likely won't notice any changes - the focus is more on ironing out bugs and glitches. lux is complex software, and sometimes changes in one part affect other parts in unwanted ways - for example, the comic book mode went dysfunctional, because I changed the semantics of the initial_dx and initial_dy options (that's fixed now).
The truly new features are quite 'specialist': it's about creating image pyramids, which are central to both the viewer and the lux version of the Burt and Adelson image splining algorithm. What I added here are new low-pass filters which are used to create a pyramid level from the level 'below' it. Until now, lux was using b-spline reconstruction kernels, 'area' decimation and a small binomial (.25, .5, .25). Now I added the next odd binomial, an 'optimal' Burt filter, and FIR half-band filters based on a truncated sinc with a Hamming window, as explained here:
The filters are used in a 'convolving basis functor', a hybrid between b-spline evaluation and FIR filter which allows off-grid access. They require a spline pyramid to operate on, which makes the pyramid building code a bit slower. Especially these filters should provide near-optimal results - for more on the topic, please visit the documentation - or discuss it here! Visibly, the change is hard to detect, because lux' image pyramids were pretty good as they were. If you want to give it a try, invoke lux with --pyramid_smoothing_level=-7 for a 7-tap half-band or -11 for an 11-tap half-band etc. (the half-band filters lux uses have tap counts of 4N-1). If you (optionally) combine that with --decimate_area=yes and zoom out (start with 1:1 magnification by pressing '1', then zoom out) the resulting animation should be practically free from pyramid level switching artifacts.
One more bit of good news: I finally managed to find someone who has a recent intel core-i processor which offers the AVX512 instruction set, and managed to talk him into running lux on it. And, lo and behold, the AVX512 capability was detected and the AVX512-specific code used! So far I have no idea if there is a significant performance gain from using the new ISA. but I suspect that the doubled register size vs. AVX2 should make a fair difference, because a lot of lux code is running in the registers rather than accessing RAM. Any of you out there with AVX-512 capable processors, please check it out!
Kay
David W. Jones
Oct 14, 2021, 4:25:55 AM10/14/21
to hugin-ptx
Tried to install the DEB package on Debian Buster (Debian 10) on my
laptop because it's the only machine in the house with real graphics
hardware (NVidia).
Got these results:
Preparing to unpack lux-1.0.9a-amd64.deb ...
versions of libc6) doesn't have real graphics hardware in it (just the
old Intel glorified framebuffer).
On 10/12/21 10:29 PM, 'kfj' via hugin and other free panoramic software
wrote:
> <https://bitbucket.org/kfj/pv/downloads/lux-1.0.9a-amd64.deb>
> https://bitbucket.org/kfj/pv/downloads/lux_1.0.9a_setup.exe
> <https://bitbucket.org/kfj/pv/downloads/lux_1.0.9a_setup.exe>
> https://bitbucket.org/kfj/pv/downloads/lux_for_windows_1.0.9a.zip
> rendition on my bitbucket.io <http://bitbucket.io> page:
>
> https://kfj.bitbucket.io/lux_options.html
laptop because it's the only machine in the house with real graphics
hardware (NVidia).
Got these results:
Preparing to unpack lux-1.0.9a-amd64.deb ...
Unpacking lux (1.0.9-0git) ...
dpkg: dependency problems prevent configuration of lux:
lux depends on libc6 (>= 2.29); however:
Version of libc6:amd64 on system is 2.28-10.
lux depends on libexiv2-27 (>= 0.25); however:
Package libexiv2-27 is not installed.
lux depends on libgcc-s1 (>= 4.0); however:
Package libgcc-s1 is not installed.
lux depends on libstdc++6 (>= 9); however:
Version of libstdc++6:amd64 on system is 8.3.0-6.
lux depends on libvigraimpex11 (>= 1.11.1+dfsg); however:
Package libvigraimpex11 is not installed.
dpkg: error processing package lux (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
lux
The machine that's running Debian 11 (which presumably has newer
dpkg: dependency problems prevent configuration of lux:
lux depends on libc6 (>= 2.29); however:
Version of libc6:amd64 on system is 2.28-10.
lux depends on libexiv2-27 (>= 0.25); however:
Package libexiv2-27 is not installed.
lux depends on libgcc-s1 (>= 4.0); however:
Package libgcc-s1 is not installed.
lux depends on libstdc++6 (>= 9); however:
Version of libstdc++6:amd64 on system is 8.3.0-6.
lux depends on libvigraimpex11 (>= 1.11.1+dfsg); however:
Package libvigraimpex11 is not installed.
dpkg: error processing package lux (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
lux
versions of libc6) doesn't have real graphics hardware in it (just the
old Intel glorified framebuffer).
On 10/12/21 10:29 PM, 'kfj' via hugin and other free panoramic software
wrote:
> https://bitbucket.org/kfj/pv/downloads/lux_1.0.9a_setup.exe
> <https://bitbucket.org/kfj/pv/downloads/lux_1.0.9a_setup.exe>
> https://bitbucket.org/kfj/pv/downloads/lux_for_windows_1.0.9a.zip
>
> https://kfj.bitbucket.io/lux_options.html
> <https://kfj.bitbucket.io/lux_options.html>
>
> I'll update the HTML version as lux_options.rst grows. I thought
> it a
> good idea to announce this text early, and I'd like to invite
> you to
> have a look at the text, and to comment on it - especially if I
> don't
> make sense or use my own jargon - as a developer, I may have
> come to use
> terms which make sense for me, but aren't comprehensible without
> explanation.
>
> Kay
>
> I'll update the HTML version as lux_options.rst grows. I thought
> it a
> good idea to announce this text early, and I'd like to invite
> you to
> have a look at the text, and to comment on it - especially if I
> don't
> make sense or use my own jargon - as a developer, I may have
> come to use
> terms which make sense for me, but aren't comprehensible without
> explanation.
>
> Kay
Kay F. Jahnke
Oct 14, 2021, 4:52:39 AM10/14/21
to hugi...@googlegroups.com
Am 14.10.21 um 10:25 schrieb David W. Jones:
> Tried to install the DEB package on Debian Buster (Debian 10) on my
> laptop because it's the only machine in the house with real graphics
> hardware (NVidia).
We've had these problems before with your debian11. Really, the .deb
package is for ubuntu - I use 20.04 LTS. Re. debian11 you posted on Jun
5, 2021, 11:25:05 AM, on this thread, and Harry responded with this
proposition:
***** begin quote
This happens more often with manually installing debian packages.
So you do a "sudo dpkg -i lux-<version>.dpkg" and get this error.
What you now should do is a:
"sudo dpkg --configure -a"
followed by:
"sudo apt-get -f install"
That should fix it.
***** end quote
Did that work for you last time around? If so, maybe try it again.
BTW - you don't need special graphics hardware, because lux is
CPU-based. GPU load is not very large, processor graphics will usually
suffice. What you *do* want is a reasonably powerful CPU - I'd recommend
four cores and AVX2 or better.
If you don't get the .deb to install, please compile from source. lux
now uses cmake, and the build process is simple, just follow the
instructions on the bitbucket page (find the chapter 'Building lux on a
debian-based system')
Kay
> Tried to install the DEB package on Debian Buster (Debian 10) on my
> laptop because it's the only machine in the house with real graphics
> hardware (NVidia).
package is for ubuntu - I use 20.04 LTS. Re. debian11 you posted on Jun
5, 2021, 11:25:05 AM, on this thread, and Harry responded with this
proposition:
***** begin quote
This happens more often with manually installing debian packages.
So you do a "sudo dpkg -i lux-<version>.dpkg" and get this error.
What you now should do is a:
"sudo dpkg --configure -a"
followed by:
"sudo apt-get -f install"
That should fix it.
Did that work for you last time around? If so, maybe try it again.
BTW - you don't need special graphics hardware, because lux is
CPU-based. GPU load is not very large, processor graphics will usually
suffice. What you *do* want is a reasonably powerful CPU - I'd recommend
four cores and AVX2 or better.
If you don't get the .deb to install, please compile from source. lux
now uses cmake, and the build process is simple, just follow the
instructions on the bitbucket page (find the chapter 'Building lux on a
debian-based system')
Kay
Luís Henrique Camargo Quiroz
Oct 14, 2021, 9:55:49 AM10/14/21
to hugi...@googlegroups.com
HI,
For information, I just installed lux-1.0.9b-amd64.deb (via dpkg -i) in Debian 12 (testing) and it went flawlessly.
As a side note, I should try to use lux more times, but I lack the needed free time. However the quality of the visualization really could help to spot misalignments, and so this effectively help to place better/missing CPs and have a better panorama as a result.
So, thanks to Kay for this tool!
sincerely,
Luís Henrique
--
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/22b15541-cc6f-ebf2-2ec6-b293e78cdba1%40yahoo.com.
--
--
Luis Henrique Camargo Quiroz
http://luishcq.br.tripod.com - http://www.christusrex.org/www2/cantgreg
http://panoramaslh.net/
Luis Henrique Camargo Quiroz
http://luishcq.br.tripod.com - http://www.christusrex.org/www2/cantgreg
http://panoramaslh.net/
David W. Jones
Oct 14, 2021, 11:30:12 PM10/14/21
to hugin-ptx
Thanks. I might try compile from source, just to see if it works. I
don't feel like jumping to Debian Testing just for lux.
On 10/13/21 10:52 PM, 'Kay F. Jahnke' via hugin and other free panoramic
don't feel like jumping to Debian Testing just for lux.
On 10/13/21 10:52 PM, 'Kay F. Jahnke' via hugin and other free panoramic
Reply all
Reply to author
Forward
0 new messages