lux FOSS panorama and image viewer: 1.1.0 pre-release available
64 views
Skip to first unread message
kfj
Feb 28, 2022, 5:54:28 AM2/28/22
to hugin and other free panoramic software
Dear all!
It's been a while since I have released new binaries! So today I'm offering binaries of a development snapshot which has - roughly - the feature level which I intend for lux 1.1.0.
Development has been intense - I rewrote a lot of code in the rendering engine, switching processing to associated alpha RGB pixel pipelines, which are better suited to deal with interpolation and masking. These code chages did mostly affect the processing of synoptic data (stitching, exposure fusions), but 'ordinary' image and panorama viewing should also benefit.
Probably the most important new features are processing of PTO files with source image cropping and masks (limited to exclude masks) - and processing of panoramas with stacks. My own panoramas make use of these features, and I found it frustrating that lux could not handle them, so I 'scratched my itch'.
I hope that this will make lux more useful for the community - give it a try, everything is set up to work with sensible defaults. To see masked and stacked panoramas on-screen will take a fair while. And lux is - as ever - memory-hungry in the default setting, so don't overdo the number/size of images in the panoramas. Snapshots are now done with the plain 'E' button for screen-sized snapshots and Shift+E for 'source-like' snapshots, and will automatically render panoramas/exposure fusions for data which are displayed as such, and there are more UI changes - I've tried to be conservative, but development goes on and the new features have to 'find room' somehow.
Find a debian package and a windows portable ZIP file here:
Robert Clausecker
Feb 28, 2022, 6:11:28 AM2/28/22
to hugi...@googlegroups.com
Hi!
I am interested in packaging this software for FreeBSD. Unfortunately,
we already have a package named lux (www/lux) in our Ports collection,
so I cannot name yours lux. What package name do you think would be
most appropriate?
Yours,
Robert Clausecker
Am Montag, dem 28.02.2022 um 02:54 -0800 schrieb 'kfj' via hugin and
other free panoramic software:
> --
> 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/4b723106-07ed-4fe5-87be-f2b54420d5aan%40googlegroups.com
> .
I am interested in packaging this software for FreeBSD. Unfortunately,
we already have a package named lux (www/lux) in our Ports collection,
so I cannot name yours lux. What package name do you think would be
most appropriate?
Yours,
Robert Clausecker
Am Montag, dem 28.02.2022 um 02:54 -0800 schrieb 'kfj' via hugin and
other free panoramic software:
> 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/4b723106-07ed-4fe5-87be-f2b54420d5aan%40googlegroups.com
> .
Kay F. Jahnke
Feb 28, 2022, 11:41:36 AM2/28/22
to hugi...@googlegroups.com
Am 28.02.22 um 12:11 schrieb Robert Clausecker:
> I am interested in packaging this software for FreeBSD. Unfortunately,
> we already have a package named lux (www/lux) in our Ports collection,
> so I cannot name yours lux. What package name do you think would be
> most appropriate?
How about lux-pv? For lux panorama viewer - that's if you're into short
package names. Or lux-viewer for something longer and less cryptic. But
bear in mind that what I've uploaded today is just a development
snapshot, so bear with me a little longer until I release 1.1.0 proper.
I just did a lot of internal rewiring, so it may take a while to settle.
The code is becoming fiendishly complex. I hope to see a bit of use and
maybe the odd bug report. Just viewing images and panoramas should be
unproblematic, though, because the changes were more to the PTO
processing part of the code.
Have you built the code on freeBSD already? I think this shouldn't be
too hard, with the CMake process and few dependencies. If you have,
please let me know - it would be the fourth OS running lux! I made the
.deb using CMake, maybe it can also build packages for freeBSD? By all
means, use the clang++ C++ compiler - so far it's made a big difference
speed-wise. And if you want to recreate today's binaries, they are made
from the associated_alpha branch, which I haven't merged back into
master yet.
Keep us posted on how it goes, thanks for your interest in lux!
Kay
> I am interested in packaging this software for FreeBSD. Unfortunately,
> we already have a package named lux (www/lux) in our Ports collection,
> so I cannot name yours lux. What package name do you think would be
> most appropriate?
package names. Or lux-viewer for something longer and less cryptic. But
bear in mind that what I've uploaded today is just a development
snapshot, so bear with me a little longer until I release 1.1.0 proper.
I just did a lot of internal rewiring, so it may take a while to settle.
The code is becoming fiendishly complex. I hope to see a bit of use and
maybe the odd bug report. Just viewing images and panoramas should be
unproblematic, though, because the changes were more to the PTO
processing part of the code.
Have you built the code on freeBSD already? I think this shouldn't be
too hard, with the CMake process and few dependencies. If you have,
please let me know - it would be the fourth OS running lux! I made the
.deb using CMake, maybe it can also build packages for freeBSD? By all
means, use the clang++ C++ compiler - so far it's made a big difference
speed-wise. And if you want to recreate today's binaries, they are made
from the associated_alpha branch, which I haven't merged back into
master yet.
Keep us posted on how it goes, thanks for your interest in lux!
Kay
Robert Clausecker
Feb 28, 2022, 11:45:12 AM2/28/22
to 'Kay F. Jahnke' via hugin and other free panoramic software
Hi Kay,
Am 28.02.22 um 17:41 schrieb 'Kay F. Jahnke' via hugin and other free panoramic software:
> Have you built the code on freeBSD already? I think this shouldn't be too hard, with the CMake process and few dependencies. If you have, please let me know - it would be the fourth OS running lux!
I have not made any attempts in this regard, but I want to start in the next few days. If I find any problems, I'll go ahead and report these to you so you can maybe add patches in time for the 1.1.0 release.
> I made the .deb using CMake, maybe it can also build packages for freeBSD? By all means, use the clang++ C++ compiler - so far it's made a big difference speed-wise. And if you want to recreate today's binaries, they are made from the associated_alpha branch, which I haven't merged back into master yet.
FreeBSD ports are compiled with the system's compiler, which is clang these days. The ports build system is external to the packages and hooks into your CMake build scripts, so no changes on your part will be required. I'll let you know once I get something done.
> Keep us posted on how it goes, thanks for your interest in lux!
>
> Kay
Yours,
Robert Clausecker
Am 28.02.22 um 17:41 schrieb 'Kay F. Jahnke' via hugin and other free panoramic software:
> Am 28.02.22 um 12:11 schrieb Robert Clausecker:
>
>> I am interested in packaging this software for FreeBSD. Unfortunately,
>> we already have a package named lux (www/lux) in our Ports collection,
>> so I cannot name yours lux. What package name do you think would be
>> most appropriate?
>
> How about lux-pv? For lux panorama viewer - that's if you're into short package names. Or lux-viewer for something longer and less cryptic. But bear in mind that what I've uploaded today is just a development snapshot, so bear with me a little longer until I release 1.1.0 proper. I just did a lot of internal rewiring, so it may take a while to settle. The code is becoming fiendishly complex. I hope to see a bit of use and maybe the odd bug report. Just viewing images and panoramas should be unproblematic, though, because the changes were more to the PTO processing part of the code.
lux-viewer sounds good. Will try that one.
>
>> I am interested in packaging this software for FreeBSD. Unfortunately,
>> we already have a package named lux (www/lux) in our Ports collection,
>> so I cannot name yours lux. What package name do you think would be
>> most appropriate?
>
> How about lux-pv? For lux panorama viewer - that's if you're into short package names. Or lux-viewer for something longer and less cryptic. But bear in mind that what I've uploaded today is just a development snapshot, so bear with me a little longer until I release 1.1.0 proper. I just did a lot of internal rewiring, so it may take a while to settle. The code is becoming fiendishly complex. I hope to see a bit of use and maybe the odd bug report. Just viewing images and panoramas should be unproblematic, though, because the changes were more to the PTO processing part of the code.
> Have you built the code on freeBSD already? I think this shouldn't be too hard, with the CMake process and few dependencies. If you have, please let me know - it would be the fourth OS running lux!
> I made the .deb using CMake, maybe it can also build packages for freeBSD? By all means, use the clang++ C++ compiler - so far it's made a big difference speed-wise. And if you want to recreate today's binaries, they are made from the associated_alpha branch, which I haven't merged back into master yet.
> Keep us posted on how it goes, thanks for your interest in lux!
>
> Kay
Robert Clausecker
Kay F. Jahnke
Mar 1, 2022, 2:17:51 AM3/1/22
to hugi...@googlegroups.com
Am 28.02.22 um 17:45 schrieb Robert Clausecker:
anything amiss. Everyone can post there, you needn't be a member.
>> I made the .deb using CMake, maybe it can also build packages for
>> freeBSD? By all means, use the clang++ C++ compiler - so far it's made
>> a big difference speed-wise. And if you want to recreate today's
>> binaries, they are made from the associated_alpha branch, which I
>> haven't merged back into master yet.
>
> FreeBSD ports are compiled with the system's compiler, which is clang
> these days. The ports build system is external to the packages and
> hooks into your CMake build scripts, so no changes on your part will be
> required. I'll let you know once I get something done.
Great! What I was hinting at is that the CMake script for lux can do the
entire package-building process as well, so once you can build the
binary, maybe you can get CMake (via cpack) to build a freeBSD package -
the debian packages made that way aren't 'good enough' for the distro (I
know because I maintain my vspline package on debian), but it's a start
and you have something which you can give to people to try it out before
it makes it's way into the repo.
Kay
> Am 28.02.22 um 17:41 schrieb 'Kay F. Jahnke'
>> Have you built the code on freeBSD already? I think this shouldn't be
>> too hard, with the CMake process and few dependencies. If you have,
>> please let me know - it would be the fourth OS running lux!
>
> I have not made any attempts in this regard, but I want to start in the
> next few days. If I find any problems, I'll go ahead and report these
> to you so you can maybe add patches in time for the 1.1.0 release.
If you like, you can go via lux' issue tracker on bitbucket if you find
>> too hard, with the CMake process and few dependencies. If you have,
>> please let me know - it would be the fourth OS running lux!
>
> I have not made any attempts in this regard, but I want to start in the
> next few days. If I find any problems, I'll go ahead and report these
> to you so you can maybe add patches in time for the 1.1.0 release.
anything amiss. Everyone can post there, you needn't be a member.
>> I made the .deb using CMake, maybe it can also build packages for
>> freeBSD? By all means, use the clang++ C++ compiler - so far it's made
>> a big difference speed-wise. And if you want to recreate today's
>> binaries, they are made from the associated_alpha branch, which I
>> haven't merged back into master yet.
>
> FreeBSD ports are compiled with the system's compiler, which is clang
> these days. The ports build system is external to the packages and
> hooks into your CMake build scripts, so no changes on your part will be
> required. I'll let you know once I get something done.
entire package-building process as well, so once you can build the
binary, maybe you can get CMake (via cpack) to build a freeBSD package -
the debian packages made that way aren't 'good enough' for the distro (I
know because I maintain my vspline package on debian), but it's a start
and you have something which you can give to people to try it out before
it makes it's way into the repo.
Kay
Robert Clausecker
Mar 4, 2022, 11:13:37 AM3/4/22
to 'Kay F. Jahnke' via hugin and other free panoramic software
Hi Kay,
I've now started working on the packaging.
Could you tell me which git commit your prerelease is based on? I need something to work off.
I noticed that your master branch is still on a 2021-12-15 state and development seems to be
happening on the associated_alpha branch. Which branch or commit should I use for the packaging?
Ideally you could tag a prerelease so I can directly work off that.
Yours,
Robert Clausecker
Am 28.02.22 um 17:41 schrieb 'Kay F. Jahnke' via hugin and other free panoramic software:
I've now started working on the packaging.
Could you tell me which git commit your prerelease is based on? I need something to work off.
I noticed that your master branch is still on a 2021-12-15 state and development seems to be
happening on the associated_alpha branch. Which branch or commit should I use for the packaging?
Ideally you could tag a prerelease so I can directly work off that.
Yours,
Robert Clausecker
Am 28.02.22 um 17:41 schrieb 'Kay F. Jahnke' via hugin and other free panoramic software:
Kay F. Jahnke
Mar 5, 2022, 4:20:07 AM3/5/22
to hugi...@googlegroups.com
Am 04.03.22 um 17:13 schrieb Robert Clausecker:
> Could you tell me which git commit your prerelease is based on? I need
> something to work off.
> I noticed that your master branch is still on a 2021-12-15 state and
> development seems to be
> happening on the associated_alpha branch. Which branch or commit should
> I use for the packaging?
> Ideally you could tag a prerelease so I can directly work off that.
I apologize for the moving target. I found a few bugs in the pre-release
version I offered in binary form which I have ironed out in the last few
days, and just now I have pushed a commit which is - hopefully - good:
https://bitbucket.org/kfj/pv/commits/a7e0d3a039766cb3b3651e672211ad9729b563c3?at=associated_alpha
or, a7e0d3a in short.
I have also set an annotated tag: 1.1.0-pre-2
I hope this is what you need for your packaging effort.
I now intend to consolidate the code - I have the feature level I want
for 1.1.0, but I'd like to have the code in use for some time to see if
more bugs crop up. Once I'm confident that all is well, I'll merge the
associated_alpha branch back into master and release 1.1.0.
Normally I work straight to the master branch, but with the move to
associated-alpha processing I was not sure my ideas would actually work
out, so I left the master branch at some 'safe' state. Luckily, so far,
it seems that the move worked as intended, and this made it possible to
add source image masking and stacking using the new code.
Kay
>
> I've now started working on the packaging.
Great!
> I've now started working on the packaging.
> Could you tell me which git commit your prerelease is based on? I need
> something to work off.
> I noticed that your master branch is still on a 2021-12-15 state and
> development seems to be
> happening on the associated_alpha branch. Which branch or commit should
> I use for the packaging?
> Ideally you could tag a prerelease so I can directly work off that.
version I offered in binary form which I have ironed out in the last few
days, and just now I have pushed a commit which is - hopefully - good:
https://bitbucket.org/kfj/pv/commits/a7e0d3a039766cb3b3651e672211ad9729b563c3?at=associated_alpha
or, a7e0d3a in short.
I have also set an annotated tag: 1.1.0-pre-2
I hope this is what you need for your packaging effort.
I now intend to consolidate the code - I have the feature level I want
for 1.1.0, but I'd like to have the code in use for some time to see if
more bugs crop up. Once I'm confident that all is well, I'll merge the
associated_alpha branch back into master and release 1.1.0.
Normally I work straight to the master branch, but with the move to
associated-alpha processing I was not sure my ideas would actually work
out, so I left the master branch at some 'safe' state. Luckily, so far,
it seems that the move worked as intended, and this made it possible to
add source image masking and stacking using the new code.
Kay
kfj
Mar 5, 2022, 5:13:40 AM3/5/22
to hugin and other free panoramic software
I also uploaded updated binaries:
Kay
Reply all
Reply to author
Forward
0 new messages