Skip to content

ENH: Add ctype aliases for numeric types of specific sizes to Python - #6762

Merged
dzenanz merged 1 commit into
InsightSoftwareConsortium:mainfrom
N-Dekker:ctype-aliases-for-numeric-types-of-specific-sizes
Aug 19, 2026
Merged

ENH: Add ctype aliases for numeric types of specific sizes to Python#6762
dzenanz merged 1 commit into
InsightSoftwareConsortium:mainfrom
N-Dekker:ctype-aliases-for-numeric-types-of-specific-sizes

Conversation

@N-Dekker

@N-Dekker N-Dekker commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Added the following aliases:

float32_t
float64_t
uint8_t
uint16_t
uint32_t
uint64_t
int8_t
int16_t
int32_t
int64_t

Aims to provide a more human-readable alternative to F, D, UC, US, UI, ULL, SC, SS, SI, and SLL. Eases writing code for which the specific size of numeric types should be platform-independent.

Typical use cases, specifying the pixel type of an image:

  • itk.Image[itk.uint8_t, 2] (equivalent to itk.Image[itk.UC, 2])
  • itk.Image[itk.float64_t, 2] (equivalent to itk.Image[itk.D, 2])
  • itk.Image[itk.int64_t, 2] (equivalent to itk.Image[itk.SL, 2] on Linux and itk.Image[itk.SLL, 2] on Windows)

