Clarify provenance and redistribution terms for progressive_libjpeg.jpg #6

Activity

1. Ttimmahlax

   added a commit that references this issue on Oct 28, 2026

   Merge pull request #25 from Remade-With-Rust/fix/6-fixture-provenance

   ...

   65528bb
2. Ttimmahlax

   closed this as completedin #25on Oct 28, 2026
3. Ttimmahlax commented on Oct 28, 2026

   

   Ttimmahlax

   on Oct 28, 2026

   Last edited by Ttimmahlax

   Contributor

   More actions

   Thanks for asking, and for checking the hash. Here's the honest answer.

   The original file (906 bytes, SHA-256 d2b6d930…, in 0.4.1 to 0.4.7). It's a 32x32 image encoded with Pillow/libjpeg for this regression test. The test needs a progressive file whose first, DC-only scan names an AC table before any DHT defines it, and our own encoder can't produce that layout. We don't have a record of where its pixel content came from, so we can't give you a provenance statement for that file.

   What we did instead (#25, merged). The fixture is now a synthetic 32x32 RGB gradient that tools/generate_progressive_libjpeg.py computes in code, with no external image involved, and encodes as a progressive JPEG with Pillow. The script is deterministic, so you can regenerate the file and check it byte for byte. Its marker layout is identical to the old file's, so the test still covers what it was written for. It's covered by the crate's MIT OR Apache-2.0 licence, and no further attribution is needed.

   For your 0.4.1 source distribution: the safest option is to replace tests/fixtures/progressive_libjpeg.jpg with the output of that script. The fixture only matters to the crate's own tests, so nothing in the library depends on it. One caveat: if you run the 0.4.1 test suite, golden_bytes_are_identical_across_build_arms in tests/no_std_surface.rs pins a hash of the decoded fixture, so update that pin as #25 does. The next rusty_jpeg release will ship the new file.

   🤖 Generated with Claude Code