lux image and panorama viewer: version 1.1.4 released

[kfj]

Dear all!

I've released lux 1.1.4 - the version jump is due to silly old me who got the tagging wrong, it should really have been 1.1.1. Most changes are 'behind the scenes', and the most notable one is that lux can now use google highway for SIMD operations. This should allow more performant builds on newer x86 and non-x86 CPUs.

The binaries I released on my project's download page are still using Vc. Please pick files with '1.1.4' in the name. macOS binaries should arrive soon. So what's new apart from that?

• processing of panoramas with stacks
• support of all PTO include and exclude masks
• support of PTO lens/source image cropping

Stacked panoramas are now fully supported, but bear in mind that they use a lot of memory. You may have to use --build_pyramids=no and --build_raw_pyramids=no to squash memory use. The stacks are exposure-fused before they are stitched together, and each stack is processed as such and used for the final result, rather than using heuristics to make the stack assignments during the stitch and excluding redundant images from the result.

The full masking support refers to still images (when the viewer is at rest) and stitches to image file output, while the 'fast' view (while zooming, panning etc) will only show the 'stack parents' to save time.

Correct lens/source image cropping now makes it possible to properly display and render 'dual fisheye' images.

I'd like to point you to one interesting new feature, called 'hdr_spread'. With this parameter, you can select by how much the dynamic range of an exposure fusion is actually compressed. A 'classic' exposure fusion will compress the dynamic range to the same range as the input images, and this is what you get with the default, which sets hdr_spread to zero. Now with increasing hdr_spread, the dynamic range will be compressed ever less, until, finally, you arrive at the maximum value of one, which produces 'proper' HDR output (you'll need openEXR output to capture that). The HDR output from this process is actually generated with lux' modified Burt&Adelson image splining algorithm, so it uses a multi-scale approach and produces pleasing results. So if you'd like to produce an HDR image from a PTO holding an exposure bracket, try the new feature, it's as easy as

lux --fuse=yes --snapshot_extension=exr --hdr_spread=1 bracket.pto

hdr_spread will also affect the fusion of stacks. Enjoy!

[Kay F. Jahnke]

Dear all!

I've released lux 1.1.5. Again, most changes are 'behind the scenes',
but there is important new functionality as well: lux now looks at the
EXIF metadata of 'ordinary' rectilinear photographs and figures out the
field of view. With that datum, 'normal' camera images are now displayed
*with automatic perspective correction*. This is especially useful for
panorama work: If you take out snapshots from rectilinear images, these
snapshots will now automatically be geometrically correct and can be
'fed back into' a panorama. This is good for, e.g. nadir patches. lux
will also recognize a range of panoramic images made with the 'panorama'
function of smartphone camera apps, using a heuristic to recognize such
images, which typically don't have the required metadata and, therefore,
were displayed as flat stripes up to 1.1.4. Introducing such features
is, of course, a gamble - there's bound to be images where the detection
doesn't work or goes wrong, but I've tested it with all image types I
could get hold of and hope that it will work 'most of the time'. Of
course you can still override the automatics.

Another feature worth mentioning is the .lux.ini file. If you put a file
with that name (yes, it has a leading dot!) in your home folder, lux
will look for parameters which it will adopt for the entire session,
just as if you had passed them on the command line. The syntax is simple
- in every line, you put one long option name, followed by '=' and the
intended value, without any white space around the '=' sign. This is
standard .lux syntax, as described in the documentation.

Apart from these new features, a great many small improvements and bug
fixes should improve the user experience, while the user interface
hasn't changed very much.

There's good news for Mac users: I was given an intel Mac, and so I
could now do building and packaging for the mac myself, and I've made
some progress - I could build a lux 1.1.5 package for intel-based Macs.
I already mentioned with the release of 1.1.4 that lux can now use
highway for time-critical rendering code, and this made it possible to
build a lux version for 'apple silicon', which uses native ARM NEON SIMD
instructions for speed similar to AVX2 on intel machines. A friend has
built lux 1.1.5 with this backend on an *M1 mac* and made a package,
which you can find alongside the i86 package on my download page:

