---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [June 26, 2025, 12:04pm UTC](https://discourse.itk.org/t/long-double-support-for-imageio-meshio-pixels/7570/5 "2025-06-26T12:04:28Z")
Does “long double” for ImageIO provide anything meaningful? Does any Image file format support “long double”?
Also how would FLOAT80 be stores as in a buffer? 3-bytes with poor alignment? 4-bytes?
I don’t see a need to for this and you state that you don’t have a use case either. There are details here that could be done incorrectly that would cause more problems if an implementation with a well defined use case was required.
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [June 26, 2025, 1:56pm UTC](https://discourse.itk.org/t/long-double-support-for-imageio-meshio-pixels/7570/6 "2025-06-26T13:56:11Z")
Brad, do you prefer leaving things as is, or removing LDOUBLE from MeshIO?
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [June 26, 2025, 2:14pm UTC](https://discourse.itk.org/t/long-double-support-for-imageio-meshio-pixels/7570/7 "2025-06-26T14:14:18Z")
I do not know if the MeshIO is usable or functional with long double. A quick grep though the IO code seems to indicate that there are a large number of occurrences of LDOUBLE in many of the MeshIO implementation so this would indicate good support for it at one point.
The ImageIOBase::IOComponentEnum is already itk::IOComponentEnum which contains LDOUBLE in the enum. So it looks like this enum is already valid if ImageIO classes.
In that context, defining the behavior or LDOUBLE for imageIO seems more reasonable. I hope that all the ImageIO implementations have correct handling of the “default” case for this enum.
---
### Author:  [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)
#### Post date: [June 26, 2025, 3:13pm UTC](https://discourse.itk.org/t/long-double-support-for-imageio-meshio-pixels/7570/8 "2025-06-26T15:13:51Z")
Ideally I would like to move the enum class `{ UCHAR, CHAR, ..., LDOUBLE }`, as well as the type-to-enum-value map (`Map...Type`) to “Core/Common”, so that they can be shared between the ImageIO and MeshIO. What do you think?
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [June 26, 2025, 3:26pm UTC](https://discourse.itk.org/t/long-double-support-for-imageio-meshio-pixels/7570/9 "2025-06-26T15:26:25Z")
Isn’t the `IOComponent` already in Core/Common/itkCommonEnums.h? What change are you proposing?
Have a common ctype-to-enum-value map seems to be a good idea to me.
---
### Author:  [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)
#### Post date: [June 26, 2025, 6:03pm UTC](https://discourse.itk.org/t/long-double-support-for-imageio-meshio-pixels/7570/10 "2025-06-26T18:03:57Z")
Yes indeed, `IOComponent` is already in [Core/Common/itkCommonEnums.h](https://github.com/InsightSoftwareConsortium/ITK/blob/ac62746139aee8bd6222db385b2394238bb592bb/Modules/Core/Common/include/itkCommonEnums.h#L77). (Sorry I was mistaken!)
So I would then just propose a common ctype-to-enum-value map.
Note that there appears another difference between `MeshIOBase` and `ImageIOBase`. `MeshIOBase::MapComponentType` unconditionally maps `char` to `CHAR`, whereas `ImageIOBase::MapPixelType` maps `char` to either `CHAR` or `UCHAR`, depending on the signedness of `char`: if `char` is signed, it is mapped to `CHAR`, otherwise to `UCHAR`. This difference should also be resolved, when introducing a common ctype-to-enum-value map.
Currently `IOComponent` has distinct enum values for two char types: CHAR and UCHAR. I think it would be easier if we would have an extra enum value for SIGNED\_CHAR, because in C++ `char` and `signed char` are distinct type. And then unconditionally map `char` to CHAR, and `signed char` to SIGNED\_CHAR, right? Or would that break too much legacy code?
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [June 26, 2025, 6:38pm UTC](https://discourse.itk.org/t/long-double-support-for-imageio-meshio-pixels/7570/11 "2025-06-26T18:38:07Z")
> [@Niels\_Dekker](#):
>
> Currently `IOComponent` has distinct enum values for two char types: CHAR and UCHAR. I think it would be easier if we would have an extra enum value for SIGNED\_CHAR, because in C++ `char` and `signed char` are distinct type. And then unconditionally map `char` to CHAR, and `signed char` to SIGNED\_CHAR, right? Or would that break too much legacy code?
It sounds like you are thinking the CHAR enum is describing the `char` C type ( which is incorrect). The actual usage of it is to describe a signed char/8-bit type. Changing the definition of the CHAR enum would not be good. Perhaps adding an alias of “SIGNED\_CHAR == CHAR” would be descriptive and useful.
Also 8-bit integers are only signed or unsigned. The three states of C’s “char” types is an artifact of C and not data. The ImageIO interface really should be describing what is stored on the disk and not the state of types and sizes at programming language level, IMHO. That is to say I have a long term frustration with this interface not providing fixed width integer types.
---
### Author:  [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)
#### Post date: [June 26, 2025, 6:50pm UTC](https://discourse.itk.org/t/long-double-support-for-imageio-meshio-pixels/7570/12 "2025-06-26T18:50:35Z")
> It sounds like you are thinking the CHAR enum is describing the `char` C type
Thanks, but I guess most users would think so as well. 🤷 And so does `MeshIOBase`. (Assuming that `MeshIOBase` can actually _think_ 😉.)
> [@blowekamp](#):
>
> That is to say I have a long term frustration with this interface not providing fixed width integer types.
_That_ frustration is over now, right? 😃
[ENH: Fixed width type enums (INT8, UINT64, FLOAT64, ...) for IOComponent by N-Dekker · Pull Request #5410 · InsightSoftwareConsortium/ITK · GitHub](https://github.com/InsightSoftwareConsortium/ITK/pull/5410)
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [June 26, 2025, 7:11pm UTC](https://discourse.itk.org/t/long-double-support-for-imageio-meshio-pixels/7570/13 "2025-06-26T19:11:09Z")
But the CHAR enum type ( for ImageIO ) currently must represents signed 8-bit data. There is not other way to represent as a component type, so it much be signed:
>
(Those later cases look like they can be conveniently updated with the new fixed types. )
And yes, 8-bit signed data is real and common with certain file formats. Java does not have an 8-bit unsigned data type. So for Java developer signed 8-bit data/images are very natural.
---
### Author:  [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)
#### Post date: [June 30, 2025, 11:18am UTC](https://discourse.itk.org/t/long-double-support-for-imageio-meshio-pixels/7570/14 "2025-06-30T11:18:31Z")
FYI, This pull request of mine is somewhat related:
>
>
> Follow-up to pull request https://github.com/InsightSoftwareConsortium/ITK/pull/…5421 commit b209c1a00f2cc042172996631d8cf5a06658fd1a
> "STYLE: Remove template specializations of \`ImageIOBase::MapPixelType\`"
>
> Note that \`MeshIOBase::MapComponentType\` supports \`long double\` as pixel component type, whereas \`ImageIOBase::MapPixelType\` does not. Moreover, \`MeshIOBase::MapComponentType\` unconditionally maps \`char\` to \`CHAR\`, whereas \`ImageIOBase::MapPixelType\` maps \`char\` to either \`CHAR\` or \`UCHAR\`, depending on the signedness of \`char\`.
Please note this pull request in it current state is only a _style_ PR. It does not address the different behavior between MeshIO and ImageIO regarding the type mapping of CHAR and LDOUBLE (long double). So it may be processed independently.
---
### Author:  [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)
#### Post date: [July 1, 2025, 11:23am UTC](https://discourse.itk.org/t/long-double-support-for-imageio-meshio-pixels/7570/15 "2025-07-01T11:23:21Z")
I see, SimpleITK’s `sitkImageReaderBase` maps `IOComponentEnum::CHAR` to `int8_t` (which is a signed integer type, by definition), whereas ITK’s `itk::ImageFileReader` maps `IOComponentEnum::CHAR` to `char` (which _might_ be an unsigned integer type):
>
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [July 2, 2025, 1:52pm UTC](https://discourse.itk.org/t/long-double-support-for-imageio-meshio-pixels/7570/16 "2025-07-02T13:52:41Z")
Interesting, thanks of sharing.
For the imageIOs which support signed 8-bit data, they are most likely reporting their data as ENUM::CHAR. Perhaps, “CHAR” should be changed to “signed char”? I think there are some portability issue with the current definitions, but I think it was “working” in practice so it was left alone.
A couple examples:
>
>
Also note I am actively using sighed 8-bit images, for the MRC image file format.
The argument for just the “char” type for being useful would be to represent text. Which I don’t think make sense for the ImageIO class. I don’t believe that this enum is used to represent any meta-data? If you did want to represent text where is a whole other set of text encoding that would be relevant, and that is not something that should opened up.
---
### Author:  [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)
#### Post date: [July 2, 2025, 4:17pm UTC](https://discourse.itk.org/t/long-double-support-for-imageio-meshio-pixels/7570/17 "2025-07-02T16:17:49Z")
Thanks @blowekamp
Honestly I don’t know if it’s useful to have a pixel type `char` to represent text. If we agree to only support `signed char` and `unsigned char` (but not plain `char`), I would suggest renaming the enum `CHAR` to `SIGNED_CHAR`.
On the other hand, if there is a use case for plain `char` pixels, let it map unconditionally to the enum `CHAR`, and add a `SIGNED_CHAR` enum, unconditionally mapping `signed char` (not plain `char`).
But honestly I don’t know what to choose 🤷