Codec Strategy for Digital Pathology and Large-Format Medical Imaging Appendix

Supporting data, validation, measurement controls, and extended reference material
Version 7 · September 2026 · Dicom Systems

Designed for online publication. Supports the Executive Brief and the full whitepaper with the per-tile data behind every figure in the main text, the measurement controls in full, the verification log, open items, and the complete reference list. Sections are lettered as referenced from the brief.

Reader’s guide. If time is short: Section D explains how the decode measurements were validated against a storage-throughput artifact and how much confidence they deserve; Section J does the same for encode. Section L lists every measurement control and source check with its finding. Section M lists what remains open.

Appendix A: Test Data Provenance

A.1 The three slides

Slides were chosen for diversity on three axes simultaneously rather than for volume: two staining modalities (CD3 IHC produces sparse brown DAB on a near-white ground, materially different color statistics from H&E’s purple/pink field, and the property that surfaced the JPEG-LS finding); two morphologies (lymphoid tissue and gastric epithelium); and two vendor container formats with three internal source codecs, which matters for the argument that a legacy fleet’s native format determines the low-cost normalization path.

Figure 2. The three source slides with benchmarked regions marked. Box positions are the offsets recorded in the benchmark manifest; tile previews are downscaled from the same files the benchmark encoded rather than re-detected afterward. Tiles were extracted at 4096px and 8192px per slide.

A.2 Tile extraction and region selection

1. Minimize near-white pixel fraction defeated by flat non-white background artifacts: scan-border vignetting scores 0% “blank” while having near-zero local variance.
2. Maximize local texture/gradient defeated by adipose tissue: fat-vacuole boundaries produce abundant edges while the interiors are diagnostically empty.

The final method maximizes texture subject to a background-fraction cap (near-white, low-saturation pixels below 20% of the window), with the cap searched independently for each slide and tile size. Even the final method needed a manual override on one slide. Direct visual inspection found the detector had selected a fat-dominated CMU-2 region; correcting it changed every codec’s measured ratio by 15-25% on that slide:

Every codec changed together, which is evidence of a content property rather than a defect in one codec’s measurement, and a direct demonstration that tile selection materially affects reported ratio claims, in this paper’s numbers and plausibly in others; the manifest records which tiles were auto-detected and which were manually placed.

Appendix B

B.1 Hardware

AWS c6i.2xlarge, Intel Xeon Platinum 8375C (Ice Lake), 4 physical cores / 8 vCPU (SMT on), 16 GiB RAM, Ubuntu 24.04 LTS. AVX2 and full AVX-512 confirmed directly from lscpu (avx512f, avx512bw, avx512cd, avx512dq, avx512vl, avx512vnni, avx512vbmi, avx512vbmi2, avx512ifma, avx512bitalg, avx512vpopcntdq, eleven flags, verified rather than inferred from instance type). Both Kakadu and libjxl run-time-dispatch to SIMD-specific paths, so an unconfirmed assumption here would silently invalidate every timing number. Storage: a single 100 GiB gp3 EBS volume at unprovisioned baseline, 3,000 IOPS, 125 MiB/s. This configuration is the determining factor in two sets of controlled measurements (Sections D and J).

B.2 CPU governor, not a controllable variable on this instance

CPU governor cannot be verified or pinned on this instance: it exposes no cpufreq subsystem (the sysfs directory does not exist, there is no intel_pstate directory, and cpupower reports no active driver), because EC2 Nitro instances delegate frequency management to the hypervisor. A file-existence test guarded the harness’s governor check. It therefore failed open; it skipped silently rather than reporting the absence, so it is recorded here as an uncontrolled variable rather than a verified one. No reported value depends on it, since frequency behavior is common to every codec measured on the instance. Still, a reproduction on hardware that does expose cpufreq should pin the governor to performance and say so.

B.3 Software versions

B.4 Environment drift between the original run and the re-run

The kernel changed across a major series, and that is the one drift that matters here: writeback throttling, dirty-page accounting and I/O scheduling are precisely the subsystems under test in Section D. This was raised before any measurement. The decision was to proceed on 7.0.x and treat Condition A as a test of whether the defect persists across the kernel change. It does, comprehensively, all six clipped series reproduced at 125.1-125.7 MiB/s, so the kernel change is ruled out as a confound rather than assumed away. Unattended upgrades were found live and fired mid-check; all apt timers were masked and the pending reboot taken before measuring, so both conditions ran in a single boot session with no background package activity.

Appendix C: Measurement Protocol and Verification

C.1 Timing protocol

• 20 measured iterations + 3 warm-up per codec/image/setting; median and IQR reported, not mean and standard deviation; all 20 per-iteration samples preserved in the result JSON.
• Page cache dropped identically before each condition; input tiles staged on tmpfs in every re-run condition, so input location is held constant and only the variable under test changes.

The libjxl threading defect. –num_threads=0 disables multithreading; -1 selects the machine default (verified against libjxl’s own –help -v -v -v -v output). An early harness version passed 0, pinning cjxl and djxl to one thread and producing JPEG XL timings roughly 3× slower across the board. All JPEG XL figures are post-fix; confirmed at 8 worker threads, ~688% CPU on an 8-vCPU host. The defect was found by observing that CPU utilization did not match the expected eight-thread behavior, not by reading the flag documentation, which had been read and misinterpreted.

