cuFFT is the only CUDA component linked dynamically (cudart and the
fast-feedback indexer are static), so the prior Windows installer would
fail to launch the GPU path on a host without a CUDA toolkit. Ship
cufft64_*.dll next to the viewer (CUDA 13 keeps it in bin/x64, earlier
toolkits in bin); the DLL is self-contained, so the installed app needs
only an NVIDIA driver.
Tag the variant where it matters and nowhere else: the installer
filename (-cuda<major> / -cpu) and the Add/Remove Programs entry
("Jungfraujoch (CUDA)" / "(CPU)") advertise it, while the install folder
and Start Menu group stay plain "Jungfraujoch" -- the CUDA build is a
strict superset, so the two variants share a location and replace each
other.
Docs: SOFTWARE.md + JFJOCH_VIEWER.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Revert Eigen from the FetchContent OVERRIDE_FIND_PACKAGE vendoring (cd394c52,
d4d2d0d8) back to an external find_package(Eigen3) dependency, like zlib. The
OVERRIDE_FIND_PACKAGE mechanism makes the Visual-Studio-bundled CMake (4.x
"-msvc") intermittently segfault during configure -- ~1/3 of fresh configures,
and 100% with Ceres CUDA enabled. The fault is in CMake's own FetchContent
variable-stack cleanup, reached when Ceres' find_package(Eigen3) resolves the
override through a nested FetchContent_MakeAvailable. Stock Kitware CMake runs
the identical scripts fine, so it is a bug in the VS-bundled cmake binary;
providing Eigen externally avoids that path entirely and is stable with Ceres
CUDA both on and off (verified 0 crashes; full CUDA build + NSIS installer
succeed under the VS-bundled cmake).
Also fix CPACK_NSIS_INSTALLED_ICON_NAME: the backslash value was written
verbatim into CPackConfig.cmake, where "\j" is an invalid escape that cmake 4.x
(CMP0010 strict) rejects when cpack re-parses it, so cpack failed under the
VS-bundled cmake (older/Kitware cpack only warned). Use a forward slash.
- image_analysis: keep Ceres USE_CUDA OFF (Jungfraujoch does not use Ceres' GPU
solvers) but drop the now-obsolete "required to avoid the Windows cmake crash"
rationale from the comment.
- docs: Eigen is a required external dependency again (SOFTWARE.md); the Windows
viewer build provides zlib + Eigen externally (JFJOCH_VIEWER.md).
- THIRD_PARTY_NOTICES: move Eigen from the fetched-and-linked table to the
external runtime-libraries table.
Docker images still need Eigen re-added (5.0.1, source build) -- to follow.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
MSVC/Windows build fixes:
- Force JFJOCH_VIEWER_ONLY ON for Windows and macOS; the broker/receiver/FPGA/
writer server stack is Linux-only, so those platforms build the viewer subset.
- Vendor an OpenBSD/NetBSD getopt/getopt_long shim (tools/wingetopt/, BSD/ISC)
as a WIN32-only static lib -- the MSVC CRT has no <getopt.h> -- and link it
into the four portable CLI tools on Windows.
- jfjoch_extract_hkl.cpp: include <getopt.h> explicitly (it relied on glibc's
transitive <unistd.h>).
- jfjoch_process.cpp: guard <unistd.h> with #ifndef _WIN32.
- Guard JFJochStreamWriter and jfjoch_writer with IF(NOT JFJOCH_VIEWER_ONLY):
the former pulls in JFJochImagePuller, the latter uses a fork()/waitpid()
multi-process design; neither belongs to the portable viewer subset.
- Record wingetopt in THIRD_PARTY_NOTICES.md and licenses/.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Acknowledge all bundled third-party software and satisfy attribution/notice
requirements, while keeping it maintainable:
- THIRD_PARTY_NOTICES.md: human-readable manifest (component, copyright, SPDX
license, link) for fetched, vendored, and runtime/SDK dependencies.
- licenses/: verbatim license texts; COLLECT.sh regenerates them from the
build trees and system SDK locations.
- Bundle the verbatim Qt LGPL-3.0 text and the CUDA Toolkit 12.8 EULA.
- frontend: self-contained npm attribution generator (`npm run licenses` ->
dist/THIRD_PARTY_LICENSES.txt), wired into the frontend build target.
- Install LICENSE + notices + licenses/ into share/doc/jfjoch for every
packaged component.
- viewer: Help > "Third-party Licenses" window (QTextBrowser) showing a
generated, self-contained HTML built from licenses/.
- docs/SOFTWARE.md: drop the stale hand-kept dependency lists; point at the
manifest.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The viewer's only .qrc is compiled explicitly via QT_ADD_RESOURCES into
APP_RESOURCES; no .qrc is added directly as a target source, so AUTORCC never
acted on anything. Remove the dead flag.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
NSIS installer was missing several things on Windows:
- License: show the repo GPLv3 LICENSE as the click-through license page
(CPACK_RESOURCE_FILE_LICENSE).
- Start Menu: no shortcut was created -- add CPACK_PACKAGE_EXECUTABLES for
jfjoch_viewer, and embed an app icon so the shortcut is not generic. The
icon is a new multi-size jfjoch.ico (256 PNG + 48/32/16) compiled into the
.exe via resources/jfjoch.rc; macOS gets the matching jfjoch.icns copied
into the .app bundle (MACOSX_BUNDLE_ICON_FILE). Both derived from
resources/jfjoch.png, padded square with transparent bands.
- Naming: install folder, Start Menu group and Add/Remove Programs entry are
now "Jungfraujoch" instead of "jfjoch <version>".
Also ship the offline analysis CLIs (jfjoch_process/scale/azint/extract_hkl)
in viewer-only / Windows packages: JFJochReceiverPlots now lives in
JFJochCommon, so their stale JFJochReceiver link is dropped, leaving only the
portable libs (reader/image_analysis/writer/common). tools/CMakeLists.txt is
split so those four build everywhere while the hardware tools stay gated
behind NOT JFJOCH_VIEWER_ONLY, and the viewer-only branch now adds tools/.
They install into the "viewer" CPack component.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A viewer-only build builds jfjoch_viewer but the CPack block hard-coded
CPACK_COMPONENTS_ALL to "jfjoch writer" and only appended "viewer" when
JFJOCH_VIEWER_BUILD was set -- which a pure viewer-only build does not set.
cpack then tried to package the empty jfjoch/writer components and failed,
requiring a manual -D CPACK_COMPONENTS_ALL=viewer.
Branch the component list on build mode: viewer-only packages just "viewer";
other modes keep "jfjoch writer" plus driver-dkms/viewer when their flags are
set. Also drops the redundant re-set of the default list.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
USE_CUDA is a Ceres cache STRING (default "default" = auto-detect), not an
option(), so a plain SET was shadowed by the cache default and CUDA got
enabled on MSVC. Force it OFF in the cache instead.
Also drop two dead settings: MINIGLOG (Ceres uses abseil logging now, no
longer referenced) and EIGENSPARSE ON (already Ceres' default).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- CUDA: append sm_121 (Blackwell GB10 / DGX Spark) to CMAKE_CUDA_ARCHITECTURES
when nvcc >= 12.9 knows it. The static list tops out at sm_120 and embeds no
PTX, so without this a build would fail to launch on Spark ("no kernel image
available"); guarded so CUDA 12.8 (which predates sm_121) is unaffected.
- FFTW: enable NEON codelets on aarch64 (Grace), mirroring the x86 SSE2/AVX/AVX2
branch, so single-precision FFT is SIMD-accelerated instead of scalar on ARM.
Both are inert on x86 / CUDA 12.8; verified configure still succeeds there.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
FFTW is fetched and built by the jungfraujoch CMake (single-precision, from the
release tarball), so the system fftw packages (fftw-static/fftw-devel on Rocky,
libfftw3-dev on Ubuntu) were unused. Remove them from all four images.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The jungfraujoch CMake now builds HDF5 + libtiff (FetchContent) and
libjpeg-turbo + Eigen (ExternalProject / OVERRIDE_FIND_PACKAGE) itself, so the
per-image pre-builds and system -dev packages for those were dead weight (the
app rebuilt its own copies regardless). Consolidate dependency management into
the one CMakeLists at the cost of longer build time (build env has network).
- Qt: pin static 6.9.1 everywhere. ubuntu2204 was on 6.10.0 and ubuntu2404 used
the OS Qt (~6.4, dynamic) -- the latter is now a static 6.9.1 build like the
others, so every image ships a self-contained, identical-Qt viewer.
- Remove the HDF5/libtiff/libjpeg-turbo/Eigen source builds + their system -dev
packages + the stale /opt/* CMAKE_PREFIX_PATH/PKG_CONFIG_PATH entries.
- nasm: now needed by the project's libjpeg-turbo ExternalProject; added to
ubuntu2404 (the others already had it).
- Standardize the Qt configure flags across all four (xcb, xcb_xlib=OFF,
no Wayland -- the qtwayland module was never built, so wayland_client=ON on
ubuntu2204 was a no-op).
Untested here (no Docker on this host) -- needs a build in each image; the
ubuntu2404 static-Qt dep list in particular should be sanity-checked.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add the platform packaging the viewer was missing so it can ship as a .dmg
(macOS) or installer (Windows):
- viewer: set MACOSX_BUNDLE (a .app bundle on macOS) and WIN32_EXECUTABLE
(GUI subsystem, no console window) -- both ignored where they don't apply;
install with BUNDLE/RUNTIME destinations.
- viewer: qt_generate_deploy_app_script + install(SCRIPT) to bundle the Qt
runtime at install time (windeployqt on Windows, macdeployqt on macOS).
Gated on Qt >= 6.5, which is where the OUTPUT_SCRIPT signature and the Linux
deploy path landed; with a static Qt (our Linux builds) it is a no-op.
- CPack: select DragNDrop (.dmg) on macOS and NSIS on Windows, ahead of the
Linux-only /etc/* probes; DEB/RPM path unchanged.
Verified: configures + generates cleanly on Linux with the viewer enabled
(Qt 6.4.2 -> deploy step correctly skipped).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A clean configure failed at generation:
install(EXPORT "CeresExport" ...) includes target "ceres" which requires
target "eigen" that is not in any export set.
Ceres' install(EXPORT CeresExport) is unconditional, and its ceres target
transitively links the eigen target. As a FetchContent subproject Eigen leaves
EIGEN_BUILD_CMAKE_PACKAGE OFF (it defaults to PROJECT_IS_TOP_LEVEL), so its
install(EXPORT Eigen3Targets) never runs and eigen ends up in no installed
export set. Force EIGEN_BUILD_CMAKE_PACKAGE ON so eigen is exported and Ceres'
export validates. Install/export-only change; the build is unaffected.
Verified with a clean configure (fresh CMakeCache): configure + generate now
succeed where they previously errored.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Two deps the Linux build picked up from the system were absent on Windows.
Bundle both, unconditionally (matching how libtiff/FFTW are vendored), so the
tree builds without system Eigen/JPEG:
- Eigen 5.0.1 via FetchContent with OVERRIDE_FIND_PACKAGE, so every
find_package(Eigen3) -- ours, Ceres', and ffbidx' -- resolves to this copy and
the requested 3.4 version is satisfied by the newer major. ffbidx's bundled
eigen submodule is disabled (GIT_SUBMODULES "" on fast-indexer) so it no longer
creates a duplicate Eigen3::Eigen target. Verified on a CUDA build: Ceres 2.3.0,
the analysis libs, and ffbidx's CUDA code all compile against 5.0.1.
- libjpeg-turbo 3.0.4 via ExternalProject (upstream discourages add_subdirectory);
built+installed static and imported as JPEG::JPEG, replacing find_package(JPEG)
in preview/. SIMD is lazy: WITH_SIMD=ON + REQUIRE_SIMD=OFF means NASM-accelerated
when nasm is present, otherwise a warning and a scalar build (no hard failure).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The recurring goal is a Windows jfjoch_viewer built with MSVC *and* CUDA ON
(GPU processing is wanted, not a CPU-only fallback); the non-CUDA path is the
macOS fallback. Also note the three deps a self-contained Windows build still
needs but FetchContent does not auto-provide: ZLIB (bundle zlib-ng as
ZLIB::ZLIB), libjpeg-turbo (ExternalProject), and Eigen (header-only, also
needed by Ceres) -- each guarded so the Linux build is unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Two spots used POSIX-only path logic that breaks on Windows:
- dataset_name() located the basename with rfind('/'), which misses
backslash separators, so a C:\...\foo_master.h5 file prefix kept the
whole directory. Use std::filesystem::path::filename() instead.
- Legacy-format data-file resolution joined paths with
fmt::format("{}/{}", ...), producing mixed \/ separators and prepending
the master directory even to absolute link targets. Reuse the existing
ResolveRelativeToMaster() helper, which joins via std::filesystem and
leaves absolute targets untouched.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
FFTW exposes fftw3.h only via $<INSTALL_INTERFACE:include>, so consuming
fftw3f from the build tree (FetchContent) leaves FFTIndexerCPU.h unable to
find the header. A system-installed fftw3.h masks this on Linux, so it only
bit on Windows; add the source-tree api/ dir to fftw3f's interface includes.
Also two viewer-reachable warnings:
- time_utc.h (C4477): %03ld was fed a chrono milliseconds::rep (64-bit), not
a long; cast the 0-999 value to int and use %03d.
- HDF5Objects.h (C4700): value-initialize the scalar read buffer.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
libtiff's webp and lerc codec options default ON whenever their library is
found on the build host, dragging in libwebp + libsharpyuv (webp) and libLerc.
We only need DEFLATE (zlib) + the internal LZW codec, so turn both OFF.
httplib likewise auto-enables Brotli content-encoding when system Brotli is
present; gzip/zlib is enough for the broker, so disable it.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
StreamWriter.cpp was compiled into both JFJochWriter and JFJochStreamWriter,
so JFJochWriter still transitively pulled in image_puller headers via
StreamWriter.h. Compile it only into JFJochStreamWriter (which already
links JFJochImagePuller); targets needing the streaming writer (jfjoch_writer,
jfjoch_test) link that lib, while JFJochWriter consumers (viewer, tools,
ImagePusher) no longer drag in the puller. Also drop a stray duplicate
HDF5DataFile source listing.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Address portability issues found building jfjoch_viewer with MSVC:
- common/{ADUHistogram,AzimuthalIntegrationProfile}.h and
image_analysis/spot_finding/StrongPixelSet.h only need DeviceOutput,
so include fpga/pcie_driver/jfjoch_fpga.h (plain-C, self-contained)
directly instead of acquisition_device/AcquisitionDevice.h, which
dragged <unistd.h> into the viewer tree.
- common/time_utc.h: guard gmtime_r/timegm/localtime_r with the MSVC
equivalents (gmtime_s/_mkgmtime/localtime_s) under _WIN32; drop the
duplicated includes and add the headers used directly.
- gemmi_gph/gemmi/utf.hpp: vendor the upstream gemmi header; fileutil.hpp
includes it on Windows for UTF8_to_wchar but it was never vendored.
- writer/HDF5Objects.cpp: ExtractFilename returns path.filename().string()
(std::filesystem::path has no implicit conversion to std::string on
Windows, where it is wchar_t-based).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Switch the libtiff FetchContent from the personal GitHub mirror to the
upstream gitlab repo and bump v4.6.0 -> v4.7.1 -- cleaner provenance; the
mirror was only ever a network-reachability workaround.
Verified on Linux: fetches, builds static (libtiff.a/libtiffxx.a), and
jfjoch_viewer links cleanly.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
FFTW selects SIMD codelets at runtime via cpuid, so enabling AVX2 does not
require an AVX2 CPU -- it just speeds up the CPU FFT fallback indexer on
capable hardware and falls back to SSE2/scalar otherwise. Arch-guarded to
x86_64/AMD64 (ARM would need ENABLE_NEON). AVX-512 left off on purpose:
it's x86-64-v4 (not our v3 target), the FFT gain over AVX2 is marginal,
older Intel downclocks on it, and it's the riskiest to build under MSVC.
Verified on Linux: SSE2/AVX/AVX2 codelets compile, libfftw3f.a stays a
single static archive, jfjoch_viewer relinks cleanly.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Both are leaf deps (JFJochPreview / JFJochIndexing) that only our own code
looks for, so building them ourselves removes the system-package lottery and
gives a reproducible, statically-linked build on every platform.
- libtiff: FetchContent, library only (jbig/zstd/lzma/jpeg/old-jpeg/tools/
tests off). The C++ binding (TIFF::CXX / libtiffxx) is packaged
inconsistently across distros -- missing on Rocky 9 -- and absent on
Windows, so find_package(TIFF COMPONENTS CXX) was unreliable; that call is
removed and JFJochPreview links the tiff/tiffxx targets directly. GitHub
mirror because upstream (gitlab) is unreachable from some restricted hosts.
- FFTW: FetchContent single precision (ENABLE_FLOAT) from the release tarball
-- the git repo ships no pre-generated codelets (needs OCaml genfft). It's
now always available, so the CPU FFT indexer is always built and
JFJOCH_USE_FFTW always defined; the "FFTW disabled" path is gone. Static
(libfftw3f.a) via the global BUILD_SHARED_LIBS OFF.
Verified on Linux: jfjoch_viewer builds and links libfftw3f.a + libtiff*.a,
all static.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Under JFJOCH_VIEWER_ONLY, only the viewer's transitive deps are built, so
sls_detector_package (detector_control/receiver) and catch2 (tests) are
never used -- and sls does not configure under MSVC, which is the whole
point of the viewer-only mode. Skip fetching just those two; zstd, hdf5,
spdlog, libzmq and httplib are still required (JFJochReader links httplib).
Verified: cmake -DJFJOCH_VIEWER_ONLY=ON configures with sls/catch2 absent
and `make jfjoch_viewer` still links.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
CMake >= 4.0 (4.3.1 ships bundled with Visual Studio 2026) makes any
cmake_minimum_required(VERSION < 3.5) a fatal error. The fetched libzmq
still declares VERSION 3.0.2, which aborts configuration before our own
CMakeLists gets a say. Set CMAKE_POLICY_VERSION_MINIMUM=3.5 before the
FetchContent_MakeAvailable calls so those subprojects configure; the
variable is simply unused (harmless) on CMake < 3.30.
Verified against CMake 4.3.1: the real libzmq source fails without it and
configures with it, and an in-file SET() propagates into the
add_subdirectory child exactly as a -D cache entry does.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
New option (default OFF) that compiles only jfjoch_viewer and the
libraries it transitively links -- common, image_analysis, writer,
reader, preview, image_puller, frame_serialize, gemmi_gph, compression,
jungfrau, and the OpenAPI model (JFJochAPI) -- skipping the Linux-only
online stack (broker service, receiver, fpga, acquisition_device,
detector_control, image_pusher, xds-plugin, tests, tools) and the
frontend. This is the standalone build path for the cross-platform
viewer.
JFJochAPI is the only piece the viewer needs from broker/, so the broker
service library and executable are gated behind NOT JFJOCH_VIEWER_ONLY.
The full build and JFJOCH_VIEWER_BUILD (viewer on top of the full build)
are unchanged -- that path is the verbatim ELSE() branch.
Verified on Linux: cmake -DJFJOCH_VIEWER_ONLY=ON configures and
`make jfjoch_viewer` links cleanly with the online stack absent.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Make the build less hostile to MSVC (needed for the viewer port) and
align the CUDA standard with C++.
- Remove the CMAKE_C/CXX_FLAGS_RELEASE overrides: -O3/-DNDEBUG only
duplicate CMake's own GCC/Clang Release defaults, and the SET()
clobbered the MSVC defaults. The lone meaningful flag,
-Wno-deprecated-enum-enum-conversion, merely silenced warnings from
the vendored Xilinx ap_private.h in the FPGA path; with no -Werror
it is just log noise, so drop it.
- CMAKE_CUDA_STANDARD 17 -> 20 (+ STANDARD_REQUIRED); CUDA >= 12.8
already supports C++20.
- Drop the file-scoped -Ofast on JFPedestalCalc.cpp /
JFConversionFloatingPoint.cpp: it is GCC-only and reaches the MSVC
viewer via JFJochCommon -> JFCalibration. Those files now build at
plain -O3.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The bare python3 is often too old for the Sphinx build. Auto-select the
newest python3.13/3.12/3.11/3 found on PATH, still allowing $PYTHON to
override.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
When only one azimuthal phi bound is entered, fill the other so the
sector is well-defined and the server accepts it: a missing phi_min
becomes 0 and a missing phi_max becomes 360. Leaving both empty still
means a full ring.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Surface the optional azimuthal phi-sector bounds (phi_min_deg/phi_max_deg)
as editable columns, so a sector can be set from the web UI, not only the
viewer. Also fix the Q_max row's d header, which read d_max but is d_min.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The ROI bound editors now have a white background, a capped width and
right-aligned text, which reads better for numeric entry.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Restore the ROI-to-mask action on the new list: "Add to mask" and
"Subtract from mask" buttons rasterise the selected ROI into the user
mask (set or clear), through the same UpdateUserMask_i path. The ROI is
evaluated with per-pixel resolution and phi from the geometry, so box,
circle and azimuthal (sector) ROIs all map correctly.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
With the scratch ROI panel gone, delete the now-orphaned
JFJochViewerImageROIStatistics(_Box/_Circle) widgets and the worker's
unused scratch-ROI plumbing (SetROIBox/SetROICircle, the ROIElement
member, AddROIToUserMask/SubtractROIFromUserMask). ROI-to-mask, if wanted
later, should act on the selected list ROI.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Clarify in FPGA_DATA_ANALYSIS.md that the ROI and azimuthal definitions
are also evaluated on CPU via the shared image_analysis library, so they
apply to the DECTRIS SIMPLON (EIGER) path that has no FPGA, not only the
FPGA-accelerated JUNGFRAU/PSI path. Document the three NXmx writer formats
(Legacy/VDS/Integrated) and the two acquisition workflows in CLAUDE.md.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Two Mask-menu entries read a 16-bit TIFF (via ReadTIFFFromString16) and
apply it as the user mask: "replace" overwrites the current mask, "add"
unions the TIFF into it. The TIFF must match the detector dimensions; any
non-zero pixel masks. Both go through UpdateUserMask_i like the other
mask edits.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add Download and "Upload to server" buttons to the ROI panel. The HTTP
reader gains GetROIDefinitions (GET /config/roi) and UploadROIDefinitions
(PUT /config/roi), converting between ROIDefinition and the generated
Roi_definitions model (including the optional azimuthal phi sector), the
same shapes OpenAPIConvert uses on the server. Download applies the
fetched ROIs through SetROIDefinition; upload pushes the current ones.
Both are no-ops unless the viewer is connected to a broker.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The interactive shift-drag (box) / shift+ctrl-drag (circle) now creates a
new persistent ROI in the list instead of feeding the old single-ROI
scratch panel. The base emits a roiScratchDrawn hook on release; the
diffraction image turns the drawn shape into a named ROI committed via
SetROIDefinition.
The old JFJochViewerImageROIStatistics scratch panel and all its wiring
(box/circle configuration, single-ROI result, add/subtract user mask) are
removed from the side panel and window; the ROI list is now the single
source.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The ROI panel now shows editable numeric fields for the selected ROI,
labelled by type: box min/max X/Y, circle centre/radius, or azimuthal
Q-range and phi sector. Editing a field rebuilds that ROI and commits it
through the same SetROIDefinition path, so all three types can be created
(via +) and dialled in by typing, not only by dragging.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Azimuthal ROIs now show discrete grab handles on the selected ROI: the
inner/outer arc (resize Q/d) and, for a sector, the two phi edges
(rotate). Editing is by clicking a handle, with a generous tolerance,
which fixes the previously near-impossible phi-edge grab. Clicking the
(large) interior of an azimuthal ROI now only selects it and lets the
view pan, instead of capturing the gesture.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
