# SimpleITK 3.0.0 Alpha 3

**URL:** <https://discourse.itk.org/t/simpleitk-3-0-0-alpha-3/7733>\
**Category:** Announcements\
**Tags:** csharp, r, java, simpleitk, python\
**Created:** [March 18, 2026, 2:16pm UTC](https://discourse.itk.org/t/simpleitk-3-0-0-alpha-3/7733 "2026-03-18T14:16:23Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [March 18, 2026, 2:16pm UTC](https://discourse.itk.org/t/simpleitk-3-0-0-alpha-3/7733/1 "2026-03-18T14:16:24Z")

</div>

# Release Notes for SimpleITK v3.0.0 Alpha Release 3

This is the third Alpha Release of SimpleITK 3.0. It covers changes since v3.0.0a1 (September 2025), including v3.0.0a2.

Significant work has been done on the Python packaging and build system, with a migration to `scikit-build-core`. The Python `Image` class now supports the buffer protocol and array interface for zero-copy interoperability with NumPy and other array libraries.

## Breaking Changes

- `SobelEdgeDetectionImageFilter`: The default 3D Sobel operator coefficients have changed to be consistent with the 2D operator (via ITK). A `UseLegacyOperatorCoefficients` option has been added to restore the previous behavior.
- Removed the private `_GetMemoryViewFromImage` function from Python. It is replaced by the `Image` class’s ` __array_interface__ ` and buffer protocol (` __buffer__ `) support (see New Features).
- Dropped Python 3.9 from packaged wheels. Minimum supported Python version is now 3.10.
- Minimum CMake version increased from 3.16.3 to 3.23.0.

## New Features

- Added Python buffer protocol (PEP 688) and ` __array_interface__ ` support to the `Image` class. Images can be used directly as read-only NumPy arrays without copying data, and the `ImageBuffer` CPython class maintains proper memory lifetime.
- Added `pixel_types` module to Python with utility functions for determining pixel type categories.
- Introduced wrapping for `ContourExtractor2DImageFilter`. Contour results are accessible via parameterized active measurement methods.
- Added `ContainerManageMemory` method to internal `PimpleImage` for controlling `ImportImageContainer` memory ownership.
- Added experimental support for building ITK via CMake `FetchContent` as an alternative to the SuperBuild `ExternalProject`.
- Added `manylinux_2_28` Linux wheel packages.
- Python packaging switched from `setuptools`/`setup.py` to `scikit-build-core` with `pyproject.toml`. A top-level `pyproject.toml` now enables building and installing SimpleITK as a Python package directly from the source repository, eliminating the need for the separate [`SimpleITKPythonPackage`](https://github.com/SimpleITK/SimpleITKPythonPackage) project. SimpleITK can now be installed directly with:

```bash
pip install . # from a local clone
pip install git+https://github.com/SimpleITK/SimpleITK.git@v3.0.0a3 # from git

```

The build automatically fetches ITK via `FetchContent` and compiles both ITK and SimpleITK. Build dependencies (`swig`, `jinja2`, `pyyaml`, etc.) are declared in `pyproject.toml` and installed automatically by `pip`.

## Build System Changes

- Migrated Python wheel building to [`scikit-build-core`](https://scikit-build-core.readthedocs.io/) with a top-level `pyproject.toml`, replacing the legacy `setuptools`/`setup.py` approach.
- SWIG 4.3.0 is now the minimum required version.
- Google Test is now fetched via CMake `FetchContent` instead of being built as a SuperBuild external project.
- Migrated to CMake `FILE_SET` for header management (requires CMake 3.23+).
- Modernized CMake usage: target-based ITK linking, modern `foreach(IN LISTS)`, `CMAKE_LINKER_TYPE` for gold linker, and simplified export configuration.
- Removed support for older MSVC compiler versions.
- Added YAML C-based loader support (`pyyaml`) for improved code generation performance.

## Updates

- Updated ITK to development version 6.0b2+ (commit c79274e4, main as of 2026-03-09).
- Upgraded SuperBuild `uv` installer with isolated install support and PowerShell compatibility.
- Corrected Lua wrapping template issues and enabled Lua in CI batch builds.

## Bug Fixes

- Fixed `Show` function creating temporary files with `%` characters, which caused failures on some platforms.
- Fixed Python module file extension on Windows.
- Fixed macOS deployment target configuration for Python distributions.

Additional details and packages can be found on Github:

> **[Release Release v3.0.0a3 · SimpleITK/SimpleITK](https://github.com/SimpleITK/SimpleITK/releases/tag/v3.0.0a3)**
>
> This is an automatic packaging of SimpleITK based on the v3.0.0a3 tag.
> To upgrade to this Python binary package run:
> pip install --upgrade --pre simpleitk --find-links https://github.com/SimpleITK/...

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [March 18, 2026, 3:07pm UTC](https://discourse.itk.org/t/simpleitk-3-0-0-alpha-3/7733/2 "2026-03-18T15:07:21Z")

</div>

Is `GetITKBase()` still the way to get ITK image from SimpleITK image? How hard would it be to make `.GetITKImage()` method, which would return an image of proper type (instead of `DataObject`)? I am interested in this via Python wrapping.

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [March 18, 2026, 3:12pm UTC](https://discourse.itk.org/t/simpleitk-3-0-0-alpha-3/7733/3 "2026-03-18T15:12:01Z")

</div>

The `itk::DataObject * Image::GetITKBase()` method is a C++ method that is wrapped in any language. This method was not modified in this release.

If you’d like to make a feature request, please create an issue on GitHub and we can discuss further there.

---

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [March 18, 2026, 4:55pm UTC](https://discourse.itk.org/t/simpleitk-3-0-0-alpha-3/7733/4 "2026-03-18T16:55:10Z")

</div>

> [@blowekamp](#):
>
> `SobelEdgeDetectionImageFilter`: The default 3D Sobel operator coefficients have changed to be consistent with the 2D operator (via ITK). A `UseLegacyOperatorCoefficients` option has been added to restore the previous behavior.

For your information, at the moment, ITK (v6.0b02) only uses the new, more consistent coefficients for 3D Sobel when you explicitly _disable_ `UseLegacyOperatorCoefficients`. Or when you enable `ITK_FUTURE_LEGACY_REMOVE`.

By default, you still get the old default! 🙃

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [March 18, 2026, 8:22pm UTC](https://discourse.itk.org/t/simpleitk-3-0-0-alpha-3/7733/5 "2026-03-18T20:22:57Z")

</div>

The release notes are correct for SimpleITK, in that it defaults to the new behavior. I believe that there was a discussion some place about why the legacy behavior was wrong it would probably be good to include that in the notes. So you know where the discussion occoured? Is this it: [Sobel operator extended for 4D, legacy support for 3D, OK?](https://discourse.itk.org/t/sobel-operator-extended-for-4d-legacy-support-for-3d-ok/7699)

> [@Niels\_Dekker](#):
>
> For your information, at the moment, ITK (v6.0b02) only uses the new, more consistent coefficients for 3D Sobel when you explicitly _disable_ `UseLegacyOperatorCoefficients`. Or when you enable `ITK_FUTURE_LEGACY_REMOVE`.

SimpleITK has the defaults explicitly specified as UseLegacyOperatorCoefficients=OFF.

---

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [March 19, 2026, 10:10am UTC](https://discourse.itk.org/t/simpleitk-3-0-0-alpha-3/7733/6 "2026-03-19T10:10:54Z")

</div>

Thanks for embracing the new Sobel coefficients for 3D, @blowekamp 😄

> [@blowekamp](#):
>
> I believe that there was a discussion some place about why the legacy behavior was wrong it would probably be good to include that in the notes. So you know where the discussion occoured? Is this it: [Sobel operator extended for 4D, legacy support for 3D, OK?](https://discourse.itk.org/t/sobel-operator-extended-for-4d-legacy-support-for-3d-ok/7699)

Yes indeed! I added the following motivation at [https://github.com/InsightSoftwareConsortium/ITK/pull/5718](https://github.com/InsightSoftwareConsortium/ITK/pull/5718) :

_The new coefficients are more commonly used by other toolkits, including SciPy’s `scipy.ndimage.sobel`, and correspond with [https://en.wikipedia.org/wiki/Sobel\_operator](https://en.wikipedia.org/wiki/Sobel_operator)_

Technically, the new coefficients for 3D are computed by the very same algorithm as the coefficients for 2D, 4D, …, and ND. So in that way, they are consistent with the other supported dimensionalities.