fix(image-io): resolve IWI CBOR round-trip corruption for uint8 images#1485
Open
fix(image-io): resolve IWI CBOR round-trip corruption for uint8 images#1485
Conversation
Make ReadCBOR key-order independent by deferring pixel data copy until after all metadata keys are processed. Previously, if the 'data' key appeared before 'imageType' or 'size' in the CBOR map, GetImageSizeInBytes() would use default values (float32), causing a 4x buffer overread for uint8 images and producing corrupted output. Also skip unknown CBOR map keys instead of throwing, improving interoperability with third-party CBOR writers like NiiVue's cbor-x. Add uint64 to the glaze enumerate list in itkComponentTypesJSON.h so JSON deserialization of uint64 componentType no longer silently fails. Replace empty Python test stubs with comprehensive tests covering IWI CBOR read, write, zstd read/write, and cross-format round-trips (PNG/MHA/NRRD through IWI CBOR) for multiple component types.
quay.io is having multi-arch manifest issues.
…forward compatibility Replace itkExceptionMacro throws with silent skips for unrecognized CBOR map keys in ReadCBOR across all three IO classes: - itkWasmImageIO: imageType inner sub-map (top-level was already fixed) - itkWasmMeshIO: meshType inner sub-map + explicit top-level else clause - itkWasmTransformIO: transformType inner sub-map + explicit top-level else clause This improves interoperability with third-party CBOR writers (e.g. NiiVue) that may include additional or extended fields in the type sub-maps. Also replace empty test stubs in transform-io with real round-trip tests for wasm-zstd and MNC (.xfm) formats, using programmatically created affine transforms to avoid dependency on IPFS test data downloads.
2a34266 to
a595527
Compare
c844031 to
5620cae
Compare
5620cae to
dfacf23
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Make ReadCBOR key-order independent by deferring pixel data copy until
after all metadata keys are processed. Previously, if the 'data' key
appeared before 'imageType' or 'size' in the CBOR map, GetImageSizeInBytes()
would use default values (float32), causing a 4x buffer overread for uint8
images and producing corrupted output.
Also skip unknown CBOR map keys instead of throwing, improving
interoperability with third-party CBOR writers like NiiVue's cbor-x.
Add uint64 to the glaze enumerate list in itkComponentTypesJSON.h so
JSON deserialization of uint64 componentType no longer silently fails.
Replace empty Python test stubs with comprehensive tests covering
IWI CBOR read, write, zstd read/write, and cross-format round-trips
(PNG/MHA/NRRD through IWI CBOR) for multiple component types.