Files
Jungfraujoch/docs/JFJOCH_VIEWER.md
T
leonarski_fandClaude Opus 5 6194fe6fbf
Build Packages / build:viewer-tgz:cpu (push) Successful in 11m45s
Build Packages / build:viewer-tgz:cuda (push) Successful in 17m11s
Build Packages / build:rpm (rocky9_nocuda) (push) Successful in 18m59s
Build Packages / build:rpm (ubuntu2404_nocuda) (push) Successful in 21m9s
Build Packages / build:rpm (rocky8_nocuda) (push) Successful in 24m51s
Build Packages / build:rpm (ubuntu2204_nocuda) (push) Successful in 25m1s
Build Packages / build:rpm (rocky8_sls9) (push) Successful in 21m32s
Build Packages / build:rpm (rocky9_sls9) (push) Successful in 17m49s
Build Packages / build:rpm (rocky8) (push) Successful in 23m8s
Build Packages / build:rpm (rocky9) (push) Successful in 20m8s
Build Packages / build:rpm (ubuntu2404) (push) Successful in 20m4s
Build Packages / XDS test (durin plugin) (push) Successful in 10m53s
Build Packages / Generate python client (push) Successful in 28s
Build Packages / Create release (push) Skipped
Build Packages / Build documentation (push) Successful in 1m30s
Build Packages / build:rpm (ubuntu2204) (push) Successful in 23m22s
Build Packages / DIALS test (push) Successful in 18m9s
Build Packages / XDS test (neggia plugin) (push) Successful in 7m55s
Build Packages / XDS test (JFJoch plugin) (push) Successful in 8m56s
Build Packages / Unit tests (push) Successful in 1h54m52s
Build Packages / build:windows:nocuda (push) Canceled after 0s
Build Packages / build:windows:cuda (push) Canceled after 0s
viewer: calibrate the whole dataset from "Analyze dataset"
The powder panel could only calibrate the image on screen. Calibration is now a
third page beside MX and AzInt, so the dataset button runs it over every image the
same way it runs the other two - which is the point, since a powder ring is
measured far better by summing a run than by one frame.

The page carries the calibrant and the method (rings or spots); the interactive
Guess/Refine buttons stay where they were and now share the one calibrant
selection, so there is no second combo to drift. analyzeDataset() carries the
ProcessMode rather than a bool: a third state was coming, and two bools would have
had one combination that cannot be valid.

The calibrant list gains ICE, which it could not offer before: the widget worked
in unit cells, and hexagonal ice has none that generates its rings correctly
(P6_3/mmc would include systematically absent ones). FindCenter now takes the ring
list its first line used to derive, so the interactive path gets ice as well.

The result window leads with the residual rms rather than the fitted sigma. The
sigma is a formal scatter estimate and understates a bad fit badly - measured on
ice, 0.215 px reported against a 1.70 px residual - while the rms separates a
usable fit from one that has locked onto the wrong thing.

A rings run needs the profile binned in azimuth; below four sectors it returns
nothing at all. The viewer raises the count to 32 exactly as the CLI does, and
says so in the panel and in the job dialog rather than doing it silently.

Also fixes a CLI inconsistency this comparison exposed: rugnux's calibration
branch never applied the standard offline analysis defaults, so it measured the
rings in a profile built with the file's polarization factor while every other
mode - and the viewer - uses 0.99. Found because the two disagreed by 0.005 px in
PONI x, and confirmed by reproducing the viewer exactly with --polarization 0.99.
With it applied the CLI and the viewer write byte-identical .poni files on LaB6
by rings, LaB6 by spots, and an iced dataset over 1800 images.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-07 10:45:39 +02:00

155 lines
9.5 KiB
Markdown

