z2000 0.2.0-rc.7

z2000 0.2.0-rc.7

This release candidate fixes resolution-reduced decoding on more than one
thread, which rc.5 and rc.6 rejected with InvalidCodestream on most images
taller than a few hundred rows. It is rc.6 with that fix and one encoder
speed-up; it changes no format or CLI behaviour, and every stream that
rc.6 decoded gives the same samples.

Fixes

• Threaded reduced decodes. A decode with --reduce N (or
  resolution_reduction in the Zig API) on two or more threads failed with
  InvalidCodestream once a component plane, or a tile of one, was tall
  enough for the block coverage check to cut it into more than one row
  band; on one thread it decoded. A band that started below the rows the
  reduced image needs got a reversed row range: an integer overflow in safe
  builds, a spurious rejection in release builds. Such a band now only
  marks its blocks, so overlapping blocks are still rejected there. It was
  reported against rc.6 with a 2761x3870 Grok 9/7 RGB JP2 in 1024x1024
  tiles, which now decodes identically on 1, 2, 4, and 20 threads at
  --reduce 1 to 5, with and without --region; a unit test compares
  2-, 4- and 8-thread reduced decodes with one thread. Unreduced decodes
  were not affected. Until upgrading, --threads 1 avoids it.

Faster Lossless Encode

• On more than three threads the lossless encoder transforms only the first
  5/3 level before Tier-1 and codes that level's detail blocks, three
  quarters of the image, while the coarser levels are still being
  transformed (about 1 ms at 20 threads on the i5-14500). Codestreams are
  byte-identical to rc.6's. The rc.6 benchmark checkpoint in
  docs/benchmarks.md otherwise stands.

Release Process

• As for rc.6, every archive was built and tested on a local machine:
  native Windows gates, and the Linux x86-64 and RISC-V 64 ReleaseFast suites
  in a Linux container (RISC-V under QEMU), with the official T.803 streams
  included in the corpus run (tools/release_local.ps1). The interop
  scripts against Kakadu 8.4.1, OpenJPEG 2.5.4, and Grok 20.4.19 passed
  before it.
• No macOS archive is published for this candidate: hosted Actions
  minutes, which the native macOS build needs, are exhausted, and a
  cross-built binary could not be tested here. macOS users can build from
  source with Zig 0.17.

Release Candidate Policy

The CLI and Zig API remain unstable before 1.0. This is not a general JP2/JPX,
camera RAW, or HDR converter. Each input adapter has a deliberately narrow
documented envelope; old-style or progressive JPEG, CCITT, LZMA, and ZSTD
TIFF compression, Adam7 PNG, CFA/demosaicing, compressed or tiled EXR,
general ICC transforms, extended XMP, and semantic metadata rewriting remain
unsupported. JP2 metadata payloads are preserved but are not yet restored into
TIFF output.

The project's 100/100 ISO engineering scorecards are internal coverage tools,
not formal ISO conformance certification; passing the T.803 streams is
evidence, not certification. The binaries are unsigned; verify the platform
archive against SHA256SUMS. Every archive contains identical z2000 and
z2k executables for the long and short command names.

z2000 0.2.0-rc.6

z2000 0.2.0-rc.6

This release candidate is about encode speed, with decode faster once more.
TIFF-to-JP2 encodes about a third faster than rc.5 and JP2-to-TIFF decodes
9-22% faster; on one thread z2000 now encodes as fast as Kakadu 8.4.1 and
decodes faster. Codestreams and decoded samples are byte for byte those of
rc.5 on every stream we test. One fix: the threaded 9/7 transform of a
one-row level at an odd vertical origin.

Faster Encode And Decode

On an Intel Core i5-14500 (2048x2048 RGB, 8 bits), against rc.5 (medians of
interleaved runs on the same files; the lossless encode is the benchmark
profile with BYPASS, the lossy one two rate layers):

