Luminance HDR covers the whole bracketed exposure workflow in one Qt5 window

A desktop front end for a photographic workflow, not a converter

Luminance HDR is a graphical user interface based on the Qt5 toolkit that provides a complete workflow for HDR imaging. The word complete is doing real work in that description. This is not a one-shot format converter that takes an OpenEXR file and writes a JPEG; it is the application you sit in front of while you work through a set of exposures from capture to tone mapped output.

The audience is photographers and imaging people who already shoot several frames of the same scene at different exposure settings. Those frames have to be merged into a single file with the dynamic range of the original scene, and then mapped down to something a screen or printer can show. That merge-and-map sequence is exactly what the tool is built around, and the surrounding operations, rotation, resizing, projective transformations and copying EXIF data between image sets, sit inside the same window rather than in separate utilities.

The implementation is C++ with a Qt5 interface, released under the GNU General Public License version 2. The project also carries an internationalization layer, so the interface is available in multiple languages, and the source tree includes a dedicated i18n directory.

The format list is where HDR pipelines usually break

Format coverage is a fair test of whether an imaging tool will fit an existing workflow, and Luminance HDR covers a wide set of formats. On the HDR side it reads and writes OpenEXR files with the exr extension, Radiance RGBE with the hdr extension, TIFF in 16bit, 32bit float and LogLuv variants, raw image formats with various extensions, and PFS native format with the pfs extension.

Raw support is worth calling out because it is not native to the project. The documentation states that raw image formats are supported and treated as HDR thanks to LibRAW, so a photographer can work from camera originals rather than from converted TIFFs.

The LDR side is smaller but practical: JPEG, PNG, PPM, PBM, TIFF and FITS. FITS in particular is an astronomy format, which tells you the tool is used beyond everyday still photography, and the presence of LogLuv and 32bit float TIFF tells you it is aimed at people who care about the tonal representation rather than just getting a picture out.

Two file types in the tree hint at how this is shipped. The net.sourceforge.qtpfsgui.LuminanceHDR.desktop file and the net.sourceforge.qtpfsgui.LuminanceHDR.appdata.xml file are the standard Linux desktop and software store entries, which means the application integrates with menus and software centres on a Linux desktop without extra configuration.

Merging exposures, then tone mapping the result

The core feature list is short and concrete. You can create an HDR file from a set of images taken at different exposure settings of the same scene, and the accepted inputs are JPEG, 8bit and 16bit TIFF, and raw. You can save and load HDR files, rotate and resize them, tone map HDR images, apply projective transformations, and copy EXIF data between sets of images.

The order of those operations matters when you think about how you will actually use the tool. Merging produces the high dynamic range file, and tone mapping brings it back into a viewable range, and the projective transformations and resizing are the finishing operations you apply before export. Keeping them in one application means the intermediate HDR file can stay on disk in its native format between steps rather than being flattened.

EXIF handling deserves a specific note. The capability described is copying EXIF data between sets of images, which matters when you merge a bracket and want the camera settings that produced each frame to travel with the merged result. The documentation does not describe which EXIF tags are copied, which are dropped on merge, or how the values are reconciled when the frames in a bracket disagree, so anyone relying on that metadata should check a merged file directly before building an archiving workflow on top of it.

pfstools underneath, with a tone mapping library of its own

Luminance HDR is not a from-scratch implementation of the imaging maths. The project states that the code is in part based on existing open source packages, naming pfstools, pfstmo and pfscalibration by Grzegorz Krawczyk and Rafal Mantiuk, and qpfstmo by Nicholas Phillips. The credits say plainly that without their contribution the project would not have been possible.

That inheritance explains the PFS native format. The PFS family is a pipeline-oriented HDR format, and having pfs in the format list means the application can exchange intermediate files with the command line tools in that ecosystem, including the separate PFStmo tone mapping library and PFScalibration.

