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

[N-Dekker]

Added the following aliases:

float32_ctype
float64_ctype
uint8_ctype
uint16_ctype
uint32_ctype
uint64_ctype
int8_ctype
int16_ctype
int32_ctype
int64_ctype

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_ctype, 2] (equivalent to itk.Image[itk.UC, 2])
• itk.Image[itk.float64_ctype, 2] (equivalent to itk.Image[itk.D, 2])

[greptile-apps]

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}

[blowekamp]

In common on unix and Mac to just use long for 64-bits. Does ITK Python instantiate long long type for all platforms? These int64 alias may need to be conditional.

[N-Dekker]

Good point @blowekamp Converted PR back to Draft, to allow us some more time...

[N-Dekker]

I just noticed that the following assert fails on GCC:

#include <type_traits> 
#include <cinttypes>
static_assert(std::is_same_v<long long, std::int64_t>);

Output at https://godbolt.org/z/hzE46MnxY :

<source>:7:20: error: static assertion failed
    7 | static_assert(std::is_same_v<long long, std::int64_t>);
      |               ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  • 'long long int' is not the same as 'long int'

The assert passes successfully (no assert failure) on MSVC. So it does support the idea of making the int64 alias conditional.

Honestly I like the simplicity of unconditional uint64_ctype = ULL and int64_ctype = SLL. But I see that there is a choice to make. 🤷

[N-Dekker]

@blowekamp Please check if you like this force-pushed amend.

[thewtex]

How about using uint8, etc per:

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

?

[N-Dekker]

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]

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!