Operation	Threads	rc.5	rc.6	Change
lossless encode	20	121 ms	83 ms	-32%
lossless encode	1	788 ms	485 ms	-38%
lossy encode	20	137 ms	85 ms	-38%
lossy encode	1	778 ms	515 ms	-34%
lossless decode	20	80 ms	73 ms	-9%
lossless decode	1	599 ms	468 ms	-22%
lossy decode	20	81 ms	72 ms	-11%
lossy decode	1	581 ms	491 ms	-15%

Against the other codecs, each with its own file of the same image
(tools/bench_compare.ps1, mean of 8 runs; one-thread rows give the range
of the three runs the two invocations made; lossy files of 4.80-4.83 MB):

Operation	Threads	z2000	Kakadu 8.4.1	OpenJPEG 2.5.4	Grok 20.4.19
lossless encode	20	82 ms	70 ms	125 ms	137 ms
lossless encode	1	469-483 ms	506-507 ms	745-752 ms	761-787 ms
lossless decode	20	74 ms	68 ms	106 ms	117 ms
lossless decode	1	454-486 ms	581-595 ms	640-649 ms	598-617 ms
lossy encode	20	81 ms	68 ms	128 ms	159 ms
lossy encode	1	498-511 ms	507-526 ms	692-727 ms	795-801 ms
lossy decode	20	84 ms	76 ms	110 ms	154 ms
lossy decode	1	464-502 ms	579-582 ms	605-616 ms	612-633 ms

Details are in docs/benchmarks.md.

• Tier-1 without branches on the coded decision: the MQ encoder and
  decoder pick the sub-interval, the context's next state, and the
  renormalization shift by selects (a context that stays is not rewritten),
  and BYPASS bits are written the same way; refinement decisions are close
  to random, so the branches mispredicted on a large share of them.
• Significance passes skip significant samples: encoder and decoder
  visit only the stripe columns and rows not yet significant, by the
  significance bitmap (three quarters of the samples the pass examined in
  the lower bitplanes).
• Encoder on all threads: the lossy front end (ICT bands, quantization
  in place), the forward 5/3 and 9/7 on up to sixteen workers, the TIFF
  input's sample conversion and file read, and Tier-1 on the shared worker
  pool; each block is coded from a contiguous copy.
• Less copying in the encoder: the packet stream and the codestream are
  built into buffers of their final size, an RGB JP2 is written as its
  boxes and then the codestream, the rate allocation's probe builds packet
  headers only and its convex hulls once, and the coefficient planes are
  released in the background.
• Shorter lossy decode tail: the finest 9/7 level and the inverse ICT
  run in row bands straight into the TIFF buffer, as the lossless tail
  does, and the 9/7 transform runs on the shared pool.

Fixes

• Threaded 9/7 on a one-row level. At an odd vertical origin a level one
  row high was transformed only in its last column band on several threads,
  so the threaded 9/7 differed from the serial one there. It takes a level
  at least 64 samples wide and one row high at an odd origin, which none of
  the test streams has; the parallel-versus-serial test now covers it.

Release Process

• As for rc.5, every archive was built and tested on a local machine:
  native Windows gates, and the Linux x86-64 and RISC-V 64 ReleaseFast suites
  in a Linux container (RISC-V under QEMU), with the official T.803 streams
  included in the corpus run (tools/release_local.ps1).
• No macOS archive is published for this candidate: hosted Actions
  minutes, which the native macOS build needs, are exhausted, and a
  cross-built binary could not be tested here. macOS users can build from
  source with Zig 0.17.

Release Candidate Policy

The CLI and Zig API remain unstable before 1.0. This is not a general JP2/JPX,
camera RAW, or HDR converter. Each input adapter has a deliberately narrow
documented envelope; old-style or progressive JPEG, CCITT, LZMA, and ZSTD
TIFF compression, Adam7 PNG, CFA/demosaicing, compressed or tiled EXR,
general ICC transforms, extended XMP, and semantic metadata rewriting remain
unsupported. JP2 metadata payloads are preserved but are not yet restored into
TIFF output.