Process-boundary asymmetry. JPEG-LS is timed in-process via pillow-jpls; HTJ2K, J2K and JPEG XL are invoked as subprocesses. The subprocess cost was measured directly at 2.67 ms (Section J.2), 0.3% of an 8192px encode, and is disclosed rather than corrected. JPEG-LS is a structural control for decode only: its decode writes no PPM, so it legitimately served as the negative control for the decode comparison (0.4% movement between Conditions A and B). Its encode path writes 25-123 MB of compressed output inside the timing loop, so it is not a structural control for the encode comparison; Condition D’s control is JPEG XL on throughput grounds (3.3-3.7% of the ceiling), a weaker guarantee than a structural null.

C.3 Correctness verification

• Lossless correctness: direct pixel-byte comparison against source via PIL, independent of codec exit codes. All four lossless codecs pass on every tile.
• Byte-identical reproduction: before the re-run, all 36 compressed artifacts, 6 tiles × (HTJ2K, J2K, JPEG-LS, JXL lossless, JXL d1.0, JXL d3.0), were re-encoded under unchanged parameters and compared against the retained August outputs: 36/36 matched, and SHA-256 over the same 36 artifacts: 36 of 36 identical. This confirms, in one step, that the source tiles were unchanged, that no codec parameters drifted, that library versions produced identical output, and that the kernel change did not perturb the encoding. Compression ratios therefore reproduce exactly.
• In-process decoders (Condition C) were verified to be pixel-identical to the subprocess tools they replace across all 36 series before any timing was reported.
• Transcode round trip (Section J.6): SHA-256 on decoded pixels, 12/12 both directions; J2K and HTJ2K decodes of the same source pixel-identical, 12/12.

C.4 Derived sanity checks, now standing practice

Both storage artifacts in this project passed review undetected for one reason: nothing divided output bytes by elapsed time. Two guards now run on every benchmark. decode_sanity() applies two independent tests to each decode series and fails the run when both fire: (1) implied output throughput equals a device ceiling; (2) between-slide range does not exceed within-slide IQR. Validated 12/12 against the original series before use; a simpler fixed percentage-spread threshold was tried first and abandoned because it missed one clipped series at 1.81% spread and false-positived on unaffected 8192px data at 0.94%. encode_write_check() records the implied write throughput for each encode series as a percentage of the receiving device’s ceiling and classifies it as ceiling (≥90%), elevated (50-90%), or clear. Replayed against the historical data, it flags exactly the six affected HTJ2K series and nothing else.

Appendix D: The Decode Artifact: Discovery, Evidence, Control

D.1 What the original harness measured

Every decode in the original harness wrote a full-size PPM to the EBS volume: 48.0 MiB at 4096px, 192.0 MiB at 8192px, fixed by pixel count and identical for every codec. The volume sustains 125 MiB/s; at that rate, a 4096px tile takes 384.0 ms to write, and an 8192px tile takes 1536.0 ms. Sustained iterations engaged dirty-page writeback throttling, and any codec fast enough to reach that limit measured the volume’s drain rate.

Six series sat within 0.6% of the ceiling.

D.2 How it was found

HTJ2K decode fell within 0.10% across three slides differing in stain, morphology, vendor format, and 31% in compressed size, where every unaffected codec varied 3-22% with content. The decisive test was within a single codec: on BLGSP_4096, same binary, same 48 MiB output, JPEG XL lossless decoded in 916.4 ms and JPEG XL lossy d1.0 in 382.3 ms, one binary, one output size, two results 2.4× apart, with the fast one at the device ceiling.

D.3 Three conditions, one variable at a time

A ran on unmodified code, so it reproduces the defect live rather than reconstructing it. B and A differ in exactly one variable. C removes the process boundary as well as the I/O path, so a C-to-B delta is not attributable to storage alone; hence, C is reported alongside B rather than substituted for it.

D.4 Full results, median across three slides (ms)

Figure 8. Decode time by codec under the three conditions, with the storage ceiling marked. Every Condition A series terminates at the ceiling line, 384.0 ms at 4096px and 1536.0 ms at 8192px, fixed by output size. Bars are medians of 20 iterations across three slides.

D.5 Why the A/B is trustworthy

The movement pattern was predicted in writing before the run: clipped codecs move hard (HTJ2K 3.94-4.26×; lossy JPEG XL 2.09-2.69× ✓); codecs that wrote PPMs but were not clipped move a little (J2K 1.11-1.20×; JXL lossless 1.06-1.14× ✓); JPEG-LS does not move (0.47% / 0.38% ✓). JPEG-LS decodes in-process and never writes a PPM, so it incurs no write cost under either condition; had it changed, the conditions would have differed in ways beyond the I/O path. No Condition B series sits near the ceiling (nearest: JPEG XL lossless 8192 at 57.2 MiB/s, 54% below). The falsification test stated in advance, HTJ2K returning at or near 385 ms with the I/O path removed, did not occur; it returned 97.1 ms.

D.6 Condition B was still 63-67% storage for HTJ2K

Roughly 65 ms at 4096px and 230 ms at 8192px regardless of codec, against 48.0 and 192.0 MiB outputs; that is 738-835 MiB/s, the tmpfs page-cache write bandwidth plus process startup. It is the same defect as the original, six times smaller: a fixed write cost negligible for a slow codec and dominant for a fast one. This is why both B and C are reported throughout, each labeled with the operation it measures, and why neither is presented as “the” corrected figure. A faster volume would not have been the fix: it raises the ceiling without removing it, and a new plateau is indistinguishable from a real result.

D.7 The decode_sanity guard in use

