Adjust converter to enable dataset processing even if errors occur#69
Conversation
|
Per our discussion, I think we need to clean the MRD header too, so the file produced by the converter is internally consistent 😄 When slice count differs:
When channel count differs:
|
|
Also, the conda build failed because of an upstream issue with the I've already fixed it in #66, and John approved, so I'll merge it now. |
| num_channels = dset.shape[1] if dset.ndim == 4 else 1 | ||
|
|
||
| _reconcile_slice_count(encoding_limits, num_slices, "K-space") | ||
| if dset.ndim == 4 and num_channels != header_channels: |
There was a problem hiding this comment.
I think the condition if dset.ndim == 4 is incorrect and should just be removed.
If the data has only one channel/coil, then dset.ndim == 3, but we still need to make sure the MRD Header only has one coil label.
And you might as well put this block into a _reconcile_coil_count() helper function too for symmetry 👍
There was a problem hiding this comment.
let me know if I got that right :)
Tested this on FastMRI knee and brain data, as well as Mosaic (new data source) data. Brain data and mosaic data was not converting correctly, below is the summary of why, both appear as artifacts of how the data we acquired was built.
Slice count (header 32 vs dataset 16, your brain file)
The fastMRI public brain release intentionally ships only a subset of the acquired slices (typically the diagnostically central ones) to control file size. The XML header is preserved verbatim from the original Siemens acquisition, which had the full 32. The fastMRI documentation/papers note this — the slice subsetting is a release-time decision, not a corruption. Trusting the dataset's first axis is the right call.
Axis order swap (Siemens twix file) — non-conforming layout.
The data is internally consistent (640 still matches matrix_size.x. What's broken is the storage convention — whoever repackaged the twix dump into the fastMRI HDF5 layout wrote phase-encode-first instead of readout-first. The samples themselves are intact, just transposed. So reconstruction will be correct as long as transpose happens on read, which is what the swapped branch does. Worth flagging upstream as a metadata/layout bug in the repackager, but the pixel data is fine.