https://bitbucket.org/kfj/pv/downloads

There are also a windows installer, a ZIP file with a portable windows
version, a .deb file for ubuntu 20.10 and one for debian11, plus updated
documentation in HTML format.

The MacOS versions are still not well-integrated with the system, and I
haven't yet managed to create a 'universal binary' which will run on all
macs. Finder integration is also largely missing: using 'open with lux'
on images won't pass the filenames on to lux, so it's best to start lux
and use it's own file select dialog. When running lux in full-screen
mode, the file select dialog may be hidden behind lux' display - you may
have to switch to it's window manually. lux on macs will use automatic
rendering quality adjustment by default to cope with the typically high
resolution on macs.

Enjoy!

[Robert Clausecker]

Hi Kay,

I was planning to update the FreeBSD package today, but noticed that you
didn't upload the source code for 1.1.5 anywhere.
If this was not intentional, please let me know once you got around to
do so!

Yours,
Robert Clausecker

On 05.02.23 21:58, 'Kay F. Jahnke' via hugin and other free panoramic

[Kay F. Jahnke]

Am 09.02.23 um 16:49 schrieb Robert Clausecker:

> I was planning to update the FreeBSD package today, but noticed that you
> didn't upload the source code for 1.1.5 anywhere.
> If this was not intentional, please let me know once you got around to
> do so!

Robert, the master in the repo and the binaries are already 1.1.5 (see
pv_version.h), but I wanted it to 'hang around' for a little while
before I assign the 1.1.5 tag, in case anyone notices bugs. I've just
assigned the tag, does it now work for your build?

Kay

[Robert Clausecker]

Hi Kay,

I'll check if it works.  The usual convention if you want to have a
version hang out before you make it final is to tag a release candidate
(e.g. 1.1.5-RC1).  Once it is finalised, you tag 1.1.5.  But without a
tag, it is not clear for packagers which commit to base the package on.

I'll let you know when the test build is complete.

Yours,
Robert Clausecker

On 09.02.23 17:42, 'Kay F. Jahnke' via hugin and other free panoramic

[Robert Clausecker]

One problem I noticed: the configuration fails to find the HWY cmake file.

CMake Error at CMakeLists.txt:602 (find_package):
  Could not find a package configuration file provided by "HWY" with any of
  the following names:

    HWYConfig.cmake
    hwy-config.cmake

  Add the installation prefix of "HWY" to CMAKE_PREFIX_PATH or set
"HWY_DIR"
  to a directory containing one of the above files.  If "HWY" provides a
  separate development package or SDK, be sure it has been installed.


-- Configuring incomplete, errors occurred!

You don't ship this file and neither does FreeBSD's highway package. 
Will check if I can
just grab it from somewhere.

Yours,
Robert Clausecker

On 09.02.23 17:42, 'Kay F. Jahnke' via hugin and other free panoramic

[Kay F. Jahnke]

Am 09.02.23 um 18:30 schrieb Robert Clausecker:

> One problem I noticed: the configuration fails to find the HWY cmake file.
>
> CMake Error at CMakeLists.txt:602 (find_package):
>   Could not find a package configuration file provided by "HWY" with
> any of
>   the following names:
>
>     HWYConfig.cmake
>     hwy-config.cmake
>

To clarify further: this is the discussion leading to the decision to
adopt finding with config mode in highway:

https://github.com/google/highway/issues/1084

The code went into their repo as of:

commit 2ea983105e69f0d8daa7b5e8ea1bcf8fb8ecaea3
...
Date: Tue Jan 17 11:33:20 2023 +0100

Generate and install a HWYConfig.cmake file

This will be needed by cmake user consuming HWY.

Also remove FindHWY.cmake since not needed in a cmake-based
build tool setup.

[Robert Clausecker]