In Condition B, the guard raised no clamped series and one warning, HTJ2K 8192, noise ratio 1.37, adjudicated and passed on four independent grounds: implied throughput 533.8 MiB/s is 4.3× clear of the ceiling with output in RAM; the JPEG-LS control did not change; the series changed 4.26× between conditions; and only the larger tile warned. In Condition A, it flagged five of six clipped series; the throughput test caught the miss (JPEG XL d1.0 4096) but not the noise test because one anomalous slide inflated the between-slide range, the argument for keeping both tests. Condition B was re-run in full with the guard inline: zero-clamped series, the same one warning (noise ratio 1.43), and every decode median reproduced within run-to-run noise (HTJ2K 96.5 / 358.0 ms against 97.1 / 360.6 ms; J2K 674.3 / 2559.2 against 674.5 / 2558.4).

D.8 Scope of impact

Appendix E: Lossless: Full Data Tables

E.0 Six-tile size and ratio matrix

Sizes are the reported rounded decimal MB values; ratios above are recomputed from them and exact RGB dimensions. Small differences from previously rounded ratio displays are due to rounding. Aggregate ratio is total raw bytes divided by total compressed bytes, not the arithmetic mean of ratios. JPEG XL effort 7 yields 10.6-15.0% smaller files than HTJ2K and 4.3-7.7% smaller than classic J2K. JPEG-LS compresses better than HTJ2K on TCGA, but neither beats J2K nor JPEG XL on these six inputs.

E.1 Encode, median ± IQR (ms), Condition D

Compressed output on the RAM-backed filesystem, 20 iterations. These are lower bounds on speed: a memory write remains inside the window (E.2b).

The HTJ2K IQRs are now 1-2% of the median. In the original run, they were 49% and 59% on the two 4096px series straddling the page-cache threshold (E.2); that noise was the artifact, not the codec. Condition B to D, per codec: HTJ2K 3.04-3.92× faster; classic J2K 1.04-1.05×; JPEG-LS 1.02-1.04×; JPEG XL, the control, 1.00-1.01×. Decode medians were unchanged between the two conditions, as they must be.

E.2 Implied write throughput in the original run, the encode artifact

Compressed output ÷ median encode time, against the gp3 ceiling of 131.07 MB/s (125 MiB/s):

Three 8192px slides whose outputs differ by 22% fall at 131.1 MB/s to four significant figures with 1% IQRs. A compute process does not produce that; a rate-limited device does. The 4096px rows behave differently and consistently with the same mechanism: at 24-32 MB the output fits within the dirty-page budget and is partly absorbed by page cache, so those series run slightly above the sustained ceiling with large, erratic IQRs; at 95-116 MB the budget is exceeded, writeback throttling engages, and the series clamp to the device rate with 1% IQRs.

E.2b Implied write throughput under Condition D

Roughly half of each HTJ2K encode measurement is still the write to the RAM-backed filesystem. It is not corrected for: the ingest comparison is between codecs measured under identical conditions, and the residual penalizes the fastest one. Every HTJ2K-encoded figure, and every multiple derived from it, is a lower bound.

E.3 Derived encode multiples, lower bounds

Under the original clipped data, these were 23.6-33.1× and 3.5-4.5×; the difference is entirely due to storage volume.

E.4 Decode, per tile, median ± IQR (ms), Conditions B and C

E.5 Derived decode multiples, median across slides

Per-tile HTJ2K-vs-J2K ranges 6.4-8.3× under B and 17.9-24.6× under C, which are the ranges quoted in the main text.

Figure 3. Lossless compression ratio against encode time, four codecs, six tiles, three slides; per-tile medians of 20 iterations. Up and to the left is better.

Appendix F: Lossy: Full Data Tables

Figure 4. SSIM, SSIMULACRA2 and Butteraugli at JPEG XL distance 1.0 across six tiles. The horizontal reference lines mark SSIMULACRA2’s 85 (“excellent quality”) anchor and the Butteraugli distance of 1.0 that libjxl defines as visually lossless. Every tile clears the first and exceeds the second. The 8192px Butteraugli points are the initial-run values (marked † in the table below).

F.1 Lossy encode and decode, per tile

Condition C values for the lossy series are in D.4 as medians across slides. A note on CMU-2 noise: in the original run, CMU-2_4096 d1.0 had the single widest decode IQR in the dataset, and in the re-run the same series defeated decode_sanity’s noise test (D.7). CMU-2 is measurably noisier than the other two slides on this series, and any CMU-2 lossy decode figure should be read with that in mind.

Figure 6. Source and compressed crops at 1:1 pixel scale, JPEG XL distances 1.0 and 3.0, from the CMU-2 slide. The metrics above are proxies; this figure presents the underlying pixel evidence, because judging diagnostic acceptability is a pathologist’s determination rather than a metric’s.

Appendix G: Decode Latency Consistency

The content-invariance claim in the main text is confined to 4096px. This section shows why.

Spread is (max − min) / min across the three slides. At 4096px, the HTJ2K result is unambiguous: three slides at 32.5, 32.4, and 32.3 ms, a 0.2-0.3 ms range against a 2.9 ms within-slide IQR. Slides differ from each other by less than a single slide differs from itself across repeated runs. At 8192px, the result cannot be resolved with three slides: 131.4, 141.1, and 128.7 ms, a 12.4 ms range against an 11.0 ms IQR, ratio of 1.12. Content dependence can be neither established nor excluded, and the paper does not claim to do so. Classic J2K tracks bitstream size almost one-to-one at both tile sizes.

