v0.4.3 — smooth stack scrolling

v0.4.3 — smooth stack scrolling

Scrolling through image stacks no longer re-decodes a file for every step. The radiology
report's "scrolling feels jerky and skips frames" complaint is fixed in the decode pump, with
a regression test that fails without the change.

• Decoded-frame cache (48 slices or 256 MB, whichever binds first; farthest-from-screen
  evicted): stepping into a decoded slice shows instantly, and scrolling back over shown
  slices costs a copy, not a file read and a decompress. Cleared on any series or folder change.
• Four-slice look-ahead on a dedicated prefetch pool keeps the next few slices decoded
  ahead of the wheel; the requested slice still never queues behind speculative work.
• Whole-notch wheel handling: notched wheels behave exactly as before; high-resolution
  wheels and trackpads accumulate to real notches instead of teleporting dozens of slices per
  flick, and trackpad pixel deltas now carry direction instead of always reading as one step down.
• Per-series annotation cache: the sidecar JSON is read once per series and invalidated on
  save, instead of being re-read on every presented slice while you scroll.
• The window/level maths is unchanged in output: the branchless form of the three-way clamp was
  verified byte-identical to the previous loop over 104,994 differential cases including
  degenerate windows and boundary pixels, on top of the pinned core checks.

What is NOT verified

• The exe has never been launched on a Windows machine (docs/VALIDATION.md unchanged on that
  point). CI compiles it and runs the test suite offscreen; no human has scrolled with it.
• Scroll feel on real hardware (notched vs trackpad) has not been measured on a device; the
  wheel-remainder behaviour is covered by the unit test at the scheduling level only.
• One offscreen test run on the Linux Pi segfaulted once and never recurred across 17
  subsequent runs; the cause is unknown and unreproduced.
• Anything VTK remains behind the build flag and is not in this package.

v0.4.2 — overlay text off the GL path, VTK behind a flag

Clivus v0.4.2. Free software (GPL-3.0-or-later); research and engineering tooling, not a certified
medical device, and nothing here has been validated for diagnosis.

0.4.1 answered four issues a radiologist hit in 0.4.0. Three of them were reproduced and fixed against a
test. The fourth — on-screen text coming out garbled — never reproduced here, so 0.4.1 shipped a layout
fix that reduced the damage without touching the cause. This release attacks the cause.

What changed

Overlay text no longer goes through the GPU. The corner blocks, measurement labels and ROI statistics
used to be painted inside the GL paint pass. On the reporter's machine individual glyphs came out sheared
into diagonal hatching while every other piece of text in the app stayed crisp, which points at the GL
glyph path rather than at the font. Those overlays now live in a transparent child widget layered over
the canvas and are painted by the same raster engine as the rest of the interface: no GL text, no
backend-specific glyph rasteriser. The overlay takes no mouse input, so dragging to window, panning and
measuring all still reach the canvas underneath.

A new overlay_widget test pins the arrangement: the child exists, covers the canvas exactly, ignores
the mouse, never takes keyboard focus, paints the corner text through the raster engine — and paints
nothing once the frame is gone. Removing the child makes the test fail, which is the only reason to
believe it protects anything.

What the test cannot tell you is whether the reporter's specific Windows backend is now happy. That
needs their machine, and it is the one claim this release deliberately does not make.

The VTK work lands, switched off. Phases 1–4 of the migration are in the tree: the volume and frame
handover with a DICOM-correct value-of-interest lookup table, a frame-based 2D canvas, three linked MPR
planes, GPU volume rendering, and a View menu entry that opens them. None of it is in this exe. It builds
only with -DCLIVUS_BUILD_VTK_CANVAS=ON; the app keeps drawing with the original canvas, and the legacy
canvas stays the default until pixel parity is proven.

Landing it now bought the thing it never had: compilation. Against VTK 9.3 the handover test passes, and
the parity gate — the legacy render() bytes compared with the VTK pipeline, normal and inverted, narrow
and wide windows — matches within one grey level with colour bytes exact. The Qt widgets remain
uncompiled anywhere, because Debian's VTK is built against Qt 5 and this app is Qt 6; that needs a VTK
built with Qt 6 on the Windows or macOS builder.

What is not verified

• The garbled-glyph report itself. The code path is gone; the reporter's machine has not seen this
  build. Nothing here should be read as "that backend is fixed".
• The packaged exe has not been launched on Windows hardware. CI compiles and packages it; the
  smoke test on a real desktop is still the open item in docs/VALIDATION.md, exactly as in 0.4.1.