For the record, this comment is updated, following the replacement of the _ctype postfixes with _t (see #6762 (comment) and this force-pushed amend)

@github-actions github-actions Bot added type:Infrastructure Infrastructure/ecosystem related changes, such as CMake or buildbots type:Enhancement Improvement of existing methods or implementation area:Python wrapping Python bindings for a class type:Testing Ensure that the purpose of a class is met/the results on a wide set of test cases are correct labels Aug 12, 2026
@N-Dekker
N-Dekker force-pushed the ctype-aliases-for-numeric-types-of-specific-sizes branch 2 times, most recently from 30289a6 to bbffc33 Compare August 12, 2026 22:27
@N-Dekker N-Dekker changed the title ENH: Aliases ctype aliases for numeric types of specific sizes to Python ENH: Add ctype aliases for numeric types of specific sizes to Python Aug 12, 2026
@N-Dekker
N-Dekker marked this pull request as ready for review August 13, 2026 08:19
@greptile-apps

greptile-apps Bot commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This change adds top-level Python aliases for fixed-width integer and floating-point ITK C types, with regression coverage registered for their NumPy dtype mappings.

Confidence Score: 5/5

No blocking failure remains.

No accepted blocking findings remain.

T-Rex T-Rex Logs

What T-Rex did

  • The team attempted the documented Pixi build command and observed it could not progress because the Pixi package manager was not installed.
  • The team attempted the registered focused test with the build-tree using PYTHONPATH and observed a ModuleNotFoundError for itk, indicating that ITK Python is not built or installed in the environment.
  • The blockers were captured and a path forward was outlined: install Pixi, build the declared Python 3.13 ITK wrapper environment, then re-run the build commands and the ctest suite.

View all artifacts

T-Rex Ran code and verified through T-Rex

Reviews (2): Last reviewed commit: "ENH: Add ctype aliases for numeric types..." | Re-trigger Greptile

Comment thread Wrapping/Generators/Python/itk/support/types.py Outdated
@N-Dekker
N-Dekker marked this pull request as draft August 13, 2026 14:39
@N-Dekker
N-Dekker force-pushed the ctype-aliases-for-numeric-types-of-specific-sizes branch from bbffc33 to faaacd4 Compare August 13, 2026 15:53
@N-Dekker
N-Dekker marked this pull request as ready for review August 13, 2026 15:57
@thewtex

thewtex commented Aug 13, 2026

Copy link
Copy Markdown
Member

@N-Dekker

N-Dekker commented Aug 13, 2026

Copy link
Copy Markdown
Contributor Author

How about using uint8, etc per:
https://github.com/InsightSoftwareConsortium/ITK/blob/main/Wrapping/Generators/Python/itk/support/extras.py#L266-L295
?

Thanks Matt, can you please elaborate a little bit? For example, how would you define a 2D itk Image of int64 pixels? With the proposed PR, it would be itk.Image[itk.int64_ctype, 2].


P.S. It looks like there is a bug at

np.dtype(np.int64): itk.SL,

    # This is a Mapping from numpy array types to itk pixel types. (Bug?)
    _np_itk = {
        ...
        np.dtype(np.int64): itk.SL,
        ...
     }

itk.SL is not int64, on Windows. Once this pull request is merged, it can be fixed by doing:

    # This is a Mapping from numpy array types to itk pixel types. (Fixed!)
    _np_itk = {
        ...
        np.dtype(np.int64): itk.int64_ctype,
        ...
     }

Is that what you meant to say?

@thewtex

thewtex commented Aug 14, 2026

Copy link
Copy Markdown
Member

itk.Image[itk.int64_ctype, 2].

I think it would be easier to write, easier to read, and more expected names if we had itk.Image[itk.int64, 2] or itk.Image[np.int64, 2].

np.dtype(np.int64): itk.SL,

Good catch!

@N-Dekker
N-Dekker force-pushed the ctype-aliases-for-numeric-types-of-specific-sizes branch from faaacd4 to 1d06a17 Compare August 15, 2026 09:01
@N-Dekker

Copy link
Copy Markdown
Contributor Author

Update: Inspired by Matt's comments, I just renamed the proposed aliases (with this force-pushed amend) to:

float32_t
float64_t
uint8_t
uint16_t
uint32_t
uint64_t
int8_t
int16_t
int32_t
int64_t

Under the hood, they are still simply aliases of itk.F, itk.D, itk.UC, etc.

The PR will now allow users to write (for example) itk.Image[itk.int64_t, 2], which looks very similar to the C++ equivalent, itk::Image<std::int64_t, 2>.

Hope that it's good enough now!

Added the following aliases:

    float32_t
    float64_t
    uint8_t
    uint16_t
    uint32_t
    uint64_t
    int8_t
    int16_t
    int32_t
    int64_t

Aims to provide a more human-readable alternative to F, D, UC, US, UI, UL, ULL,
SC, SS, SI, SL, SLL, etc. Eases writing code for which the specific size of
numeric types should be platform-independent.
@N-Dekker
N-Dekker force-pushed the ctype-aliases-for-numeric-types-of-specific-sizes branch from 1d06a17 to dc0ea28 Compare August 15, 2026 21:29
@blowekamp

Copy link
Copy Markdown
Member

Does itk.Image[np.int64, 2] already work? I know it's not in this PR, but both of Matt's examples looked intuitive to me as a python user.

@blowekamp
blowekamp self-requested a review August 18, 2026 12:02
@N-Dekker

Copy link
Copy Markdown
Contributor Author

Thanks for your approval, @blowekamp

Does itk.Image[np.int64, 2] already work?

No, itk.Image[np.int64, 2] does not work, sorry. I tried:

import itk
import numpy as np
image_type = itk.Image[np.int64, 2]

It said:

Traceback (most recent call last):
  File "...\Lib\site-packages\itk\support\template_class.py", line 526, in __getitem__
    this_item = self.__template__[key]
                ~~~~~~~~~~~~~~~~~^^^^^
KeyError: (<class 'numpy.int64'>, 2)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "...\my_arithmetic_types.py", line 3, in <module>
    image_type = itk.Image[np.int64, 2]
                 ~~~~~~~~~^^^^^^^^^^^^^
  File "...\Lib\site-packages\itk\support\template_class.py", line 530, in __getitem__
    raise itk.TemplateTypeError(self, key)
itk.support.extras.TemplateTypeError: itk.Image is not wrapped for input type `int64, int`.

To limit the size of the package, only a limited number of
types are available in ITK Python. To print the supported
types, run the following command in your python environment:

    itk.Image.GetTypes()

Possible solutions:
* If you are an application user:
** Convert your input image into a supported format (see below).
** Contact developer to report the issue.
* If you are an application developer, force input images to be
loaded in a supported pixel type.

    e.g.: instance = itk.Image[itk.RGBPixel[itk.UC], int].New(my_input)

* (Advanced) If you are an application developer, build ITK Python yourself and
turned to `ON` the corresponding CMake option to wrap the pixel type or image
dimension you need. When configuring ITK with CMake, you can set
`ITK_WRAP_${type}` (replace ${type} with appropriate pixel type such as
`double`). If you need to support images with 4 or 5 dimensions, you can add
these dimensions to the list of dimensions in the CMake variable
`ITK_WRAP_IMAGE_DIMS`.

Supported input types:

itk.RGBPixel[itk.UC]
itk.RGBAPixel[itk.UC]
itk.Vector[itk.F,2]
itk.Vector[itk.F,3]
itk.Vector[itk.F,4]
itk.CovariantVector[itk.F,2]
itk.CovariantVector[itk.F,3]
itk.CovariantVector[itk.F,4]
itk.SS
itk.UC
itk.US
itk.F
itk.D
itk.complex[itk.D]
itk.complex[itk.F]
itk.Vector[itk.D,2]
itk.Vector[itk.D,3]
itk.Vector[itk.D,4]
itk.SI
itk.UI
itk.UL
itk.ULL
itk.B
itk.FixedArray[itk.F,2]
itk.FixedArray[itk.D,2]
itk.Offset[2]
itk.SymmetricSecondRankTensor[itk.D,2]
itk.SymmetricSecondRankTensor[itk.F,2]
itk.RGBPixel[itk.UC]
itk.RGBAPixel[itk.UC]
itk.Vector[itk.F,2]
itk.Vector[itk.F,3]
itk.Vector[itk.F,4]
itk.CovariantVector[itk.F,2]
itk.CovariantVector[itk.F,3]
itk.CovariantVector[itk.F,4]
itk.SS
itk.UC
itk.US
itk.F
itk.D
itk.complex[itk.D]
itk.complex[itk.F]
itk.Vector[itk.D,2]
itk.Vector[itk.D,3]
itk.Vector[itk.D,4]
itk.SI
itk.UI
itk.UL
itk.ULL
itk.B
itk.FixedArray[itk.F,3]
itk.FixedArray[itk.D,3]
itk.Offset[3]
itk.SymmetricSecondRankTensor[itk.D,3]
itk.SymmetricSecondRankTensor[itk.F,3]
itk.RGBPixel[itk.UC]
itk.RGBAPixel[itk.UC]
itk.Vector[itk.F,2]
itk.Vector[itk.F,3]
itk.Vector[itk.F,4]
itk.CovariantVector[itk.F,2]
itk.CovariantVector[itk.F,3]
itk.CovariantVector[itk.F,4]
itk.SS
itk.UC
itk.US
itk.F
itk.D
itk.complex[itk.D]
itk.complex[itk.F]
itk.Vector[itk.D,2]
itk.Vector[itk.D,3]
itk.Vector[itk.D,4]
itk.SI
itk.UI
itk.UL
itk.ULL
itk.B
itk.FixedArray[itk.F,4]
itk.FixedArray[itk.D,4]
itk.Offset[4]
itk.SymmetricSecondRankTensor[itk.D,4]
itk.SymmetricSecondRankTensor[itk.F,4]
itk.Vector[itk.F,1]
itk.Vector[itk.F,1]
itk.Vector[itk.D,2]
itk.Vector[itk.D,3]
itk.Vector[itk.D,4]
itk.Vector[itk.F,1]
itk.CovariantVector[itk.D,2]
itk.CovariantVector[itk.D,3]
itk.CovariantVector[itk.D,4]
itk.CovariantVector[itk.D,2]
itk.CovariantVector[itk.D,3]
itk.CovariantVector[itk.D,4]
itk.CovariantVector[itk.D,2]
itk.CovariantVector[itk.D,3]
itk.CovariantVector[itk.D,4]
itk.NormalBandNode[itk.Image[itk.F,2]]
itk.NormalBandNode[itk.Image[itk.D,2]]
itk.NormalBandNode[itk.Image[itk.F,3]]
itk.NormalBandNode[itk.Image[itk.D,3]]
itk.NormalBandNode[itk.Image[itk.F,4]]
itk.NormalBandNode[itk.Image[itk.D,4]]

Press any key to continue . . .

@N-Dekker

N-Dekker commented Aug 18, 2026

Copy link
Copy Markdown
Contributor Author

As a follow-up, it might be nice to add support for using a NumPy type to specify the pixel type of an itk.Image. But I think there should still be a direct and ITK-specific way as well, for users to specify a pixel type of a specific size.

@thewtex thewtex left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@N-Dekker nice! LGTM! 🥇

@N-Dekker

Copy link
Copy Markdown
Contributor Author

Thanks for your approval, @thewtex, @dzenanz, @blowekamp

When it's merged, I'm considering a style PR to replace code of the form:

if os.name == "nt":
use itk.SLL
else:
use itk.SL

With simply just: use itk.int64_t. To be continued... 😃

@dzenanz
dzenanz merged commit f1daa03 into InsightSoftwareConsortium:main Aug 19, 2026
19 checks passed
N-Dekker added a commit to N-Dekker/ITK that referenced this pull request Aug 19, 2026
Replaced `if os.name == "nt"` statements which used `itk.SL`, `itk.SLL`,
`itk.UL`, or `itk.ULL` with the equivalent code, using just `itk.int64_t` or
`itk.uint64_t`.

Aims to improve code readability and remove OS-specific code.

Follow-up to pull request InsightSoftwareConsortium#6762
commit dc0ea28
"ENH: Add CType aliases for numeric types of specific sizes to Python"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:Python wrapping Python bindings for a class type:Enhancement Improvement of existing methods or implementation type:Infrastructure Infrastructure/ecosystem related changes, such as CMake or buildbots type:Testing Ensure that the purpose of a class is met/the results on a wide set of test cases are correct

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants