v0.7.0

Highlights

This release fixes how Image-Codes longer than 64 bits are calculated. It follows the same fix in
the iscc-core 1.5.0 reference
implementation and brings iscc-lib in line with ISO 24138:2024 §5.4.5.2 e).

Breaking changes

Image-Codes longer than 64 bits change. This affects all languages.

• What was wrong: bits 65–256 of an Image-Code came from 8×8 squares of the DCT coefficients
  shifted by only one coefficient from the first square. The squares overlapped almost entirely,
  so the extra bits added very little information.
• What it does now: the four 64-bit blocks come from the top-left, top-right, bottom-left and
  bottom-right 8×8 squares of the upper-left 16×16 DCT coefficients, as the standard specifies.
• Not affected:
  • 32-bit and 64-bit Image-Codes. 64 bits is the default.
  • ISCC-CODEs, which use 64-bit units.
  • All other code types.
• What to do: if you store Image-Codes at 96, 128 or 256 bits, regenerate them. The first 64
  bits are unchanged, but bits beyond 64 can't be compared between old and new codes.
• API: no changes on any surface. cargo semver-checks passes.

Conformance and robustness

• The conformance test vectors are updated to iscc-core 1.5.0. conformance_selftest() now
  checks the corrected 256-bit Image-Code vector.
• New layout tests in the Rust core and the pure-Go port check each 64-bit block of a 256-bit
  Image-Code against its 8×8 DCT square. A test like this would have caught the bug.

Packaging and toolchains

• npm packages (@iscc/lib, @iscc/wasm) are now published via npm trusted publishing (OIDC),
  with provenance attestations.

Published to

crates.io, PyPI, npm (@iscc/lib, @iscc/wasm), Maven Central (Java and Kotlin),
RubyGems, NuGet, Go proxy, Swift Package Manager and GitHub Releases (C FFI).
Documentation: https://lib.iscc.codes/

What's Changed

• Release 0.7.0 by @titusz in #49

Full Changelog: v0.6.0...v0.7.0