• The VTK widgets. Reviewed line by line, never compiled: no host available to us has a Qt 6 VTK.
  Experimenting with them is not possible in this build anyway.
• The parity gate has a blind spot. It cannot see a width vs width - 1 range error — that
  mutation passes with a max difference of one grey level, and it is precisely the DICOM difference the
  migration doc cites to justify its own lookup table. Gross errors it does catch: an ignored inversion
  fails at 255 levels across 3069 of 3072 pixels. Both facts, with the mutation runs, are in
  docs/VTK-INTEGRATION-EVIDENCE.md; testing the lookup table's bounds directly is follow-up work.

Pi build for this release: 285/285 objects, ctest 31/31 offscreen, including the new target.

---

Package note: the zip was refreshed after publication so that READ-ME-FIRST.md tells you to run the included vc_redist.x64.exe first on a machine that has never had a C++ application installed (clivus.exe imports MSVCP140.dll and VCRUNTIME140.dll). The executable is unchanged.

v0.4.1 — folding groups, a window that stays put, no stale frames, legible overlay

Clivus v0.4.1. Free software (GPL-3.0-or-later); research and engineering tooling, not a certified
medical device, and nothing here has been validated for diagnosis.

This release is the answer to four issues a radiologist hit in 0.4.0, plus one follow-up those photos
turned up. Each fix has a test that was checked to fail without it; the verbatim runs are in
docs/UNIT-6-EVIDENCE.md.

What changed

Groups fold. The browser already split a folder into patient and study headers; they could not be
closed, so forty studies meant scrolling past several hundred series. Click a header (or put the caret on
it and press Left/Right) and everything under it gets out of the way. Folding is navigation, not closing:
the image you are reading stays on screen, no slice is decoded, and the caret moves to the header rather
than to another series. Fold state is keyed by patient ID and study UID, so a scan batch that rebuilds
every row cannot lose it, and two patients sharing a name cannot share a fold. A search shows what it
matches even inside a folded group, and clearing the search puts the folds back.

The window you choose stays chosen. setFrame() used to re-derive window/level from every frame that
arrived, so stepping one slice threw the adjustment away — the comment on the function said as much. The
frame's own default now applies only when the image changes identity: a different series, or a different
matrix. Stepping forward, backward, or re-decoding a slice keeps your window; Reset View (double-click or
R) still returns it to the image's full range.

Scrolling stops flashing frames you already left. Three scheduling defects, measured with counters
that now live in the code and a probe that runs headless:

• a decoded frame was presented even when the wheel had moved on. A 12-step burst presented slice 2 (an
  abandoned target) and stayed on it — the wheel said 12, the screen said 2. Now it presents only what
  was the target when it arrived, then the current one.
• the request path decoded a slice the speculative pool was already decoding: two reads of the same file,
  two presentations of the same frame. It now waits for the speculative decode.
• a step that was waiting on the prefetch did not advance the wheel's target, so a fast spin dropped
  every second notch. Steps are measured from the target now.

On a Pi 5 against local disk, a 15-step walk served 14 of 15 steps from the speculative decode with a
median request→present under the probe's 20 ms sampling granularity. Those are decode-and-schedule
numbers, not frame-rate claims: this machine has no GPU-bound paint path to measure.

The corner overlay is legible. Two photographs of the running app showed two lines of 8 pt grey text
over a dark image; local OCR read the characters correctly, so it was size and contrast, not encoding.
The font floor is 10 pt (ceiling 18), and each corner block gets a backing plate sized to its text.
Measured over the left block on mid-grey: contrast 1.84:1 → 6.09:1. Both images are in
docs/img/overlay-legibility-*.png, painted by the same paintOverlays() the canvas calls.

The overlay blocks also no longer share one full-width rectangle: a long series description used to run
underneath the window/level block, and both blocks were drawn into their own measured box, which re-wrapped
the text at a narrower width and clipped it.

Verification

• 30 test targets green on this host (26 existing plus browser_groups, overlay_layout, scroll,
  window_level). Baseline before the work was 25/26 — cine is timing-sensitive on four cores and
  failed once on an untouched tree, then passed.
• Every behaviour above has a test that was disabled in place, rebuilt and re-run; the failing line is
  quoted in docs/UNIT-6-EVIDENCE.md.
• Windows: windows.yml (core + pixel math) and windows-app.yml (full GUI, packaged folder) run on
  every push and on demand. This tag's Windows folder is attached below.

