Lumiera
The new emerging NLE for GNU/Linux

Lumiera is written for GNU/Linux.
We try to get the best out of modern system programming techniques to reach a solid performance and good throughput. Lumiera shall scale with the provided Hardware, the more RAM and the more/faster CPU’s you have the better. Nevertheless lower end 64bit machines are supported too.

Secondary targets will be other free operating systems which offer a decent Posix API. Porting to other more or less similar platforms will be possible, if — by coincidence — Someone™ helps with porting.

Having said that — for the time being, the core team won’t spend much effort on porting, be it to special hardware or some other popular OS.

Platform

We develop and test on standard PC hardware, 64 bit.
[ We attempt to write code mostly in a portable way, yet we have encountered several aspects now where our solution effectively assumes 64bit layout —  and thus the code might compile on 32bit, but then not perform as expected. A notorious example are hash values, which are typed as size_t following the C++ idiom. We now use a hash function that is clearly optimised for 64bit, and we know that a 32bit hash would produce collisions on a regular base, while our solution assumes that collisions can be ruled out effectively. This is just one example, which shows that handling such aspects in a portable fashion, while certainly possibly, requires a significant amount of design work and incurs additional complexity. For the time being, we are content to document such cases as tickets. ]
It is intended to target other platforms running GNU/Linux eventually. Lumiera expects a “standard” desktop installation running a XServer.
[ Wayland is “just around the corner” since 10 years now. Well, recently it seems it is really just around the corner. We are aware of the necessary changes, which are not very complicated to implement (since we are using GTK-3). However, as long as Wayland simply crashes or hands in our everyday work setup with XFCE, we will not consider this topic a priority. In the meantime, please report any problems you encounter with Lumiera running on XWayland. ]

Graphics

There are no special requirements for the graphic system, other than some GPU supported for common desktop display in the standard setup. Hardware acceleration for video processing will likely be added later through extensions, but will remain strictly optional.
[ For the time being, we’ll watch the evolution in that area and might revisit that topic when there are more compelling and widely supported solutions available. Support for 32bit floating point data formats is considered more important. ]

Disks

No special requirements. Video editing requires decent disk speed though, so it is suggested to use a fast/big array of disks configured as raid.

Special Hardware

Support for special hardware would be possible, but depends on certain conditions

  • we need access / donations for the hardware

  • Specs and APIs must be open.

  • someone to do the actual interfacing and support needs to join the team

Compatibility

We try to keep our depdendencies close to Debian/stable and the most recent Ubuntu LTS. Whenever we need more recent libraries or other dependencies not available for our reference platform, we care to provide custom Debian / Ubuntu packages as reference. This does not mean Lumiera is limited to Devian flavours, it should work on any current Linux distribution.

Languages and Tools

  • C / C++

    • A C++23 compatible compiler is required.
      [ In practice, we build using GCC and occasionally we check using Clang. Right now (7/2025) Clang has fallen behind regarding support of type dependent name resolution in templates and does not even comply with C++20 in this respect. We have dropped most usages of the typename keyword recently, and as long as Clang can not cope with that, we have to postpone further tests with Clang. ]

    • GCC-14 or better should be fine.
      [ Basically we try to use just the stock language. But we actually compile with the GNU extensions, i.e. -std=gnu++23 / -std=gnu99. And any language feature is used to the degree that it is available and stable in this build environment. ]

  • BOOST (listed below are the Debian package names)

    • libboost-dev (at least 1.83)

    • libboost-program-options-dev

  • Script languages

    • Python (3.10) required for building (→SCons)

    • bash (some test scripts use bash specific extensions)

Build Tools

  • SCons build system v4.8
    [ Unfortunately, SCons still sets the conceptual standard how a modern build system should be: It is declarative, defines the what and not the how and uses build scripts written in a clean and modern language (Python). Autotools should be considered legacy, and CMake turned out to be rather disappointing and lacks adequate conceptual grounding. Meson has a somewhat more modern appeal, yet seems to require us to do much more work to get even remotely to that level of clarity and flexibility which we enjoy every day when working with SCons.
    We are aware of the shortcomings of SCons in practice however, notably that it is not widely known and thus requires additional learning effort, and that it could become prohibitively slow on very large projects. At the current project size, the delay on incremental builds does not really seem relevant in practice, given that C++ compilation as such is slow anyway. We are not aware of using any notable features of SCons beyond v2.0, and we use some SCons plug-ins, which are all shipped in-tree (directory admin/scons)]

  • pkg-config

  • Doxygen (optional)

  • Asciidoc (optional)

  • Git → git://git.lumiera.org/LUMIERA
    [ Ichthyo maintains a repo at Github ~Ichthyostega/Lumiera ]

💡 We maintain a Debian/Ubuntu package (based on git-buildpackage)

Libraries

  • Boost libraries

  • NoBug library

  • GAVL (for raw media support)

  • ALSA (libasound2-dev)

  • for the GUI: (GTK-3) gtkmm, glibmm-2.4, cairomm-1, gdlmm-3, Xv

    • libgtkmm-3.0-dev (>=3.20)

    • libglibmm-2.4-dev (>= 2.66), requiring at least glib2.0 (>=2.80)

    • libcairomm-1.0-dev (>= 1.14)

    • librsvg2-dev (>=2.40) for rendering Icons

    • libxv-dev
      [ For the time being, this is a placeholder and fallback to integrate any technology for displaying video frames on the dektop. It is now used in the XV viewer widget stage/output/xv-displayer.hpp|cpp — currently expected to be obsolete soon, but it is yet undecided as of 11/2025 what we use as starting point for video output from the Lumiera Render Engine. XV might be retained as a fall-back solution, the libraries GLX or EGL might be used… ]
      and X-lib TODO 11/2025

    • libgdl-3-dev (>= 3.40) through libgdlmm-3 — the »Gnome Docking Library«
      [ lib GDL isn’t directly related to GNOME any more. We use this library for docking panels in the GUI with GTK-3. This solution was maintained for some time by the »Anjuta« project — we also contributed to the improvement of this library in the past, and these improvements went upstream with GDL-2.27. Unfortunately, GDL was abandoned meanwhile. and we do not see a clear pathway for the future here, short of upgrading to GTK-4, which is possible, but would require some considerable effort. As of 2025, GDL is still usable, but no longer available through the standard distribution channels.
      We provide a Git repository at our Website for libGDL (3.40) git://git.lumiera.org/debian/gdl and the GDL C++ bindings (3.7.3) git://git.lumiera.org/debian/gdlmm and we maintain custom Debian packages for both in our Debian DEB depot. ]