FreeBSD's package is 1.0.3, which is the most recent version, released
Jan 19.
However, it does not ship this file.  Maybe I can just grab it from
upstream.

Yours,
Robert Clausecker

On 09.02.23 18:40, 'Kay F. Jahnke' via hugin and other free panoramic

[Kay F. Jahnke]

Am 09.02.23 um 19:20 schrieb Robert Clausecker:

> FreeBSD's package is 1.0.3, which is the most recent version, released
> Jan 19.
> However, it does not ship this file.  Maybe I can just grab it from
> upstream.

It's not a file, cmake deploys the necessary information when you do a
'make install' on the target machine. The separate find-file was
dismissed as superfluous when deploying like that. I think it would be
easier if you simply patch out the bit in may CMakeLists.txt which looks
for highway.

Kay

[Robert Clausecker]

Am Donnerstag, dem 09.02.2023 um 20:01 +0100 schrieb 'Kay F. Jahnke'
via hugin and other free panoramic software:

How is this information “deployed” if not by placing a file somewhere?
CMake specifically asks for a file to be provided in the error message.
Here is the list of files installed for the devel/highway package:

https://cgit.freebsd.org/ports/tree/devel/highway/pkg-plist

Where is this information deployed? If it is not there, where would it
be if it was there?

The default location stuff is too fragile. I would strongly prefer to
avoid having to do that. Can't you just use pkg-config to find the
highway library?

> Kay


Yours,
Robert Clausecker

[Kay F. Jahnke]

Am 09.02.23 um 22:16 schrieb Robert Clausecker:

> How is this information “deployed” if not by placing a file somewhere?
> CMake specifically asks for a file to be provided in the error message.
> Here is the list of files installed for the devel/highway package:
>
> https://cgit.freebsd.org/ports/tree/devel/highway/pkg-plist
>
> Where is this information deployed? If it is not there, where would it
> be if it was there?

The list above does not contain all the files which should be deployed
on the target machine. If I do a 'make install' on my machine with hwy
master, it installs these files as well:

-- Installing: /usr/local/lib/cmake/hwy/hwy-config-version.cmake
-- Installing: /usr/local/lib/cmake/hwy/hwy-config.cmake
-- Installing: /usr/local/lib/cmake/hwy/hwy-config-relwithdebinfo.cmake

This is what I mean by 'deploy'. If you like, I can send you the files.
Maybe you can ask the maintainer of the highway port to look at the
matter - I suspect that these three files have to be added to the list.
When they are present, CMake should find your highway install with
CONFIG mode, as it's done in may lux CMakeLists.txt

> The default location stuff is too fragile.

I agree, that's why I requested the addition of code to make highway
findable with CMake. I'd like to stick with CMake for configuration. lux
1.1.4 did rely on the default location, and the patch I proposed to you
off-list yesterday evening would do just the same. Once the hwy port is
updated, you can switch back to the unpatched version. I did not mean to
propose a permanent solution, it's just to get you going with the 1.1.5
build if the finding-hwy issue can't be resolved otherwise.

Kay

[Robert Clausecker]

Okay, I checked again: the feature you depend on is not part of Google
Highway 1.0.3, which is the newest published version. Looks like it
went in just a few days after the release. I will therefore not be able
to package lux 1.1.5 until a Google Highway version with this feature
has been released.

I cannot fix this as I'm not going to bundle a second copy of Highway
just to build your package. We'll have to wait until a new Highway
version is released. Please avoid depending on unreleased features in
dependencies. Makes it much harder to actually use your software.

Yours,
Robert Clausecker

Am Freitag, dem 10.02.2023 um 08:09 +0100 schrieb 'Kay F. Jahnke' via

hugin and other free panoramic software:

[Kay F. Jahnke]

Am 10.02.23 um 13:18 schrieb Robert Clausecker:

> Okay, I checked again: the feature you depend on is not part of Google
> Highway 1.0.3, which is the newest published version. Looks like it
> went in just a few days after the release. I will therefore not be able
> to package lux 1.1.5 until a Google Highway version with this feature
> has been released.