Not verified, stated plainly

• The garbled-text report itself. The corner overlay was genuinely hard to read and is fixed; whether
  that is what the reporter saw is unconfirmed. If text still looks wrong on their machine, the useful
  question is which text, and whether the characters are wrong or the layout is.
• Nobody has launched a packaged Windows build on Windows hardware. The CI runner has no GPU, so its
  --bench smoke step produces no output and says nothing about fps.
• Scrolling was measured on a Pi 5 with local disk. A Windows workstation's paint path, DPI scaling and
  GPU are not covered by any number in this release.
• The fold gesture was driven through real QMouseEvents under the offscreen platform, not by a human
  clicking on a desktop.
• No clinical validation, no regulatory assessment, no diagnostic claims.

v0.4.0 — grouped browser, progressive import, honest pixel readout

Clivus v0.4.0. Free software (GPL-3.0-or-later); research and engineering tooling, not a certified
medical device, and nothing here has been validated for diagnosis.

What changed

The series browser shows the study, not just a list. Patient header, study header, series rows
with thumbnails. Two patients whose series share a description were previously indistinguishable,
because the boundary between them was not on screen. A group header opens its first series.

Series appear while the folder is still being scanned. The walk reports what it has found every
64 objects, so a large nested folder shows something usable immediately instead of an empty pane until
the last header is parsed. Cancelling keeps the series found so far instead of discarding a nearly
finished scan.

Grouping is keyed on (StudyInstanceUID, SeriesInstanceUID). A malformed export that reuses one
series UID across two studies used to produce a single row carrying the first patient's identity and
every file. Now a UID proven to carry two patient identities is split, and the count is reported.
Objects with no SeriesInstanceUID — two of the committed corpus files are like this — are kept in a
labelled quarantine group instead of being dropped silently.

Zoom where you are looking. Ctrl+wheel zooms about the pointer, so the pixel under the cursor stays
under it. Zoom and pan survive slice changes and reset only when the series or its matrix changes.

Drag the stack to scroll it. Middle-drag scrubs slices through the same coalesced decode path as
the wheel; left-drag stays window/level, right-drag stays pan.

Read the pixel under the cursor. Row and column, the stored value, the modality value, and a unit
only when the object earns one: HU needs a rescale pair, RT Dose reads in Gy, and an object whose values
came from a LUT reports no stored number rather than inventing one. Colour pixels say RGB.

Fixed along the way: the top-left overlay was drawn in the measurement accent colour instead of
light grey (it inherited whatever pen the previous drawing pass left behind); measurement labels were
clipped at the canvas edges; DICOM text was decoded as UTF-8 regardless of the charset the file
declares, so Latin-1 names rendered as replacement characters; a cache schema bump dropped its tables
after creating them, which broke the first save after an upgrade.

Verification

• 27 test targets green: 26 in the full build plus the core-only parity gate. Every behaviour above
  has a test that was checked to fail without its change — see docs/UNIT-*-EVIDENCE.md and
  docs/PIXEL-POINTER-EVIDENCE.md for the verbatim runs.
• Built and tested on Debian 13 / aarch64, Qt 6.8.2, DCMTK 3.6.9; the macOS lane builds with
  DCMTK 3.7.1. The 3.6 build is what keeps the two DCMTK generations honest.
• A Windows build accompanies this tag: clivus-0.4.0-windows-x64.zip, built by
  .github/workflows/windows-app.yml (manual dispatch) from this tag's commit on 2026-10-25 with MSVC and
  Qt 6.8.1 — 26/26 ctest targets green. Unzip it and run clivus.exe; it carries the Qt and DCMTK DLLs,
  the corpus, the assets and the licence texts. That workflow is still manual-dispatch: tagging alone does
  not build Windows.

Not verified, stated plainly

• Nobody has launched a packaged Windows build on Windows hardware.
• No clinical validation, no regulatory assessment, no diagnostic claims.
• The slice-step latency improvement from separating speculative decode from the foreground pool has
  no measurement behind it: that bench needs a machine with a working GL context and was not run.
• Rendering, DPI scaling and font behaviour were checked by painted-image tests and by the report
  author's photographs, not on a calibrated display.

Upgrading

The index cache schema is now version 5. An older cache is dropped and rebuilt the first time a folder
is opened, so the first open after upgrading is a cold scan. Patient names and identifiers are still
never written to the cache.

v0.3.0 — de-identified export, image and series PNG export

Getting data out, without the patient coming along

Export a de-identified copy