The project's 100/100 ISO engineering scorecards are internal coverage tools,
not formal ISO conformance certification; passing the T.803 streams is
evidence, not certification. The binaries are unsigned; verify the platform
archive against SHA256SUMS. Every archive contains identical z2000 and
z2k executables for the long and short command names.

z2000 0.2.0-rc.5

z2000 0.2.0-rc.5

This release candidate is about decode speed. JP2-to-TIFF decodes faster on
one thread and markedly faster on many, with output byte for byte that of
rc.4 on every stream we test; irreversible 9/7 components now decode at
every Part 1 precision, and the wide (above 29-bit) encoder runs on all
threads.

Faster Decode

On an Intel Core i5-14500 (2048x2048 RGB, 8 bits), against rc.4
(medians of interleaved runs on the same files):

Decode	Threads	rc.4	rc.5	Change
lossless 5/3	20	124 ms	81 ms	-35%
lossless 5/3	1	812 ms	612 ms	-25%
lossy 9/7	20	127 ms	80 ms	-37%
lossy 9/7	1	789 ms	597 ms	-24%

Against the other codecs, each decoding its own file of the same image
(tools/bench_compare.ps1, mean of 8 runs; lossy files of 4.80-4.83 MB):

Decode	Threads	z2000	Kakadu 8.4.1	OpenJPEG 2.5.4	Grok 20.4.19
lossless 5/3	20	80 ms	78 ms	115 ms	121 ms
lossless 5/3	1	609-627 ms	610-681 ms	678-914 ms	648-660 ms
lossy 9/7	20	87 ms	77 ms	120 ms	162 ms
lossy 9/7	1	594-604 ms	601-618 ms	624-631 ms	646-652 ms

Encode is 13-15% faster too (lossless 138 -> 118 ms at 20 threads, 1037 ->
900 ms at one), with byte-identical output. Details are in
docs/benchmarks.md.

• Tier-1 on one thread: folded MQ contexts, a 64-bit MQ register that
  renormalizes in one shift, a cleanup pass that screens four rows of a
  column at once, and neighbor flags written a row at a time.
• Stages overlap Tier-1: one block pool decodes all components, and the
  inverse 5/3 or 9/7 of each finished plane runs inside it while later
  planes still decode. One process-wide worker pool serves every parallel
  stage and starts while the input is read.
• Shorter head: the packet scan, the packet-header walk, the catalog
  fill, and the coverage check run on all threads; a single-layer stream's
  block payloads stay in the input instead of being copied.
• Shorter tail: 8-bit RGB is written straight into the TIFF buffer; a
  reversible decode finishes the last plane's finest wavelet level and the
  colour transform in one pass over row bands; irreversible planes are
  dequantized in place; large intermediates are released in the background
  while the file is written; the JP2 wrapper's tile-part audit runs beside
  the decode.
• Less memory: a lossy 2048x2048 RGB decode no longer holds a second
  48 MB of floating-point planes, and the block catalog shrank from about
  1 KB to under 200 bytes per code-block.

Every change keeps the decoded samples identical: the corpus, the
ITU-T T.803 streams, region and quality-layer decodes, the 34-bit wide
stream, and mutation tests that compare one-thread with eight-thread
decodes byte by byte and error by error.

Broader Decode

• Irreversible 9/7 at every precision. Components above 24 bits, which
  rc.4 refused, decode in f64 (T1 through 64-bit coefficients, f64 inverse
  9/7 and ICT); up to 24 bits the f32 path is unchanged. Kakadu 8.4.1's 28-
  and 30-bit irreversible streams decode within 115 and 423 levels of
  kdu_expand's own output, which synthesizes in single precision.

Faster Wide Encoder

• zraw-to-j2k codes the blocks of a tile on all threads and splits the
  wide 5/3 transform over them: a 34-bit 2000x1500 three-component encode
  drops from 8.8 s to 0.6 s at 20 threads, with byte-identical output.

Measurement

• tools/win_affinity_run.zig confines a decoder to a processor mask
  through a job object, and tools/win_pmc_record.ps1 with
  tools/win_pmc_summary.py record hardware counters per decode. They
  showed that an earlier per-core-type comparison let Kakadu run outside its
  mask; the corrected figures are in docs/benchmarks.md.