Why does Condition B give the wrong number? Condition B showed HTJ2K 8192 at 0.83% spread, apparently more content-invariant than 4096. That was the fixed ~230 ms of tmpfs write plus process overhead suppressing variance: a constant added to every measurement shrinks the relative spread of whatever variance the codec actually has. Under Condition C, with the constant removed, the 8192px spread is 9.4-9.6%. A fourth slide exists on the instance but was deliberately not used, because adding it would change the dataset for every result in the paper and require the same tissue-region selection rule.

Appendix H: Ratio-Matched Lossy Comparison and Baseline JPEG

H.1 Method

HTJ2K and classic J2K were encoded to match JPEG XL’s achieved byte count per tile by solving for the Kakadu rate that reproduces it. Matching accuracy: within 2.0% on all 24 pairs, range −0.12% to −1.97%. Decode ran under Condition B (output on tmpfs). Encode was re-timed with output on the RAM-backed filesystem; the three series that had been at 50-53% of the storage ceiling changed by 3-7%.H.2 Per-slide results:

JPEG XL’s own values for each tile are in F.1.

H.2b Butteraugli, 8192px ratio-matched pairs (max-norm / 3-norm)

Computed with 24 GiB of swap scoped to the job; butteraugli_main had been terminated at 10.4-13.0 GiB resident on every earlier attempt. At equal bytes, HTJ2K’s Butteraugli max-norm is 0.6-1.0 higher than classic J2K’s at ~10.6× and 0.0-0.8 higher at ~24.4×, consistent in direction with its SSIMULACRA2 deficit.

H.3 Derived comparisons, median across slides

What the decode column understates. The Condition B residual (D.6) is 64.3 ms at 4096px and 229.2 ms at 8192px. Against a matched-ratio HTJ2K decode of 93.03 ms at 4096px, that residual is 69% of the measurement, so the decode advantages above are lower bounds by an unquantified margin. An in-process decode of this pass was not run.

H.4 Baseline JPEG at matched compression ratio

Baseline JPEG was encoded with libjpeg-turbo, in-process, to match JPEG XL’s achieved byte count on each tile, at both 4:4:4 and 4:2:0 chroma subsampling (matching within 2.3% on all 24 pairs). 4:4:4 is the like-for-like codec comparison; 4:2:0 is what most existing archives hold. Medians across three slides, with HTJ2K and JPEG XL from H.3 for comparison. JPEG timings are in-process and carry no subprocess cost; the comparison of interest is quality at equal bytes, not speed.

At equal bytes, JPEG XL exceeded baseline JPEG by 3.8-6.1 SSIMULACRA2 points at ~10.5× and by 14.8-15.9 points at ~24×. HTJ2K matched or exceeded JPEG 4:4:4 at every operating point, by 0.4-1.4 points at 10.5× and 6.5-7.0 points at 24×. 4:2:0 subsampling cost JPEG about 1.8 points at 10.5× and had no consistent effect at 24×. The gap between the incumbent and either wavelet or JPEG XL codec is small at moderate compression and substantial at aggressive compression. The case for migrating a JPEG archive rests on lossless capability, decode speed and streaming, not on quality at equal bytes.

Appendix I: JPEG XL Effort Sweep, Full Precision

All three slides, 4096px. Decode columns from the original sweep are deliberately omitted: they were produced via the defective I/O path (Section D) and were not part of the re-run scope. Encode figures were unaffected by the storage artifact (JPEG XL encodes at 3.3-3.7% of the ceiling; 1.00-1.01× under Condition D).

Figure 5. Compression ratio and encode time against encoder effort for three slides at 4096px, lossless mode, on separate panels sharing an effort axis. Encode time is on a logarithmic scale.

I.1 Lossless

I.2 Lossy d1.0

I.3 Lossy d3.0 (ratio / SSIM / SSIMULACRA2 / Butteraugli)

Reading the sweep. Effort 1→3 is the only step that buys a real lossless gain, 13-25% depending on slide, for a sub-second cost; in lossy mode the same step buys only 3.6-5.8%. Effort 7→9 costs 3.6-4.8× the encode time on lossless rows and 17-18× on lossy d1.0 rows; the lossy multiplier is larger because rate-distortion search has more room to keep grinding at higher effort for progressively less benefit. At effort 9, lossy SSIM decreases on every slide relative to effort 7 (bolded in I.3). The encoder trades toward a smaller file at slightly worse perceptual quality; the specific basis for “effort 9 is not recommended.” Note also the effort 1 and 3 identity in lossy mode: SSIM, SSIMULACRA2 and Butteraugli are identical between efforts 1 and 3 on all three slides at d1.0. At the same time, the ratio improves slightly; the encoder is finding a smaller encoding of what is perceptually the same result.

Appendix J: Encode: the Artifact, Parameter Sensitivity and the Transcode Benchmark

J.1 The encode artifact

Detailed in E.2. The re-run that controlled decode relocated the decode directory to tmpfs but did not relocate the compressed-output directory, which was hardcoded with no environment override. In every run in the series, conditions A and B, the overhead probe, and the ratio-matched pass recorded to the same 125 MiB/s volume. Condition D result: HTJ2K encode fell 3.04-3.92×; JPEG XL, the control, changed 1.00-1.01×; J2K and JPEG-LS changed 1.02-1.05×; decode was unchanged. Every encode figure in the main text is the Condition D value and is stated as a lower bound on speed. The t unless both output directories are on tmpfs.