# jfjoch_viewer
`jfjoch_viewer` is the **interactive** desktop application of Jungfraujoch. It opens diffraction
datasets, displays each image together with the analysis overlay (spots, predictions, azimuthal
integration, per-image statistics), and can follow a live data collection by syncing with a
running [`jfjoch_broker`](JFJOCH_BROKER.md) over its HTTP interface.
It is a standalone Qt 6 application, distributed pre-built for **Linux and Windows** on the Gitea
release page and in the Jungfraujoch RPM/APT repositories — see [Release contents](RELEASE_CONTENTS.md)
for what each package contains and what it requires, and [Deployment](DEPLOYMENT.md) for how to
install it.
## Where it fits among the three analysis tools
| Tool | Mode | Driven by | Output |
| --- | --- | --- | --- |
| [`jfjoch_broker`](JFJOCH_BROKER.md) | Online, real-time streaming analysis on FPGA + GPU | HTTP/REST + ZeroMQ | Live results and statistics, images streamed to [`jfjoch_writer`](JFJOCH_WRITER.md) |
| **`jfjoch_viewer`** | **Interactive, on-screen exploration** | **Qt desktop application** | **On screen; a processing job can write the same files as `rugnux`** |
| [`rugnux`](RUGNUX.md) | Offline batch processing of a stored dataset | Command-line interface | `_process.h5`, and `.mtz`/`.cif`/`.hkl` when merging |
## Functionality
- Opens HDF5 files written by [`jfjoch_writer`](JFJOCH_WRITER.md) (`*_master.h5`) and the
`*_process.h5` files produced by [`rugnux`](RUGNUX.md). It also opens NXmx files
written by DECTRIS detectors, though that path has had only limited testing.
- Runs an **embedded data-processing pipeline** — the same analysis code as the rest of
Jungfraujoch — performing spot finding, indexing and integration on the displayed image, with the
result drawn over it. This interactive analysis is not written anywhere.
- Runs **full processing jobs** on the open dataset with *Analyze dataset*, on the same
[`rugnux`](RUGNUX.md) engine and off the GUI thread. The settings panel's **MX / AzInt / Calib**
toggle decides what a run does — full analysis, azimuthal integration only, or a detector
calibration — over a chosen image range, optionally writing `_process.h5` and the merged
`.mtz`/`.cif`. A finished run becomes a selectable view of the dataset, so several processing runs
can be compared against each other, and its merging statistics (or, for a calibration, its fitted
geometry) open in their own window; the *Processing* panel lists the runs and reopens those
results. The equivalent `rugnux` command line can also be copied out to run the same job on a
cluster instead.
- **Detector calibration** against a powder standard, on the *Calib* page: pick the calibrant
(`LaB6`, `AgBh`, `CeO2`, `Si`, `ice`, or the open dataset's own unit cell) and fit either the image
on screen (*Guess* / *Refine detector calibration*) or the whole dataset (*Analyze dataset*, which
writes a pyFAI `<output prefix>.poni`). The whole-dataset fit measures the rings either from the
azimuthally-binned profile summed over the run (*Rings*, the default) or from the pooled spot lists
(*Spots*), and reports PONI x/y, the two tilts and the distance against the header values. Judge it
by the **radial rms**, not the beam-centre sigma: the sigma shrinks with the number of ring points,
so a fit that sits a couple of pixels off every ring can still report a small one. *Rings* needs
the run to be integrated in azimuthal sectors — with the AzInt page's *Azimuthal bins* below 4 the
calibration run raises it to 32, as `rugnux --mode calibration` does, and says so.
- **Settings** panel for the geometry, unit cell, spot finding, indexing, azimuthal integration,
Bragg integration, scaling, powder calibration and a reference dataset — the same settings the
CLI takes.
- Auxiliary windows: image list, dataset metadata, spot list, reflection list, reciprocal-space
viewer, 2D azimuthal-integration image, calibration-image viewer and a magnifier; plus the
*Inspector* (per-image statistics, image features, resolution rings, ROI statistics), the
*Image strip* thumbnail feed and dataset-info charts.
- User-mask editing: build a user mask interactively, load one from TIFF (replacing or adding to the
current one), save it as TIFF, clear it, or upload it to a connected server.
- Layout presets (*View ▸ Image layout / Processing layout / Reset layout*) rearrange the docks for
looking at images or at processing results.
## Hardware
As with the rest of Jungfraujoch, **serious performance requires an NVIDIA GPU**. On systems with a
GPU, use the CUDA build (a separate package variant everywhere: RPM/APT repository, `.tgz` and
Windows installer) for the embedded indexing and integration; the non-CUDA build runs the same
pipeline on the CPU at much lower throughput. The CUDA build also runs on a machine without a GPU —
see [Release contents ▸ CUDA and non-CUDA builds](RELEASE_CONTENTS.md#cuda-and-non-cuda-builds).
## Opening data
- **File ▸ Open** (`Ctrl+O`) — open a local HDF5 file.
- **File ▸ Open HTTP** (`Ctrl+H`) — connect to a `jfjoch_broker` HTTP endpoint to follow a live
collection. The dialog defaults to host `localhost` and port `8080`; these defaults can be
overridden with the environment variables `JUNGFRAUJOCH_HTTP_HOST` and `JUNGFRAUJOCH_HTTP_PORT`.
- **Command line** — `jfjoch_viewer <file.h5>` opens a file (or an `http://host:port` URL) on
start-up. `--dbus <true|false>` (`-d`) enables or disables the D-Bus interface (default: enabled);
`--help` and `--version` behave as usual.
## D-Bus interface
When enabled, the viewer registers the D-Bus interface `ch.psi.jfjoch_viewer`, so other processes
can drive it:
- `LoadFile(filename, image_number=0, summation=1)` — open a file (or an `http://host:port` URL)
and display the given image.
- `LoadImage(image_number, summation=1)` — navigate to an image in the already-open dataset.
`summation` sums that many consecutive images before display.
## Building from source on Windows
`jfjoch_viewer` is the one Jungfraujoch component that is cross-platform: it builds on Windows 11
with MSVC and the full CUDA GPU path. (The rest of Jungfraujoch — broker, receiver, FPGA host — is
Linux-only.) A pre-built installer is published with every release, so building from source is only
needed to develop or to change the build options. On Windows the build is automatically restricted
to the viewer and the libraries it needs (`JFJOCH_VIEWER_ONLY` is forced on), and the remaining
dependencies are fetched and built automatically (the first configure needs network access).
Verified toolchain — the same one the released installer is built with:
- Windows 11
- Visual Studio 2026 with the C++ (MSVC) toolset — required; CUDA on Windows builds through MSVC
- CUDA Toolkit 13.3 (12.8 or newer is required) — for the GPU indexing/integration path
- Qt 6.11 for MSVC (`msvc2022_64`), including the **Qt Charts** module — e.g. `C:\Qt\6.11.1\msvc2022_64`
- CMake plus Ninja. The CMake that ships with Visual Studio is the simplest choice and works out of
the box — it comes with the C++ workload, so there is nothing extra to install. Any recent
standalone CMake (from cmake.org, or the one bundled with Qt in `C:\Qt\Tools\CMake_64`) works too.
- zlib and Eigen — the two libraries not auto-fetched on Windows. Build/install both into one prefix
(here `C:\deps`) and point CMake at it:
```
:: static zlib
git clone --branch v1.3.1 https://github.com/madler/zlib
cmake -G Ninja -S zlib -B zlib-build -DCMAKE_INSTALL_PREFIX=C:/deps
cmake --build zlib-build --target install
:: Eigen 3.4 (header-only) -- install just the headers with `cmake --install`; the BLAS/LAPACK/test
:: targets are disabled since they are not needed (and fail to build under MSVC). Use the 3.4 series:
:: the project requests find_package(Eigen3 3.4), which Eigen's same-major rule rejects for 5.x.
git clone --branch 3.4.0 https://gitlab.com/libeigen/eigen.git
cmake -G Ninja -S eigen -B eigen-build -DCMAKE_INSTALL_PREFIX=C:/deps ^
-DEIGEN_BUILD_BLAS=OFF -DEIGEN_BUILD_LAPACK=OFF -DEIGEN_BUILD_DOC=OFF -DBUILD_TESTING=OFF
cmake --install eigen-build
```
- Optional: [NSIS](https://nsis.sourceforge.io) to build the `.exe` installer.
Configure and build from an **x64 Native Tools Command Prompt for VS 2026** (so `cl`, `nvcc` and
`ninja` are on `PATH`):
```
cmake -G Ninja -B build-win -DCMAKE_BUILD_TYPE=Release ^
-DCMAKE_PREFIX_PATH="C:/deps;C:/Qt/6.11.1/msvc2022_64"
cmake --build build-win --target jfjoch_viewer
```
Notes:
- `CMAKE_PREFIX_PATH` (the `C:/deps` prefix plus Qt) is the only required flag — CMake finds zlib and
Eigen from the prefix, so no separate `-DZLIB_ROOT` is needed.
- The CUDA toolchain is located automatically from the `CUDA_PATH` environment variable that the
CUDA installer sets (or from `nvcc` on `PATH`). Pass `-DCMAKE_CUDA_COMPILER=".../bin/nvcc.exe"`
only if `nvcc` is installed in a nonstandard location and is not found.
- For a machine without an NVIDIA GPU, add `-DJFJOCH_USE_CUDA=OFF`: the viewer then runs the same
pipeline on the CPU (FFTW indexer) at lower throughput.
To produce a self-contained installer (bundles the Qt runtime via `windeployqt`, the analysis CLIs,
and — on the CUDA build — the cuFFT runtime DLL, so the target host needs neither Qt nor a CUDA
toolkit), with NSIS installed:
```
cd build-win
cpack
```
The NSIS generator is selected automatically on Windows (no `-G` needed). What comes out, and how
the CUDA and CPU variants are named and told apart, is described in
[Release contents ▸ Windows installer](RELEASE_CONTENTS.md#windows-installer).