Release Process

• As for rc.4, every archive was built and tested on a local machine:
  native Windows gates, and the Linux x86-64 and RISC-V 64 ReleaseFast suites
  in a Linux container (RISC-V under QEMU), with the official T.803 streams
  included in the corpus run (tools/release_local.ps1).
• No macOS archive is published for this candidate: hosted Actions
  minutes, which the native macOS build needs, are exhausted, and a
  cross-built binary could not be tested here. macOS users can build from
  source with Zig 0.17.

Release Candidate Policy

The CLI and Zig API remain unstable before 1.0. This is not a general JP2/JPX,
camera RAW, or HDR converter. Each input adapter has a deliberately narrow
documented envelope; old-style or progressive JPEG, CCITT, LZMA, and ZSTD
TIFF compression, Adam7 PNG, CFA/demosaicing, compressed or tiled EXR,
general ICC transforms, extended XMP, and semantic metadata rewriting remain
unsupported. JP2 metadata payloads are preserved but are not yet restored into
TIFF output.

The project's 100/100 ISO engineering scorecards are internal coverage tools,
not formal ISO conformance certification; passing the T.803 streams is
evidence, not certification. The binaries are unsigned; verify the platform
archive against SHA256SUMS. Every archive contains identical z2000 and
z2k executables for the long and short command names.

z2000 0.2.0-rc.4

z2000 0.2.0-rc.4

This release candidate fixes the quality layers of every layered stream that
rc.3 wrote, decodes every JPEG 2000 Part 1 sample precision from 1 to 38 bits,
passes all seven ITU-T T.803 profile-1 streams in addition to the sixteen
profile-0 ones, and adds a native encoder (zraw-to-j2k) for any Part 1
component layout.

Fixes Since 0.2.0-rc.3

• Quality layers decode correctly. A layer that ended inside a block's
  continuous codeword carried only the bytes the MQ coder had already
  emitted, so every decoder (z2000, Kakadu, OpenJPEG, Grok) reconstructed the
  end of that pass wrongly: layer 1 of a five-layer RGB stream differed in
  649297 samples by up to 110 levels. Each pass boundary now records the
  shortest prefix that decodes it exactly. Only intermediate layers were
  affected; full streams and BYPASS/TERMALL segment ends were always exact.
  Layered files written by rc.3 keep the defect in their intermediate layers
  and should be re-encoded if those layers matter.
• POC follows ISO/IEC 15444-1 A.6.6. A tile's own POC replaces the
  main-header POC instead of extending it, at most one POC marker may appear
  in a header, and a tile that uses POC must carry one in its first
  tile-part. A single-tile POC in a later tile-part header now decodes, and
  R, L, and C tile-parts work under any POC schedule.
• PCRL and CPRL streams whose tiles are not aligned to the precinct grid,
  PPT streams ending in empty packets, JP2 files with QCC for only some
  components, and tile coding overrides in every progression order decode.

Broader Part 1 Decode

• Every Part 1 precision. Reversible components of 30 to 38 bits, and
  any component whose bands need more than 31 magnitude bitplanes, decode
  through 64-bit coefficients up to the Part 1 ceiling, block-parallel like
  the 32-bit path. None of the codecs we compare against decode above 30
  bits.
• All seven T.803 profile-1 streams pass beside the sixteen profile-0 ones.
• The native decoder (j2k-to-pgx, j2k-to-zraw) applies ICT as well as
  RCT, accepts component-local coding together with component subsampling
  and on multi-tile streams, and applies RCT when the other components
  differ in precision or sampling.

New: Native Encoder

zraw-to-j2k encodes a canonical ZRAW reversibly into a raw codestream:

• any Part 1 component layout: up to 16384 components, each signed or
  unsigned with its own precision from 1 to 38 bits and its own subsampling,
  on a reference grid with any origin, with component registration (CRG);
• one tile or a tile grid encoded in parallel, RCT, every progression order,
  POC, R/L/C/P tile-parts, TLM, PPM/PPT, SOP/EPH, and every code-block style;