File ▸ Export de-identified copy… writes a second copy of the open folder with identity removed
from the metadata, then re-reads every file it wrote and searches for the original values. The
report says Verification: PASSED only when none survive; a copy that fails is reported as a copy
you should not share.

Always removed or replaced: Patient Name → ANONYMOUS, Patient ID → generated, birth date/time,
other patient IDs and names, address, telephone numbers, patient comments, accession number, study
ID, institution name/address/department, referring/performing/reading physicians, operators, station
name, device serial number, and free-text study/series descriptions and protocol names.

Your choice: remap Study/Series/SOP Instance UIDs (references followed through nested sequences),
shift dates by one random offset per export (intervals preserved — a 2-day gap stays 2 days),
remove private vendor tags (on by default — 179 of them in the committed corpus alone), remove
patient sex.

Safety properties: the destination must be empty, so verification covers exactly what this run wrote;
non-DICOM files are skipped rather than copied; a UID element is never rewritten while the dataset is
being walked; pixel data is written back byte-identical in its original transfer syntax, so the copy
still measures the same.

Export images

• Export image as PNG… — the canvas exactly as displayed at the current window/level, no overlay
  text. Refuses with a reason instead of writing a black file when there is no GL context.
• Export series as PNGs… — every slice at the current window/level, on a worker, cancellable;
  slices that fail to decode are counted and named rather than written as blank frames.

What this release does not claim

• Pixel data is untouched, so text burned into an image (annotations, ultrasound overlays,
  photographed films) survives. Clivus does no OCR and cannot detect it. Review the images yourself.
• Not a legal determination. De-identification ≠ anonymity: a rare diagnosis, a distinctive
  implant, a face in a reconstruction can still identify someone. No HIPAA/GDPR/PS3.15 conformance
  assessment has been performed; the tag set is the core identity list, not the full basic profile.
• No real patient study has been de-identified in testing — identifiers were fabricated on synthetic
  objects.
• Nobody has launched the packaged app on Windows hardware. CI builds, tests (23 targets) and
  packages it; docs/VALIDATION.md records that as unrun.
• Not a medical device.

Install

Unzip anywhere, run clivus.exe. LICENSE, THIRD-PARTY.md and assets/ ship beside the binaries.

Provenance

Commit d9dfa85 (tag v0.3.0), 23 test targets green on Linux and on the Windows CI runner
(run 40053785138). The first Windows run failed one test: it assumed the second series in the list
had multiple frames, which depends on directory order — fixed to select a multi-frame series
explicitly rather than relying on platform sort.

v0.2.0 — DICOMweb access, saved measurements, cine and MIP/MinIP

The three gaps that mattered

This release closes the three capabilities the comparison against paid viewers put at the top of
the list: reaching a study over the network, keeping what you measured, and watching/reformatting a
stack properly.

Open a study over the network (DICOMweb)

File ▸ Open from server… — enter a DICOMweb base URL, filter by patient / date / accession /
modality, pick a study, and it downloads into its own cache folder and opens like a local one.
QIDO-RS for search, WADO-RS for retrieval, one instance at a time with progress and a working
Cancel. A study whose instances cannot all be fetched is reported as an error and is never opened
as if complete. No C-FIND/C-MOVE, no upload, no worklists; single-part WADO replies only.

Regions of interest that stay measured

Rectangle and ellipse ROIs (Tools menu, Ctrl+R for rectangle) report mean, population SD, min, max,
pixel count and mm² area — the area only when the file carries Pixel Spacing, never invented. An
ellipse counts the pixels it covers, not π·a·b. Regions are stored per series per slice in a local
JSON sidecar keyed by Series Instance UID: geometry and tool type only, no patient name, no paths.
Statistics are recomputed from the pixels on load, so a hand-edited file cannot make the numbers
lie. File ▸ Export measurements… writes CSV.

This is a private sidecar, not DICOM SR/GSPS — no other viewer will read these annotations. Distance
and angle measurements remain session-only.

Cine and reformats

Space loops the series (2–30 fps with [ and ]), advancing from what is on screen so a slow disk
stretches the loop instead of skipping frames; any manual step stops it. The MPR window gains a
Reformat row: nearest neighbour (invents nothing) or linear interpolation between adjacent slices,
and single-slice / MIP / MinIP over a slab thickness in millimetres, clipped at the stack edge.

What this release does not claim

• Nobody has launched the packaged app on Windows hardware. CI builds, tests (21 targets) and
  packages it; docs/VALIDATION.md records that as unrun.