Well, why don't you just apply the patch then? It's a simple fix and
will work. Then it will work just fine with hwy 1.0.3.

If you don't want to use highway because you insist on using the CMake
code I added recently to find it you could still build the Vc version,
even though it may produce less 'true' SIMD code on some platforms.

> I cannot fix this as I'm not going to bundle a second copy of Highway
> just to build your package. We'll have to wait until a new Highway
> version is released. Please avoid depending on unreleased features in
> dependencies. Makes it much harder to actually use your software.

You *can* fix it. All it takes is this patch to the CMakeLists.txt in
the lux root folder:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 013a122..af5f18c 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -598,17 +598,17 @@ endif()

# highway has added code to find it with cmake config mode

-if(USE_HWY_LIBRARY)
- find_package(HWY CONFIG REQUIRED)
- if (HWY_FOUND)
- message(STATUS "find_package: HWY_FOUND = true")
- endif()
-
- if(NOT "${HWY_INCLUDE_DIR}" STREQUAL "")
- message(STATUS "HWY_INCLUDE_DIR = ${HWY_INCLUDE_DIR}")
- include_directories(${HWY_INCLUDE_DIR})
- endif()
-endif()
+# if(USE_HWY_LIBRARY)
+# find_package(HWY CONFIG REQUIRED)
+# if (HWY_FOUND)
+# message(STATUS "find_package: HWY_FOUND = true")
+# endif()
+#
+# if(NOT "${HWY_INCLUDE_DIR}" STREQUAL "")
+# message(STATUS "HWY_INCLUDE_DIR = ${HWY_INCLUDE_DIR}")
+# include_directories(${HWY_INCLUDE_DIR})
+# endif()
+# endif()

set(required_libraries vigraimpex sfml-window sfml-graphics
sfml-system exiv2)

[Kay F. Jahnke]

Am 10.02.23 um 15:50 schrieb Kay F. Jahnke:
>
> You *can* fix it.

Not convinced? Here's my reasoning: You're build relies on the freeBSD
highway package. Fulfilling the dependency means that highway will be
installed in a specific location (e.g. /usr/local). Therefore you know
that highway is available and accessible, and you don't need the CMake
code to locate it.

Kay

[Robert Clausecker]

Hi Kay,

Am Samstag, dem 11.02.2023 um 12:39 +0100 schrieb 'Kay F. Jahnke' via

hugin and other free panoramic software:

The location of dependencies is configurable when building the port, so
I cannot rely on just /usr/local. While it is probably possible to
hack something for this, I'm not too keen on messing around with your
already fairly complex build scripts. Will wait for the next Highway
release (I've already tested with the latest git commit of Highway;
your port works fine with it).

Yours,
Robert Clausecker

> Kay
>

[Kay F. Jahnke]

Am 11.02.23 um 13:35 schrieb Robert Clausecker:

> The location of dependencies is configurable when building the port, so
> I cannot rely on just /usr/local. While it is probably possible to
> hack something for this, I'm not too keen on messing around with your
> already fairly complex build scripts. Will wait for the next Highway
> release

Fair enough. They seem to release every two months or so.

> (I've already tested with the latest git commit of Highway;
> your port works fine with it).

Ah, that's good to know, thanks for the info! One worry less :D

Kay

[Kay F. Jahnke]

Dear all!

After a fair amount of testing and tweaking, I am now happy with my
rendering back-end using the highway SIMD library. Vc, which I have used
for intel CPUs until now, has better support for older CPUs: it offers
dedicated AVX (without the '2') support and the 'fallback' mode is
faster than when I use it with highway - but such CPUs are becoming
increasingly rare and using lux with them is no fun, anyway. What tips
the scale for me is AVX512 support. Vc does not produce actual AVX512
instructions, instead it falls back to emitting AVX2 instructions, so
there is not much to be gained in the rendering code which relies on the
SIMD library - some other code which relies on autovectorization may
benefit, but that's not so relevant. highway, on the other side, *does
support AVX512*, and a friend of mine who has a CPU with AVX512 has run
a test of the Vc version against the highway version of the code. The
performance gain was more than 50%!

