ENH: Add ctype aliases for numeric types of specific sizes to Python by N-Dekker · Pull Request #6762 · InsightSoftwareConsortium/ITK

N-Dekker · 2026-08-12T22:24:34Z

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)

greptile-apps · 2026-08-13T08:25:13Z

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 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.

_{Ran code and verified through T-Rex}

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

thewtex · 2026-08-13T19:46:34Z

How about using uint8, etc per:

https://github.com/InsightSoftwareConsortium/ITK/blob/main/Wrapping/Generators/Python/itk/support/extras.py#L266-L295

?

N-Dekker · 2026-08-13T20:16:36Z

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

ITK/Wrapping/Generators/Python/itk/support/extras.py

Line 286 in d56ecc0

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 · 2026-08-14T18:03:02Z

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 · 2026-08-15T09:13:56Z

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.

blowekamp · 2026-08-18T12:02:20Z

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.

N-Dekker · 2026-08-18T12:11:04Z

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 · 2026-08-18T12:38:53Z

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

@N-Dekker nice! LGTM! 🥇

N-Dekker · 2026-08-19T12:16:44Z

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... 😃

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"

Made the mapping from NumPy to ITK types clearer, by using the itkCType aliases with the specified number of bits (`itk.uint8_t`, `itk.uint16_t`, etc.), which were introduced by pull request InsightSoftwareConsortium#6762 commit dc0ea28

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 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

dzenanz approved these changes Aug 13, 2026

View reviewed changes

N-Dekker marked this pull request as ready for review August 13, 2026 08:19

blowekamp reviewed Aug 13, 2026

View reviewed changes

Comment thread Wrapping/Generators/Python/itk/support/types.py Outdated

N-Dekker marked this pull request as draft August 13, 2026 14:39

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 marked this pull request as ready for review August 13, 2026 15:57

dzenanz approved these changes Aug 13, 2026

View reviewed changes

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 force-pushed the ctype-aliases-for-numeric-types-of-specific-sizes branch from 1d06a17 to dc0ea28 Compare August 15, 2026 21:29

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

blowekamp approved these changes Aug 18, 2026

View reviewed changes

thewtex approved these changes Aug 18, 2026

View reviewed changes

dzenanz merged commit f1daa03 into InsightSoftwareConsortium:main Aug 19, 2026
19 checks passed

N-Dekker mentioned this pull request Aug 19, 2026

STYLE: Use itk.int64_t and itk.uint64_t instead of if os.name == "nt" #6767

Merged

N-Dekker mentioned this pull request Aug 21, 2026

STYLE: Let _get_itk_pixelid use itkCType aliases with specified sizes #6775

Merged

N-Dekker mentioned this pull request Aug 24, 2026

On Linux, GetCTypeForDType(np.uint64) should return UL, and GetCTypeForDType(np.int64) should return SL #6785

Closed

Navigation Menu

Uh oh!

Uh oh!

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

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

N-Dekker commented Aug 12, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot commented Aug 13, 2026 •

edited

Loading

Greptile Summary

Confidence Score: 5/5

T-Rex Logs

Uh oh!

Uh oh!

thewtex commented Aug 13, 2026

Uh oh!

N-Dekker commented Aug 13, 2026 •

edited

Loading

Uh oh!

thewtex commented Aug 14, 2026 •

edited

Loading

Uh oh!

N-Dekker commented Aug 15, 2026

Uh oh!

blowekamp commented Aug 18, 2026

Uh oh!

N-Dekker commented Aug 18, 2026

Uh oh!

N-Dekker commented Aug 18, 2026 •

edited

Loading

Uh oh!

thewtex left a comment

Uh oh!

N-Dekker commented Aug 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

N-Dekker commented Aug 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

greptile-apps Bot commented Aug 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 5/5

T-Rex Logs

Uh oh!

Uh oh!

thewtex commented Aug 13, 2026

Uh oh!

N-Dekker commented Aug 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thewtex commented Aug 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

N-Dekker commented Aug 15, 2026

Uh oh!

blowekamp commented Aug 18, 2026

Uh oh!

N-Dekker commented Aug 18, 2026

Uh oh!

N-Dekker commented Aug 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thewtex left a comment

Choose a reason for hiding this comment

Uh oh!

N-Dekker commented Aug 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

N-Dekker commented Aug 12, 2026 •

edited

Loading

greptile-apps Bot commented Aug 13, 2026 •

edited

Loading

N-Dekker commented Aug 13, 2026 •

edited

Loading

thewtex commented Aug 14, 2026 •

edited

Loading

N-Dekker commented Aug 18, 2026 •

edited

Loading