Figure 9. Encode time by codec under Condition B (compressed output on the gp3 volume) and Condition D (output on a RAM-backed filesystem), median of three slides, log scale, with the gp3 write ceiling for HTJ2K’s output size marked. Only HTJ2K was constrained by the volume; the JPEG XL control changed by 1.00-1.01×.

J.2 Fixed per-invocation overhead, eliminated as a cause

0.30-0.37% of an 8192px encode window; 1.2% of an 8192px HTJ2K encode and 4.4% of a 4096px one after correction. Unaffected by the artifact, since these outputs are bytes rather than megabytes.

J.3 Thread count

Thread counts were sampled from /proc during live runs, kdu_compress 8, kdu_expand 8, cjxl 9, and are likewise unaffected.

J.4 Parameter sensitivity, re-measured; no operating-point effect

The original sweep, on the BLGSP 8192px tile with output on the storage volume, appeared to show a 3.27× span between lossless and rate-controlled HTJ2K encoding. Four of its six variants were at the write ceiling. Re-run with output on the RAM-backed filesystem at 20 iterations:

Every HTJ2K variant now falls within 198-252 ms. Reversibility and rate control do not move encode time; the apparent 3.27× span was write volume at a clipped device. Clevels has no measurable effect; Cblk={32,32} costs about 12%. Classic J2K is 11.7× slower than the HTJ2K baseline. Overhead-corrected 8192px HTJ2K encode across the three slides: 210.5, 223.6 and 212.2 ms.

J.5 Comparability of absolute encode times across studies

Absolute encoding times do not transfer between studies; therefore, this paper reports ratios measured within a single harness. Three factors each move HTJ2K’s absolute 8192px encode time by the same order as the codec differences under study. Compressed byte count: the dense-tissue selection rule here yields tiles that compress to 94.7-115.8 MB, whereas a more typical whole-slide region compresses to ~75 MB, 1.27-1.56× more bytes through the block coder by design. Thread count and ISA: 8 threads on AVX-512 here; a 16-thread run on the same ISA would land materially lower, a single-thread run materially higher. Kakadu version: 8.7 here; the HT block coder has changed across releases. A figure measured elsewhere, landing near Condition D’s 211-225 ms, would be a coincidence rather than confirmation. Cross-harness comparisons additionally inherit each harness’s own output-path residual (D, J.1): a reference figure taken from a harness that wrote to storage carries a write cost that is invisible in the number. The valid comparison is the one made here: every codec on the same tiles, instance, thread count, and output path.

J.6 Transcode benchmark, separate platform

Environment: Fedora 43, Linux 6.17, AMD Ryzen AI 7 350, 8 cores, AVX2 only, CPU governor powersave (this host does expose cpufreq), Kakadu 8.6.1, in a container. Test data: CMU-1 tiles at 1024/4096/8192px plus synthetic pathology and radiology images, not the three slides used elsewhere. Do not compare absolute times in this subsection against any other section; compare speedup ratios within it only.

Equal-thread comparison (both paths single-threaded):

Production, out of the box (single-threaded kdu_transcode vs multi-threaded full pipeline):

The cause is documented in Kakadu’s own materials: “the kdu_transcode demonstration application is currently only single threaded […] licensees can use Kakadu’s low level API’s to develop very high throughput multi-threaded transcoders.” Integrity: SHA-256 round trip 12/12 both directions; J2K and HTJ2K decodes of the same source pixel-identical 12/12. Re-measuring these paths on the benchmark instance is recorded as an open item (Section M).

Appendix K: Storage Economics Model

K.1 Basis and limits

All examples use one cohort of 1 PB of uncompressed-equivalent RGB pixels, decimal units (1 PB = 1,000 TB; 1 TB = 10¹² bytes), retained for ten years. They are not a model of ten successive annual cohorts. Storage is bytes-weighted over the six tiles in E.0, using the published sizes rounded to 0.01 MB. The timing scale uses medians over the three slides at the stated tile size. This is an extrapolation of a small, tissue-selected corpus, not a measured archive migration or a capacity forecast.

Illustrative rates are $0.34 per 8-vCPU benchmark-instance hour and $10/TB-month cold storage. A separate flat-rate storage illustration uses $0.023/GB-month; it is not a negotiated S3 quote and excludes tiered pricing. Exclusions from all net values: licenses, redundancy, retained originals, temporary migration copies, caches, request/retrieval fees, egress, data I/O, metadata/pyramids beyond the sampled RGB pixels, orchestration, validation and operations. Insert deployment-specific amounts before deciding.

For a fixed cohort, stored TB equals raw TB divided by its compression ratio. Storage dollars equal stored TB × dollars per TB-month × retained months. Encode dollars equal tile count × seconds per tile ÷ 3,600 × dollars per instance-hour. Use the difference between candidate configurations. Annual acquisition volume requires a separate retention-cohort model.

K.2 One-time encoding

Condition D includes encoding and compressed output to a RAM-backed filesystem. Approximately 4.967 million 8192px RGB tiles make one raw PB. These are encoding costs only: migration also needs source decoding or an appropriate compressed-domain conversion. Parallel execution can shorten elapsed time if scaling is efficient; it does not remove the work. The separate-host transcode timings in J.6 do not establish a cheaper production migration on this instance.

K.3 Storage for the measured lossless settings

K.4 Active viewing workload illustration