The binaries on my download page are all done with Vc (except for the
macOS ARM64 build, which also uses highway because Vc does not produce
native ARM NEON code). For those of you who have AVX512 on a windows
machine, I now offer a lux-portable ZIP compiled with the highway
backend, so you can see what a difference the SIMD backend makes! It
would be nice if this binary could see a bit of testing, just to be sure
the change of SIMD backend does not introduce unwanted behaviour which
has escaped my scrutiny! I am considering switching to the highway
backend altogether with the next lux version. Please find the ZIP file here:

https://bitbucket.org/kfj/pv/downloads/lux_for_windows_1.1.5_portable_with_highway.zip

Apart from AVX512, this build supports the fallback ISA (no SIMD),
SSE4.2 and AVX2. The console output will tell you which CPU was detected.

Kay

[mikko....@kavi.fi]

Hi,

I just discovered Lux (on an M1 mac) – great work, thanks!

Any hope of supporting more projections? I regularly use panini projections for wide panoramas which now cause Lux to exit ungracefully.

Mikko

[Kay F. Jahnke]

> I just discovered Lux (on an M1 mac) – great work, thanks!

You're welcome! 1.1.6 is also out now (there's a separate thread on
hugin-ptx with the release notes) and there's an M1 binary for that as well!

> Any hope of supporting more projections? I regularly use panini
> projections for wide panoramas which now cause Lux to exit ungracefully.

If I remember correctly, Panini is not simply a single straight
geometrical reprojection but quite a complex affair. It's made to make
the result, printed out as a poster or such, look pretty, but it's not
such a good candidate for fast reprojection in a panorama viewer, where
every cycle counts when you're trying to produce the 60fps for smooth
animations.

Where does the Panini cause you trouble? Are you trying to stitch a PTO
to Panini projection or do you want to display a stitched image which is
already in panini projection?

If you want to make your panorama lux-friendly, best stitch to
spherical. If you're using hugin, tell it to supply your output with
GPano metadata - lux can read them, and you'll get the correct geometry
without fiddling.

Kay

[Kuutti Mikko (KAVI)]

I am running lux 1.1.6 (althoug the about box says 1.0), thanks.

I use hugin for producing panoramic photos and thought I could use lux as a quick way to make jpgs using the hugin-produced .PTOs and original (sub)images. For 2D output rectilinear quickly becomes unwieldy as the size increases, and for architecural images spherical is really not a good choice.

Mikko

> --
> A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
> ---
> You received this message because you are subscribed to a topic in the Google Groups "hugin and other free panoramic software" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/hugin-ptx/bfX6Fu3mwy0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to hugin-ptx+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/df46a2d2-cad5-5c49-a879-5473567a364c%40yahoo.com.

[Kay F. Jahnke]

> I use hugin for producing panoramic photos and thought I could use lux as a quick way to make jpgs using the hugin-produced .PTOs and original (sub)images. For 2D output rectilinear quickly becomes unwieldy as the size increases, and for architecural images spherical is really not a good choice.

I see, so it's about stitching a PTO file and producing an image which
'looks nice' as a whole, rather than being good to view with a panorama
viewer. For that purpose, using hugin/enblend is probably the better
choice, but the process (create remapped partials first, then stitch
them) is indeed a bit circuitous, compared to lux' integrated process.

When I look at the way how lux handles a PTO file specifying an
unhandled projection (like Panini) in the p-line, I admit it's
'ungraceful' - the p-line is only relevant for stitching, lux could
display the PTO in any of the target projections it can handle, and a
failure would only be necessary if the user actually requested stitching
to the p-line, like when pressing 'Shift+E' or using --stitch=yes. I'll
keep that in mind for the next version. Thank you for your input, sorry
I can't be more helpful right now.

Kay