Files
leonarski_fandClaude Opus 5.5 d2d8102b66 JPEG: encode with the vendored stb_image_write instead of libjpeg-turbo
WriteJPEGToMem is the only JPEG code in the tree (encode only, no decoding),
and libjpeg-turbo came in as an ExternalProject whose imported target passed
its include dir as -isystem. Any other jpeglib.h on the include path (conda,
the distribution, the CUDA directory) could then win, and a build failed with
"Wrong JPEG library version: library is 62, caller expects 80".

stb_image_write v1.16 (commit 31c1ad3) is vendored in preview/stb/ and
compiled into JFJochJPEG.cpp alone with STB_IMAGE_WRITE_STATIC and
STBI_WRITE_NO_STDIO, so no JPEG symbol or header leaves that file. Output is
baseline JPEG (it was progressive); the API is unchanged. Size limits are
checked up front (JPEG's 65535 per side, stb's int pixel index) and an
encoder failure throws JFJochException. Quality is clamped to 1-100. stb
encodes an 18 Mpx frame in ~350 ms against ~210 ms for the scalar
libjpeg-turbo we built; accepted.

Removed: the ExternalProject and JPEG::JPEG target in preview/, nasm from the
Docker images, licenses/libjpeg-turbo.txt and its manifest row, and the CI
check that counted libjpeg-turbo copies in the viewer (the Qt JPEG/TIFF plugin
check stays, as does the viewer's plugin exclusion). Licence: MIT OR
Unlicense, recorded in licenses/ and THIRD_PARTY_NOTICES.md.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HVeDQqrcrEZy6XBUCMZvyT
2026-11-01 13:49:11 +01:00

2.9 KiB

Software requirements

Operating system

Recommended operating system is Red Hat Enterprise Linux (RHEL) / Rocky Linux versions 8 or 9. For these operating systems we provide RPMs with pre-built binaries to simplify deployment. On an experimental basis we also build repositories for Ubuntu 22.04 and 24.04.

Running Jungfraujoch on Red Hat Enterprise Linux 7 is currently not tested and not recommended, but likely possible by providing some packages from external repositories.

Two programs additionally run on Windows 11: the desktop viewer jfjoch_viewer, shipped as a pre-built installer, and rugnux, the offline analysis CLI, shipped as a .zip. Both can be built from source with Visual Studio 2026 (MSVC) and CUDA 13.3 — the viewer additionally needs Qt 6.11; see jfjoch_viewer ▸ Building from source on Windows. The Windows artefacts bundle the Qt runtime (viewer only) and, on the CUDA builds, the cuFFT DLL, so end users need neither Qt nor a CUDA toolkit installed — only an NVIDIA GPU driver for the GPU path. On Linux the portable archives link CUDA entirely statically and so need nothing but the driver. rugnux is also built for 64-bit Arm Linux (GH200, DGX Spark). The rest of Jungfraujoch is Linux-only and x86-64-only. See Release contents for the CPU baseline and CUDA requirements of each released package.

Software dependencies

Required:

  • C++20 compiler and C++20 standard library; recommended GCC 11+ or clang 14+ (Intel OneAPI and AMD AOCC also work)
  • CMake version 3.26 or newer + a build tool (GNU make or Ninja)

HDF5, libtiff, zlib and Eigen used to be required system packages; they are now downloaded and built automatically by CMake (see the note below), so none of them needs to be installed. Beyond the optional dependencies listed below, no third-party library has to be provided by the host any more.

Optional:

  • CUDA compiler version 12.8 or newer - required for the MX fast feedback indexer and GPU analysis
  • FFTW library - for indexing if GPU/CUDA is absent (also auto-downloaded by CMake)
  • Node.js - to build the frontend
  • Qt version 6 (for jfjoch_viewer)

Many further dependencies (spdlog, Zstandard, HDF5, slsDetectorPackage, libzmq, libtiff, Ceres, the fast feedback indexer, Catch2, ...) are downloaded automatically by CMake and statically linked; building therefore requires network access on the first configure. zlib (as zlib-ng in its zlib-compatible mode) and Eigen are among them: a copy already on the machine is used instead if the configure is given -DZLIB_ROOT=<prefix> or -DEigen3_DIR=<dir>. Others are vendored directly in the source tree. The complete list of third-party components, with copyright holders, licenses and verbatim license texts, is in Third-party software notices and the licenses/ directory.