The arithmetic assumes 100 simultaneous sessions, each requesting two whole 4096px tiles per second, serialized decoding on each 8-vCPU instance, and this load for all 8,760 hours of a year. Instance counts round up and contain no utilization headroom. This is neither a conservative production estimate nor a claim about actual sessions: normal tile sizes, duty cycle, parallelism, cache hits, client/GPU decoding, network, scheduling, and rendering change capacity. The workload is not tied to a 1 PB archive. Do not present its approximately $369,000 HTJ2K-versus-J2K difference as a per-PB saving.

A financially dimensioned break-even for a fixed archive is additional storage dollars divided by decode dollars saved per equal-volume read, including the chosen horizon. Using only these CPU microbenchmark values, a complete read of 1 raw PB at 4096px saves approximately $1,163 for HTJ2K versus J2K; its extra cold storage is about $4,756 per year. Thus this limited model needs about 4.1 full raw-equivalent archive reads per year, or about 41 over ten years, to offset storage before other costs. A pathologist’s view is generally a partial read, not a full archive read. Dividing percentage speedup by percentage storage overhead does not establish payback.

K.5 JPEG XL archive replacement and retrieval

This retrieval budget charges the entire modeled JPEG XL-to-HTJ2K conversion to the storage benefit. It is not a universal break-even: direct JPEG XL viewing avoids this conversion, cache hits reduce it, keeping cached HTJ2K increases storage, and baseline read costs may differ. The decode and encode stages were measured separately; their sum is an estimate, not a measured integrated service. Use the deployment’s actual miss rate, conversion cost, and cache size. Do not interpret 4.7 as a codec-wide cold-tier cutoff.

Against classic J2K, the all-six-tile storage difference is about 28.6 TB per raw PB, worth approximately $34,269 over ten years. The initial effort-7 encode difference is about $7,769, leaving about $26,501 before retrieval and other costs. J2K-to-HTJ2K transcode measurements came from another host, so they do not establish a numerical comparative retrieval cutoff for unit clarity only; 100M retrievals divided by 4.967M tiles and ten years equal about 2.0 full archive reads per year, not 25.

K.6 Encoder effort and JPEG-LS migration

JPEG-LS to JPEG XL requires a full decode and encode; JPEG XL .111 reversible recompression covers baseline JPEG, not JPEG-LS. At 8192px, using measured Condition B JPEG-LS decode of 3.9041 s and effort-7 encode of 19.1653 s gives about $10,822 compute per raw PB, approximately 1,326 instance-days. Against about $13,162 in annual cold-storage savings, the compute-only payback is approximately 10 months. This excludes the migration and operational costs listed in K.1 and assumes the original is retired after validation. It is not a guaranteed project payback.

An effort-3 estimate of roughly 3.2 s per 8192px encode, extrapolated from the 4096px sweep, gives about $3,333 migration compute and about 408 instance-days including source decode. Do not pair this estimate with effort-7 storage savings or decode timings: the effort-3 8192px output sizes and serving performance must be measured to calculate its payback. On the measured effort-7 path, JPEG XL Condition B decode was 857 versus JPEG-LS 974 ms at 4096px and 3,359 versus 3,904 ms at 8192px.

The effort sweep also illustrates diminishing returns. For the TCGA 4096px lossless tile, effort 1 to 3 saves about 4.2 MB using ratios rounded to 1.85× and 2.19×; extra encode is 0.6201 s, about $0.000059. At the stated cold-storage rate, this saves about $0.0051 over ten years. For TCGA lossy d1.0, effort 7 to 9 saves about 0.25 MB using ratios 11.91× and 12.65×, at roughly $0.0034 extra compute versus $0.0003 storage saved. These are specific operating-point examples, not a clinical basis for an effort cap.

K.7 External cost context

Published pathology infrastructure reports provide context, not present-day quotes. Memorial Sloan Kettering [31] reported approximately $1M per PB including redundancy and an annualized 2021 storage cost of $1.6M. A European review reports approximately €150/TB-year for fast access and €60/TB-year for long-term storage. Match redundancy, service scope, and retention assumptions before inserting such figures into a comparison.

Appendix L: Verification Log

Every measurement control and source check performed for this paper, with its finding and how the paper handles it so that a reader can judge the evidence rather than take it on trust.

A pattern for reviewers. Items 1, 2 and 3 share a mechanism: a claim entered the working notes without being tested at source, propagated to every derived artifact, and every artifact then agreed with every other. Item 2 is the sharpest case: “encode is unaffected by the storage artifact” appeared in the methodology, the re-run specification, the replacement tables and the figure-generation script, and was never once tested by dividing bytes by seconds. Internal consistency is not evidence.

Appendix M: Open Items

What is not a gap. n = 3 slides is a design choice favoring stain, morphology, and vendor-format diversity over volume, disclosed throughout. A pathologist reader study was out of scope by design; the clinical-risk section states what such a study would establish and why no metric can substitute for it. Learned or neural compression was excluded with supporting rationale and a survey citation. Because no 12/16-bit monochrome data were tested, every JPEG XL claim is limited to 8-bit RGB pathology. A plain-JPEG baseline is measured (H.4).

What was deliberately not run. An in-process encode (“Condition E”) was built and abandoned: the ingest claim is a comparison at matched parameters, the tmpfs residual penalizes the faster codec, so Condition D’s figures are conservative lower bounds and a further condition would invalidate another set of tables for a degree of isolation the document does not need. A fourth slide for 8192px content invariance would change the dataset for every result; the claim is narrowed instead. Ratio-matched in-process decode was not run; it would only increase HTJ2K’s stated advantage.