• per-component levels, code-block size, precincts, and style (COC);
• Maxshift regions of interest whose region decodes losslessly from the
  first layer alone;
• rate-targeted layers by global PCRD (--rates).

At 8 and 16 bits its output is byte for byte that of the existing RGB,
planar, gray, and sampled encoders. Kakadu 8.4.1 decodes its streams exactly
within Kakadu's own precision; OpenJPEG 2.5.4 decodes ROI streams exactly
except with BYPASS, which it misdecodes even from Kakadu's own encoder (see
docs/reference_tools.md).

Release Process

• As for rc.3, every archive was built and tested on a local machine:
  native Windows gates, and the Linux x86-64 and RISC-V 64 ReleaseFast suites
  in a Linux container (RISC-V under QEMU), with the official T.803 streams
  included in the corpus run (tools/release_local.ps1).
• No macOS archive is published for this candidate: the hosted build that
  produced it is unavailable, and a cross-built binary could not be tested
  here. macOS users can build from source with Zig 0.17.

Release Candidate Policy

The CLI and Zig API remain unstable before 1.0. This is not a general JP2/JPX,
camera RAW, or HDR converter. Each input adapter has a deliberately narrow
documented envelope; old-style or progressive JPEG, CCITT, LZMA, and ZSTD
TIFF compression, Adam7 PNG, CFA/demosaicing, compressed or tiled EXR,
general ICC transforms, extended XMP, and semantic metadata rewriting remain
unsupported. JP2 metadata payloads are preserved but are not yet restored into
TIFF output. Irreversible 9/7 components are decoded up to 24 bits.

The project's 100/100 ISO engineering scorecards are internal coverage tools,
not formal ISO conformance certification; passing the T.803 streams is
evidence, not certification. The binaries are unsigned; verify the platform
archive against SHA256SUMS. Every archive contains identical z2000 and
z2k executables for the long and short command names.

z2000 0.2.0-rc.3

z2000 0.2.0-rc.3

This release candidate fixes a regression in 0.2.0-rc.2 that rejected
JPEG 2000 streams declaring a Part 1 profile, decodes ordinary rate-truncated
reversible files that rc.2 refused, and passes all sixteen ITU-T T.803
profile-0 conformance streams.

Fixes Since 0.2.0-rc.2

• Profile streams decode again. rc.2 rejected every codestream with a
  nonzero Rsiz, so Profile 0/1, digital cinema, broadcast, and IMF streams
  (for example OpenJPEG -cinema2K/-IMF or Kakadu Sprofile output) failed
  with UnsupportedPayload. These profiles only restrict Part 1 syntax and
  now decode like unrestricted streams; Part 2, CAP, PRF, and reserved
  declarations still fail closed.
• Rate-truncated reversible files decode. A reversible stream whose
  encoder truncated its layers, such as Kakadu Creversible=yes -rate N or
  OpenJPEG's default output with -r N, can reconstruct slightly out of
  range; rc.2 rejected it with SampleOutOfRange. Only a decode in which
  every code block provably carries all its coding passes is now treated as
  exact; every other decode clamps to the component range, and the output
  matches Kakadu exactly. Corrupt complete streams still fail closed.
• Ordinary Kakadu streams whose COD level count is below one component's
  COC no longer fail as InvalidCodestream.

Broader Part 1 Decode

• All 16 T.803 profile-0 streams pass; rc.2 as shipped passed only the three
  that declare no profile. New: multipart POC under a main RLCP progression
  (p0_07), up to 16384 components with two-byte component selectors above
  256 (p0_13, 257 components), a main QCD shared across components with
  different level counts (p0_05, p0_08), and RCT on the native path for
  any component count.
• The native decoder (j2k-to-pgx, j2k-to-zraw) applies RCT to components
  0..2 and mixes 5/3 and 9/7 components in single-tile streams.

Release Process