The repository also carries librtprocess as a directory of its own, so at least part of the processing code is vendored rather than pulled from the system. The build is CMake based, with CMakeLists.txt at the top level, plus a build-lhdr script, a build_files directory, an hdrhtml directory for the in-application help, and a test directory. The presence of a test directory is a modest signal about the shape of the codebase, not a claim about how much is covered.

Every build and dependency instruction lives in INSTALL.md

There is a deliberate gap in the project documentation here. The dependencies section does not list anything itself; it says to refer to the INSTALL.md file. The compiling section does the same. And the same file is named twice more, once for people intending to package the application for a GNU/Linux distribution and once as the general pointer. In other words, the project page is a map and INSTALL.md is the territory.

The consequence for a reader is that this page cannot hand you a working install command, and any tutorial built from it alone would end at the point where the real instructions begin. Distribution packages do exist for GNU/Linux systems, as the packaging status badge in the project documentation shows, and the project is also published through the SourceForge page for qtpfsgui alongside the GitHub repository, which is where older builds for Windows and macOS have traditionally been listed.

Two other files complete the picture of how support works. LOCALIZATION.md covers the translation effort, which matches the i18n directory in the tree, and the BUGS file is the documented place for bug reports, issues and feature requests. The copyright header covers 2006 to 2019 and names Davide Anastasia, Franco Comida and Daniel Kaneider, with earlier copyright from 2006 to 2010 held by Giuseppe Rota.

A GUI against a command line pipeline, and the choice between them

The real alternative to Luminance HDR is not another GUI, it is the command line family it is built on. pfstools, PFStmo and PFScalibration are separate programs from the same research lineage, and a photographer comfortable with a shell can build the same merge-and-tone-map pipeline from scripts, without an interactive window.

The difference in approach is real and it cuts both ways. The command line route is scriptable and repeatable, which matters if you process many sets of the same scene or want the pipeline inside a larger batch job. It also demands that you know the format conventions and the tone mapping operators you want, since there is no interface to explore them in. The GUI route is the inverse: you can open a bracket, look at the result of a transform, change it, and see the effect, at the cost of being a manual step in the loop.

Choosing between them is not purely a matter of taste. If your output needs to be reproduced exactly across many files, the pipeline form suits the job. If you are still deciding what a photograph should look like, an interactive window where you can compare operators on the actual image is worth more than the automation. Luminance HDR also keeps the PFS format in the loop, so the two approaches can meet: work in the interface, then finish with the command line tools on the saved file.

No tagged release since 2019, and a GPLv2 codebase to inherit

The maintenance picture needs stating plainly. The repository is not archived, and the last push was on 2026-05-20, so source changes have continued to land. The most recent tagged release, however, is 2.6.0 from 2019-07-15, and the release badge in the project documentation still points at that tag. That means the packaged binaries most users download are several years behind the working tree.

The licence is GPLv2, which matters for anyone shipping a modified build inside a commercial product, since the copyleft obligations attach to distributing the modified program. The documentation does not offer commercial licensing terms, so an organisation that needs them has to look elsewhere or work with the copyleft as it stands. This is a boundary worth checking before the project is embedded in a product pipeline.

There is a Changelog and a TODO file in the repository, so the intent of upcoming work is recorded even if the release cadence is not. The practical takeaway for an adopter is that you should expect to build from the master branch rather than track tagged releases, and that the gap between 2019 and the 2026-05-20 push should be reviewed in the commit history before you trust a seven year old binary.

Editorial conclusion

Luminance HDR suits a photographer who already shoots bracketed exposures and wants a single desktop tool that reads raw, OpenEXR and Radiance files without leaving the application, and it does not suit someone who expects camera control or an actively released package, since the last tagged release was 2.6.0 on 2019-07-15 and the project defers every dependency and build instruction to INSTALL.md. Before adopting it, read INSTALL.md against your distribution and confirm the bundled librtprocess and the LibRAW path work on your platform.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. LuminanceHDR/LuminanceHDR on GitHub
3. Project website
4. README
5. Releases