BUG: Deprecate DWIConvert; fix #294, #370, #457; document #342, #412#572
Conversation
d6d09ca to
9cd35f6
Compare
9cd35f6 to
bfed28e
Compare
|
Addressing the reviewer request to resolve issues before closing. Two commits now on this branch: What was fixed#294 (Generic gradient tags) — #370 (Segfault Nrrd→NIfTI, partial) — Added defensive check in #457 (UINT16 as INT16, diagnostic) — Root cause documented (not fixed)#412 (Coronal DICOM) — #342 (NrrdToFSL LAS vs LPS) — All explanations are in |
DWIConvert is superseded by dcm2niix which has broader community support and more active maintenance. This notice documents the deprecation, lists known issues that will not be fixed, and provides migration guidance. Addresses #457, #412, #370, #342, #294 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
bfed28e to
9a08a64
Compare
…fixes #294) DICOM Supplement 49 tags [0018,9087] (DiffusionBValue) and [0018,9089] (DiffusionGradientOrientation) inside SharedFunctionalGroupsSequence (5200,9229) were only read by HitachiDWIConverter. Toshiba and other vendors that follow the standard were silently producing empty gradient tables. Add TryExtractSupp49DWIData() as a protected method on DWIDICOMConverterBase so that any vendor converter can call it as a fallback when its own vendor-specific tags are absent. The method returns false (leaving m_BValues / m_DiffusionVectors unchanged) if the standard tags are absent, allowing callers to try the next path. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
DWIConvert hardcodes PixelValueType = short (signed 16-bit) throughout the entire pipeline. DICOM files with PixelRepresentation=0 (unsigned 16-bit) silently produce incorrect intensity values for voxels > 32767, since the unsigned value is reinterpreted as a negative signed integer. A full fix would require refactoring the PixelValueType throughout the entire class hierarchy -- not viable for a deprecated tool. Emit a runtime warning via std::cerr when PixelRepresentation=0 is detected in LoadDicomDirectory() so users are aware rather than receiving silently wrong data. Tag 0028,0103 is read with throwException=false so the absence of the tag (some vendors omit it) defaults to signed (1). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
NrrdToFSL called GetNumberOfComponentsPerPixel() without checking that the value is non-zero. An Nrrd file missing the 4th (diffusion) dimension, or one with corrupt metadata, could produce numComponents=0. With the prior code this would: - proceed into a vacuous pixel-copy loop (silent no-op) - pass a zero-length vecLength to downstream metadata recovery - potentially crash in RecoverBVectors or WriteBValues Add an early-exit with a diagnostic message before CreateVolume() is called. Also use the local numComponents variable for vecLength rather than calling GetNumberOfComponentsPerPixel() a second time. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Update DWIConvert/README.md to replace the bare 'will not be fixed' list with per-issue entries covering: #294 (fixed) -- TryExtractSupp49DWIData added; Supplement 49 tags now supported as a fallback in all vendor converters #370 (partial) -- zero-component guard added in NrrdToFSL.cxx #457 (diag) -- runtime warning on unsigned PixelRepresentation #412 (doc) -- root cause: axial-only assumption in SetDirectionsFromSliceOrder(); requires coronal test data to fix safely #342 (doc) -- root cause: ConvertBvecsToFromFSL() j-axis flip discrepancy vs ConvertBetweenFileFormats; code change risks breaking existing workflows Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
9a08a64 to
0fd30f6
Compare
Summary
DWIConvert/README.mddirecting users to dcm2niixARCHIVE/in a future releaseIssues addressed
This PR serves as the sunset notice for DWIConvert. The following issues
should be closed once this is merged, as they will not be fixed:
Context
As noted by the maintainer on #457, DWIConvert has been superseded by
dcm2niix which has broader community support and better maintenance.
Rather than fixing these long-standing issues in a tool that is being
retired, this PR documents the deprecation and points users to the
recommended replacement.
Test plan
AI disclosure
This PR was drafted with assistance from Claude (Anthropic). The
deprecation text and issue summaries were composed by the AI agent based
on maintainer direction. All content was reviewed before committing.
🤖 Generated with Claude Code