Appendix N: References

Numbered in order of first citation in the full whitepaper, per the ICMJE Recommendations. Every entry was consulted in full; sources that could not be read in full are not cited (Section L, rows 16 and 23). A DOI is given where one exists; web sources carry a URL and access date.

1. DICOM Standards Committee, Working Group 4. Supplement 232: JPEG XL Transfer Syntaxes. Final text. NEMA; September 18, 2024. Accessed September 9, 2026. https://www.dicomstandard.org/news-dir/ftsup/docs/sups/sup232.pdf
2. DICOM Standards Committee, Working Group 4. Supplement 235: HTJ2K Transfer Syntax. Final text. NEMA; November 14, 2023. Accessed September 9, 2026. https://www.dicomstandard.org/News-dir/ftsup/docs/sups/sup235.pdf
3. Amazon Web Services. AWS HealthImaging supports importing large DICOM objects and high-throughput JPEG 2000 (HTJ2K) transfer syntaxes. Published March 2024. Accessed September 9, 2026. https://aws.amazon.com/about-aws/whats-new/2024/03/aws-healthimaging-import-dicom-objects-htj2k-transfer-syntaxes
4. Tong G, Liu S, Lv Y, Pei H, Fan FL. A survey on medical image compression: from traditional to learning-based approaches. Preprint. arXiv. Posted July 13, 2025. Updated February 8, 2026. arXiv:2507.10615v2. doi:10.48550/arXiv.2507.10615
5. Kakadu Software. Kakadu SDK Documentation: HTJ2K_in_Kakadu.txt. Version 8.7. Distributed with the licensed SDK.
6. Sneyers J, Alakuijala J, Versari L, et al. The JPEG XL image coding system: history, features, coding tools, design rationale, and future. Preprint. arXiv. Posted June 6, 2025. Updated June 13, 2025. arXiv:2506.05987v2. doi:10.48550/arXiv.2506.05987
7. libjxl: JPEG XL image format reference implementation. Version 0.13.0, commit e4b66d3. GitHub. Accessed September 9, 2026. https://github.com/libjxl/libjxl
8. DICOM Standards Committee. DICOM PS3.3 2026c: Information Object Definitions. Section C.8.12.4.1.5, Photometric Interpretation and Samples per Pixel, note 2. NEMA; 2026. Accessed September 9, 2026. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_c.8.12.4.html
9. Access Advance. Access Advance announces HEVC Advance and VVC Advance pricing through 2030. Published July 21, 2025. Accessed September 9, 2026. https://accessadvance.com/2025/07/21/access-advance-announces-hevc-advance-and-vvc-advance-pricing-through-2030/
10. Access Advance. Access Advance extends HEVC Advance rate increase deadline. Published January 27, 2026. Accessed September 9, 2026. https://accessadvance.com/2026/01/27/access-advance-extends-hevc-advance-rate-increase-deadline/
11. Dicom Systems. Benchmark methodology, harness controls, and raw results. September 2026. This appendix, sections A-J; six-tile sizes in section E.0.
12. Wang Z, Bovik AC, Sheikh HR, Simoncelli EP. Image quality assessment: from error visibility to structural similarity. IEEE Trans Image Process. 2004;13(4):600-612. doi:10.1109/TIP.2003.819861
13. Sneyers J. SSIMULACRA 2: structural similarity unveiling local and compression-related artifacts. Cloudinary. 2022-2023. Accessed September 9, 2026. https://github.com/cloudinary/ssimulacra2
14. Google. butteraugli: a project that estimates the psychovisual similarity of two images. GitHub. Accessed September 9, 2026. https://github.com/google/butteraugli
15. Alakuijala J, Boukortt S, Ebrahimi T, et al. Benchmarking JPEG XL image compression. Proc SPIE.2020;11353:113530X. doi:10.1117/12.2556264
16. Sneyers J, Ben Baruch E, Vaxman Y. CID22: large-scale subjective quality assessment for high fidelity image compression. Preprint. TechRxiv. 2023. doi:10.36227/techrxiv.22659061
17. DICOM Standards Committee. DICOM PS3.5 2026c: Data Structures and Encoding. Section 8.2.1, JPEG Image Compression, note. NEMA; 2026. Accessed September 9, 2026. https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_8.2.html
18. European Society of Radiology. Usability of irreversible image compression in radiological imaging. A position paper by the European Society of Radiology (ESR). Insights Imaging. 2011;2(2):103-115. doi:10.1007/s13244-011-0071-x
19. Norweck JT, Seibert JA, Andriole KP, et al. ACR-AAPM-SIIM technical standard for electronic practice of medical imaging. J Digit Imaging. 2013;26(1):38-52. doi:10.1007/s10278-012-9522-2
20. Chen Y, Janowczyk A, Madabhushi A. Quantitative assessment of the effects of compression on deep learning in digital pathology image analysis. JCO Clin Cancer Inform. 2020;4:221-233. doi:10.1200/CCI.19.00068
21. Pambrun JF, Noumeir R. Limitations of the SSIM quality metric in the context of diagnostic imaging. In: 2015 IEEE International Conference on Image Processing (ICIP). IEEE; 2015:2960-2963. doi:10.1109/ICIP.2015.7351345
22. DICOM Standards Committee. DICOM PS3.5 2026c: Data Structures and Encoding. Section A.6, DICOM JPIP Referenced Transfer Syntax. NEMA; 2026. Accessed September 9, 2026. https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_A.6.html
23. Noumeir R, Pambrun JF. Using the JPEG 2000 interactive protocol to stream a large image or a set of large images. J Digit Imaging. 2011;24(5):833-843. doi:10.1007/s10278-010-9343-0
24. MDN Web Docs. Image file type and format guide. Updated August 28, 2026. Accessed September 9, 2026. https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types
25. Amazon Web Services. AWS HealthImaging adds JPEG XL support. Published February 2, 2026. Accessed September 9, 2026. https://aws.amazon.com/about-aws/whats-new/2026/01/aws-healthimaging-adds-jpeg-xl
26. Dicom Systems. Compressed-domain HTJ2K↔J2K transcoding measurements. February 2026. This appendix, section J.6.
27. DICOM Standards Committee. DICOM PS3.6 2026c: Data Dictionary. Annex A, Registry of DICOM Unique Identifiers. NEMA; 2026. Accessed September 9, 2026. https://dicom.nema.org/medical/dicom/current/output/chtml/part06/chapter_A.html
28. DICOM Standards Committee. DICOM PS3.3 2026c: Information Object Definitions. Section A.32.8, VL Whole Slide Microscopy Image IOD. NEMA; 2026. Accessed September 9, 2026. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.32.8.html
29. OpenJPH: open-source implementation of high-throughput JPEG 2000 (HTJ2K). GitHub. Accessed September 9, 2026. https://github.com/aous72/OpenJPH
30. Dicom Systems. OpenJPH implementation evaluation. June 2026. This appendix, section J.5, and the Licensing section of the accompanying brief.
31. Ardon O, Klein E, Manzo A, et al. Digital pathology operations at a tertiary cancer center: infrastructure requirements and operational cost. J Pathol Inform. 2023;14:100318. doi:10.1016/j.jpi.2023.100318
32. Schwen LO, Kiehl TR, Carvalho R, Zerbe N, Homeyer A. Digitization of pathology labs: a review of lessons learned. Lab Invest. 2023;103(11):100244. doi:10.1016/j.labinv.2023.100244
33. NVIDIA. Advancing medical image decoding with GPU-accelerated nvImageCodec. NVIDIA Technical Blog. Published April 17, 2024. Accessed September 9, 2026. https://developer.nvidia.com/blog/advancing-medical-image-decoding-with-gpu-accelerated-nvimagecodec/
34. Philips. Philips announces digital pathology scanner with configurable DICOM JPEG and JPEG XL native output in world first. News release. September 8, 2025. Accessed September 9, 2026. https://www.philips.com/a-w/about/news/archive/standard/news/articles/2025/philips-announces-digital-pathology-scanner-with-configurable-dicom-jpeg-and-jpeg-xl-native-output-in-world-first.html
35. Schüffler PJ, Geneslaw L, Yarlagadda DVK, et al. Integrated digital pathology at scale: a solution for clinical diagnostics and cancer research at a large academic medical center. J Am Med Inform Assoc. 2021;28(9):1874-1884. doi:10.1093/jamia/ocab085
36. Leeds Teaching Hospitals NHS Trust. Breakthrough for cancer patients as a network of digitized NHS pathology departments is now live in the north of England. Published August 21, 2024. Accessed September 9, 2026. https://www.leedsth.nhs.uk/news/breakthrough-for-cancer-patients-as-a-network-of-digitized-nhs-pathology-departments-is-now-live-in-the-north-of-england/; National Pathology Imaging Co-operative. About NPIC. Accessed September 9, 2026. https://npic.ac.uk/about/
37. DICOM Standards Committee, Working Group 4. Supplement 232 presentation slides. September 2024. Accessed September 9, 2026. https://www.dicomstandard.org/news-dir/current/docs/sups/sup232-slides.pdf
38. Mayo Clinic. Mayo Clinic launches Mayo Clinic Digital Pathology to modernize pathology, speed medical breakthroughs. News release. January 13, 2025. Accessed September 9, 2026. https://newsnetwork.mayoclinic.org/discussion/mayo-clinic-launches-mayo-clinic-digital-pathology-to-modernize-pathology-speed-medical-breakthroughs/
39. Mao Y, Wang J, Guan N, Xue CJ. WISE: a framework for gigapixel whole-slide-image lossless compression. In: Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 2025:29342-29351.
40. Høibø M, Gaucher E, Reinertsen I, Valla M, Smistad E. Deep learning-based compression of giga-resolution whole slide images. Preprint. arXiv. Posted May 17, 2026. arXiv:2605.17668. doi:10.48550/arXiv.2605.17668
41. didrikwiigandersen. wsi-jxl-compression. Repository README. GitHub. Accessed September 9, 2026. https://github.com/didrikwiigandersen/wsi-jxl-compression
42. OpenJPEG. OpenJPEG officially recognized as JPEG 2000 reference software (ISO/IEC 15444-5:2003/AMD.2). Published July 9, 2015. Accessed September 9, 2026. https://www.openjpeg.org/2015/07/09/openjpeg-officially-reference-software
43. Amazon Web Services. Supported transfer syntaxes. AWS HealthImaging Developer Guide. Accessed September 13, 2026. https://docs.aws.amazon.com/healthimaging/latest/devguide/supported-transfer-syntaxes.html
44. Philips. Digital pathology: Pathology Scanner SGi product information and regional availability. Accessed September 13, 2026. https://www.usa.philips.com/healthcare/diagnostic-and-clinical-informatics/digital-pathology