Skip to content

BUG: Compare NIfTI test output by content, not by compressed bytes - #96

Open
hjmjohnson wants to merge 1 commit into
masterfrom
pr/test-gz-content-compare
Open

hjmjohnson wants to merge 1 commit into
masterfrom
pr/test-gz-content-compare

Conversation

@hjmjohnson

Copy link
Copy Markdown
Member

Re-submission of #31, reverted from master on 2026-09-24 so it can be
reviewed before merging. Content is unchanged from the original.

Base: master. Independent: nothing has to land before it.

Commits
  • BUG: Compare NIfTI test output by content, not by compressed bytes

Ordering for all the re-submitted work is tracked in #84.

nifti_c22_copy_image has been failing on this machine since before any of
this work started.  It converts an image i16 -> i64 -> i16 and asserts
the result matches the original, using

    cmp out.c22.0.i16.nii.gz out.c22.2.0.i16.nii.gz

That compares gzip output, which is not reproducible across zlib
implementations.  The system zlib here is zlib-ng 1.3.1, which Arch,
CachyOS and a growing number of distributions ship in place of stock
zlib; it encodes the same input differently.  Both files come out at
exactly 642454 bytes and differ from byte 321594 on.

The conversion itself is fine.  Decompressed, the two files are
byte-identical at 1114768 bytes each, so the round-trip through int64 and
back preserves the data exactly, which is what the test set out to check.
Confirmed the other way too: in an Ubuntu 24.04 container with stock
zlib 1.3, the test passes unmodified.

The test now decompresses before comparing, via a small nii_cmp helper
that falls back to plain cmp for uncompressed files.  With this the suite
is 92 of 92 on both zlib-ng and stock zlib; previously it was 91 of 92
on any zlib-ng system.

(cherry picked from commit 7d92f16)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants