BUG: MINCImageIO should use signed char for CHAR and MI_TYPE_BYTE
#5470
Conversation
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
`MINCImageIO::Write` should use `signed char` for the estimation of the min and the max pixel value, when the pixel component type is `IOComponentEnum::CHAR`. Both `IOComponentEnum::CHAR` and `MI_TYPE_BYTE` specify a _signed_ type, whereas the default `char` might be unsigned (for example, when using GCC compiler option `-funsigned-char`). Obviously the estimation of min and max pixel value may go wrong when the pixels are incorrectly assumed to be unsigned.
github-actions
bot
added
type:Bug
Member
|
Glad to hear that compiler flag has been useful to track down issues! |
Contributor
|
@gdevenyi may interest you |
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a bug in MINCImageIO where the wrong char type was used for min/max pixel value calculations. The issue occurs when IOComponentEnum::CHAR and MI_TYPE_BYTE are used with compilers that default to unsigned char (e.g., GCC with -funsigned-char), leading to incorrect pixel value range estimation.
- Changes
chartosigned charin the template parameter forget_buffer_min_maxfunction call - Ensures consistent handling of signed byte data regardless of compiler char signedness defaults
thewtex
merged commit 87a4fff
into
InsightSoftwareConsortium:main
16 of 17 checks passed
N-Dekker
added a commit
to N-Dekker/ITK
that referenced
this pull request
Jul 16, 2025
Both `VTKPolyDataMeshIO::WritePoints` and `VTKPolyDataMeshIO::WritePointData` originally casted the `buffer` to plain `char *` for component type `CHAR` (using `CASE_INVOKE_WITH_COMPONENT_TYPE`). However, `CHAR` indicates that the component type is _signed_ char, whereas the default `char` might be unsigned. Follow-up to pull request InsightSoftwareConsortium#5470 commit 70fbb2b "BUG: MINCImageIO should use `signed char` for `CHAR` and `MI_TYPE_BYTE`"
N-Dekker
added a commit
to N-Dekker/ITK
that referenced
this pull request
Jul 17, 2025
`VTKPolyDataMeshIO` originally casted the `buffer` to plain `char *` for component type `CHAR`. However, `CHAR` indicates that the component type is _signed_ char, whereas the default `char` might be unsigned. Follow-up to pull request InsightSoftwareConsortium#5470 commit 70fbb2b "BUG: MINCImageIO should use `signed char` for `CHAR` and `MI_TYPE_BYTE`"
N-Dekker
added a commit
to N-Dekker/ITK
that referenced
this pull request
Jul 25, 2025
`VTKPolyDataMeshIO` originally casted the `buffer` to plain `char *` for component type `CHAR`. However, `CHAR` indicates that the component type is _signed_ char, whereas the default `char` might be unsigned. Follow-up to pull request InsightSoftwareConsortium#5470 commit 70fbb2b "BUG: MINCImageIO should use `signed char` for `CHAR` and `MI_TYPE_BYTE`"
N-Dekker
added a commit
to N-Dekker/ITK
that referenced
this pull request
Aug 27, 2025
`VTKPolyDataMeshIO` originally casted the `buffer` to plain `char *` for component type `CHAR`. However, `CHAR` indicates that the component type is _signed_ char, whereas the default `char` might be unsigned. Follow-up to pull request InsightSoftwareConsortium#5470 commit 70fbb2b "BUG: MINCImageIO should use `signed char` for `CHAR` and `MI_TYPE_BYTE`"
N-Dekker
added a commit
to N-Dekker/ITK
that referenced
this pull request
Oct 10, 2025
`VTKPolyDataMeshIO` originally casted the `buffer` to plain `char *` for component type `CHAR`. However, `CHAR` indicates that the component type is _signed_ char, whereas the default `char` might be unsigned. Follow-up to pull request InsightSoftwareConsortium#5470 commit 70fbb2b "BUG: MINCImageIO should use `signed char` for `CHAR` and `MI_TYPE_BYTE`"
N-Dekker
added a commit
to N-Dekker/ITK
that referenced
this pull request
Oct 10, 2025
`VTKPolyDataMeshIO` originally casted the `buffer` to plain `char *` for component type `SCHAR`. However, `SCHAR` indicates that the component type is _signed_ char. Follow-up to pull request InsightSoftwareConsortium#5470 commit 70fbb2b "BUG: MINCImageIO should use `signed char` for `CHAR` and `MI_TYPE_BYTE`"
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
MINCImageIO::Writeshould usesigned charfor the estimation of the min and the max pixel value, when the pixel component type isIOComponentEnum::CHAR. BothIOComponentEnum::CHARandMI_TYPE_BYTEspecify a signed type, whereas the defaultcharmight be unsigned (for example, when using GCC compiler option-funsigned-char).Obviously the estimation of min and max pixel value may go wrong when the pixels are incorrectly assumed to be unsigned.
@blowekamp This little bug fix is still a spinoff from your suggestion to try to build ITK using
-funsigned-char😃