• No real PACS contacted: TLS with institutional certificates, OAuth/SMART flows, multipart WADO
  replies and paging are untested; documented in docs/VALIDATION.md.
• MPR remains research/experimental. Interpolation is across the slice axis only. No oblique
  reformats, no volume rendering.
• Not a medical device. Nothing here is validated for clinical decisions.

Install

Unzip anywhere, run clivus.exe. LICENSE, THIRD-PARTY.md and assets/ ship beside the binaries.

Provenance

Commit 9b98a55 (tag v0.2.0); 21 test targets green on Linux and on the Windows CI runner
(run 40041232270, green on the first attempt — unlike v0.1.5's four MSVC-only failures).

v0.1.5 — privacy and cache correctness, manual full-text search, honest validation record

What's new

The index cache no longer travels with your studies, and no longer remembers who the patient is.

• Moved out of the DICOM folder into the OS application cache directory (%LOCALAPPDATA%\Clivus\index, ~/Library/Caches/Clivus/index, $XDG_CACHE_HOME/clivus/index), named from a hash of the folder path. Copying a study no longer copies its metadata. The hash is documented as correlation-resistant at best — not anonymity.
• Patient names are gone from the cache (schema v4). Nothing in the UI reads a patient name from it. An older cache is dropped at open rather than migrated, so stale sensitive columns don't sit on disk; legacy in-folder .clivus-index.sqlite files are deleted on sight.
• Every database operation that affects correctness is now checked; saves run in a transaction and roll back on failure, a corrupt cache is rebuilt once, and an unusable cache directory degrades to an uncached scan. View ▸ Clear index cache forgets the open folder and says so honestly if Windows has the file locked.

Manual search finds text inside articles, not just chapter titles. Matching runs on markup-stripped body text, case-folded, with an excerpt shown on the matching row and a jump to the first hit. The manual's stale "measurements and MPR are not supported" text is corrected — measurements work, MPR is documented as experimental.

Documentation that doesn't overclaim. New docs/PRIVACY.md (what is stored, where, how to clear, and the fingerprint's known limitation) and docs/VALIDATION.md (what is verified versus not, with numbered Windows smoke-test steps). README hero, welcome and About images are now real captures produced by the application itself.

What this release does NOT claim

• The packaged app has not been launched on Windows hardware. CI builds, tests and packages it; nobody has double-clicked it. docs/VALIDATION.md records this as unrun.
• No high-DPI/multi-monitor/GPU matrix, no large clinical studies (the committed corpus is synthetic).
• Not a medical device; nothing here is validated for clinical decisions.

Known limitations

• MPR is first-round: nearest-neighbour, no oblique reformats, no 3D volume rendering.
• Codec support depends on the DCMTK build: RLE, JPEG, JPEG-LS, JPEG 2000 where present.
• Cache fingerprint = file count, newest mtime, total size: a file replaced with identical size and timestamp is not detected. Clear index cache forces a rescan.
• No PACS/DICOM networking, no anonymisation tools, no annotations beyond distance and angle.

Install

Unzip anywhere, run clivus.exe. No installer or admin rights. LICENSE, THIRD-PARTY.md and assets/ ship beside the binaries.

Build provenance

Commit b03506f (tag v0.1.5), 16 test targets green on Linux and on the Windows CI runner. This cycle's Windows CI caught four real defects invisible to Linux: the <windows.h> min/max macro collision, POSIX-only setenv in a test, a chmod-based test that silently tested nothing on Windows, and the open-file deletion behaviour of clearCache (which was also a real user path — clearing during a scan).

v0.1.4 — the Clivus identity

What's new

The Clivus logo and icon set, integrated.

• Welcome screen and About show the full Clivus lockup — the teal mark and wordmark as designed, scaled for the dark workspace (132 px on welcome, 96 px in About).
• Window and taskbar icon come from the shipped 256 px icon.
• The executable's own icon (Explorer, pinned taskbar, Alt-Tab) comes from the multi-size .ico; Windows shows it before the app even starts.
• assets/ travels with the binaries, so the released folder shows the real logo with no setup step. A source build without the folder falls back to the built-in mark rather than breaking.

No viewer behaviour changed in this release; everything from v0.1.3 (measurements, three-plane MPR, the first-trial fixes) is included.

Known limitations