• Every archive in this release was built and tested on a local machine:
  native Windows gates, and the Linux x86-64 and RISC-V 64 ReleaseFast suites
  in a Linux container (RISC-V under QEMU), with the official T.803 streams
  included in the corpus run. tools/release_local.ps1 records the
  procedure.
• No macOS archive is published for this candidate: the hosted build that
  produced it is unavailable, and a cross-built binary could not be tested
  here. macOS users can build from source with Zig 0.17.

Release Candidate Policy

The CLI and Zig API remain unstable before 1.0. This is not a general JP2/JPX,
camera RAW, or HDR converter. Each input adapter has a deliberately narrow
documented envelope; old-style or progressive JPEG, CCITT, LZMA, and ZSTD
TIFF compression, Adam7 PNG, CFA/demosaicing, compressed or tiled EXR,
general ICC transforms, extended XMP, and semantic metadata rewriting remain
unsupported. JP2 metadata payloads are preserved but are not yet restored into
TIFF output.

The project's 100/100 ISO engineering scorecards are internal coverage tools,
not formal ISO conformance certification; passing the T.803 streams is
evidence, not certification. The binaries are unsigned; verify the platform
archive against SHA256SUMS. Every archive contains identical z2000 and
z2k executables for the long and short command names.

z2000 0.2.0-rc.2

z2000 0.2.0-rc.2

This release candidate widens Part 1 decode and encode coverage, opens most
of the TIFF input that scanners and archives produce, and moves the build to
Zig 0.17, while keeping unsupported input fail-closed.

Highlights Since 0.2.0-rc.1

• Broader Part 1 decode: tile-local COD/COC/QCD/QCC overrides, mixed and
  component-local transforms, RGN Maxshift ROI, CRG, PLM, CAP/PRF, general
  multipart POC across inline, PPT, and PPM headers, every TLM width, empty
  resolutions and subbands, arithmetic bypass across layers, irreversible
  9/7 and RGBA through the native and planar paths, and a native decode
  path for any bounded component count with signed or unsigned reversible
  components up to 29 bits, written as raw PGX or ZRAW diagnostics. A
  manifest-driven Part 1 corpus pins
  Kakadu, OpenJPEG, and Grok streams, including fail-closed producer
  defects.
• Selective and bounded decode: tile, reference-region, quality-layer, and
  reduced-resolution selection, with streaming JP2-to-TIFF output for
  palette, alpha, subsampled, and grayscale layouts.
• Broader encode: gray, gray+alpha, and RGBA on tile grids, RGB without MCT,
  BYPASS without TERMALL, odd and tiny tiles at the global level count, TLM
  over many segments, planar 9/7, and every unsigned precision from 1 to
  16 bits. A writer defect that put EPH after the packet body in
  one-part-per-tile layouts is fixed, and the decoder now checks EPH where
  ISO A.8.2 puts it.
• TIFF input: 1- to 16-bit samples, LZW, Deflate, PackBits, and baseline
  JPEG (gray, RGB, YCbCr 1x1/2x1/2x2) compression with horizontal
  prediction, tiled and separate-plane layouts, and multi-page files, one
  JP2 per page (out-p001.jp2, ...) or --page N. Batch conversion refuses
  output-name collisions, including page names and names differing only in
  case, before writing anything.
• PNG input keeps 1/2/4-bit grayscale at its native depth and accepts the
  sRGB-valued cHRM/gAMA chunks ImageMagick writes.
• Hardening: a truncated zlib stream could overrun the input in Zig 0.16's
  inflater (a panic in safe builds, an out-of-bounds read in ReleaseFast)
  through PNG or TIFF Deflate input; z2000 guards against it, and Zig 0.17
  fixes it upstream. Fuzz campaigns over the committed fixtures end in
  errors, never panics or hangs.
• Builds with Zig 0.17.0.

Release Candidate Policy

The CLI and Zig API remain unstable before 1.0. This is not a general JP2/JPX,
camera RAW, or HDR converter. Each input adapter has a deliberately narrow
documented envelope; old-style or progressive JPEG, CCITT, LZMA, and ZSTD
TIFF compression, Adam7 PNG, CFA/demosaicing, compressed or tiled EXR,
general ICC transforms, extended XMP, and semantic metadata rewriting remain
unsupported. JPEG-compressed TIFF is decoded from a lossy source before
encoding. JP2 metadata payloads are preserved but are not yet restored into
TIFF output.