• MPR is first-round: nearest-neighbour reslice, no oblique reformats, no 3D volume rendering.
• Codec support depends on the DCMTK build: RLE, JPEG, JPEG-LS, JPEG 2000 where present.
• No annotations beyond distance and angle; no PACS/DICOM networking.
• Research and education only. Not a medical device; not validated for clinical decisions.

Install

Unzip anywhere and run clivus.exe. No installer, no admin rights. LICENSE and THIRD-PARTY.md ship alongside the binaries as the GPL requires.

v0.1.3 — measurements, three-plane MPR, and the first-trial fixes

What's new

Measurements. A Measure tool (toolbar, Tools menu, M): left-drag draws a distance, labelled in millimetres from the object's Pixel Spacing; Shift+click three points draws an angle (second click = the vertex). Objects with no usable spacing say spacing unknown — no invented numbers. Measurements belong to the slice they were drawn on; Clear measurements in Tools wipes them.

MPR (research/experimental). View ▸ MPR opens axial / coronal / sagittal planes resliced through the study's own geometry: each plane scrolls on its own strip or wheel, window/level is shared, and hairline crosshairs follow the reference position on the other two. Nearest-neighbour reslice, labelled as such — no interpolated tissue between slices. The entry disables itself for studies whose objects do not all report position and orientation.

From the first radiology trial of v0.1.2:

• Images no longer render upside down (the texture's vertical mapping was inverted).
• Subfolder scanning no longer aborts on a bad entry — a permission-denied folder early in the walk used to drop everything after it.
• Windows text no longer garbles (/utf-8 for MSVC; the middle dots and dashes in series rows were being compiled as cp1252 bytes).
• Overlay text no longer looks shredded (it was drawn twice, one pixel apart).
• "Pointer" is now "Browse", with a tooltip that says what it does.
• Drop a folder or DICOM file anywhere on the window to open it.
• The slice strip jumps to the slice you click and scrubs while you hold.
• Smooth scrolling: the next slice in your scroll direction is pre-decoded, easing the stutter and skipped frames.

About/version. About is now a proper panel (mark, version, repository, licence, acknowledgments, research-use disclaimer), and the app version finally matches the release tag (0.1.3).

Known limitations

• MPR is first-round: nearest-neighbour, no oblique reformats, no 3D volume rendering.
• Codec support depends on the DCMTK build: RLE, JPEG, JPEG-LS; JPEG 2000 where present. JPEG-LS near-lossless sample objects in the test corpus are meta-header-only and won't scan.
• No annotations/clinician tools beyond distance and angle; no PACS/DICOM networking.
• Research and education only. Not a medical device; nothing here is validated for clinical decisions.

Install

Unzip anywhere and run clivus.exe. No installer, no admin rights. LICENSE and THIRD-PARTY.md ship alongside the binaries as the GPL requires.

v0.1.2 — palette color and LUT sequences decode

The two remaining "decode as stored values" gaps are closed — Clivus now shows what the file's own tables say, everywhere.

Research tool, not a medical device. Research and educational use only.

New in v0.1.2

• PALETTE COLOR: palette-indexed objects map through the file's Red/Green/Blue LUT tables at decode time and render as true display RGB — no more stored-values-through-a-greyscale-window. Indexes beyond the table clamp to its last entry; 8- and 16-bit entry tables both work.
• Non-linear Modality LUT Sequences (PS3.3 C.11.2.1.3): applied as a real lookup, replacing slope/intercept entirely when present, exactly as the standard prescribes. PixelPaddingValue maps through the LUT as well, and the window numbers (WC/WW, min/max) describe the post-LUT values — so the visible range and the numbers agree.
• Loader tests now build palette and LUT-sequence objects directly with DCMTK and assert specific table outputs — the suite pins the mapping, not just the absence of errors.
• Documentation synced: the manual's Limitations chapter, the README loader notes and roadmap all reflect the new coverage (v0.1.0-level claims retracted, new claims test-backed).

The Windows download (no toolchain)

clivus-v0.1.2-windows-x64.zip — unzip and run clivus.exe .\corpus (test corpus included). Licences included (GPL-3.0-or-later; Qt 6 under its GPL option; LICENSE + THIRD-PARTY.md ship in-the-box).

Source: v0.1.2 @ 4d36b31

Known limitations (documented, not hidden)

• No orientation markers (needs Volume origin/orientation geometry — next on the roadmap, prerequisite for MPR/3D)
• No MPR, measurements, DICOM networking or anonymisation
• JPEG 2000 decodes where the DCMTK build carries it; macOS Homebrew's still doesn't (the vendored-DCMTK item)