The project's 100/100 ISO engineering scorecards are internal coverage tools,
not formal ISO conformance certification. The binaries are unsigned; verify
the platform archive against SHA256SUMS. Every archive contains identical
z2000 and z2k executables for the long and short command names.

z2000 0.2.0-rc.1

z2000 0.2.0-rc.1

This release candidate broadens z2000's checked JPEG2000/JP2 profiles and adds
bounded raster-to-JP2 conversion front ends while keeping unsupported input
fail-closed.

Highlights Since 0.1.0-rc.1

• Added component-generic one- through four-plane paths, gray/RGB alpha
  semantics, mixed 8/16-bit precision, sampled component geometry, packed
  packet headers, and bounded sampled reversible encoding with quality layers,
  multi-tile layouts, and checked POC schedules.
• Added explicit sYCC conversion, bounded ICC v2/v4 RGB matrix/TRC conversion,
  and plane-preserving signalling for CMYK, default CIELab, e-sRGB, and e-sYCC.
• Added bounded BMP, PNG, baseline JPEG, LinearRaw DNG, and normalized-linear
  OpenEXR input adapters. Extension-inferred single-file commands and sorted,
  non-recursive wildcard batch conversion are available through z2k.
• Added byte-exact EXIF, XMP, and IPTC-IIM preservation from the bounded JPEG
  profile into checked JP2 UUID boxes.
• Capped and pooled the reversible 5/3 worker phase while retaining
  deterministic output across thread counts.

Release Candidate Policy

The CLI and Zig API remain unstable before 1.0. This is not a general JP2/JPX,
camera RAW, or HDR converter. Each input adapter has a deliberately narrow
documented envelope; progressive/arithmetic JPEG, Adam7 PNG, CFA/demosaicing,
compressed or tiled EXR, general ICC transforms, extended XMP, and semantic
metadata rewriting remain unsupported. JP2 metadata payloads are preserved but
are not yet restored into TIFF output.

The project's 100/100 ISO engineering scorecards are internal coverage tools,
not formal ISO conformance certification. The binaries are unsigned; verify
the platform archive against SHA256SUMS. Every archive contains identical
z2000 and z2k executables for the long and short command names.

z2000 0.1.0-rc.1

z2000 0.1.0-rc.1

This is the first public release candidate of z2000, an inspectable
JPEG2000 Part 1 codec and TIFF-to-JP2 conversion tool written in Zig.

Highlights

• Lossless RGB and grayscale TIFF-to-JP2 conversion for uncompressed chunky
  8-bit and 16-bit strips.
• Reversible RCT/5-3 and irreversible ICT/9-7 paths with strict no-sidecar
  decode.
• Single- and multi-tile coding, all five progression orders, quality layers,
  global rate allocation, PLT/TLM, POC, PPM/PPT, and the six Part 1 code-block
  style bits in their documented profile envelope.
• Optional ICC profile preservation without implicit pixel conversion.
• OpenJPEG, Grok, Kakadu, and jpylyzer interoperability gates for maintained
  profiles.
• Portable Zig vector kernels and multi-threaded encode/decode.

Release Candidate Policy

The CLI and internal Zig API are not stable before 1.0. Unsupported profile
combinations fail closed, but this release is not a general JP2/JPX decoder.
The project's 100/100 ISO engineering scorecards are internal coverage tools,
not formal ISO conformance certification.

Known boundaries include uncompressed strip-based TIFF input, bounded
component layouts, no JPX feature set, opaque ICC preservation rather than
color conversion, and no JPEG/PNG/BMP/RAW/OpenEXR conversion front ends yet.
See README.md and docs/iso_coverage.md for the exact supported envelope.

The downloadable binaries are currently unsigned. Verify the archive against
the accompanying SHA256SUMS file before use.