[SID-6921]

image_from_vtk_image only trimmed a trailing size-1 VTK z dimension for vector-pixel images, so round-tripping a 2D scalar image through the VTK bridge produced a 3D image. Apply the same trim for scalar pixels.

AI assistance

• Tool: Claude Code (claude-sonnet-5)
• Role: located the bug by comparing the scalar and vector branches of image_from_vtk_image in Wrapping/Generators/Python/itk/support/extras.py; drafted the fix and the added round-trip test
• Contribution: the vector branch already trimmed a trailing size-1 z dimension (VTK images are always stored with 3 dims) before calling image_view_from_array, but the scalar branch had no equivalent check, so 2D scalar images silently grew a spurious 3rd dimension on the VTK round trip
• All code was reviewed locally before committing; no build environment was available to execute the test, so CI must confirm it

[dzenanz]

Test looks good. Does looking at git history reveal why was is_vector in the if condition? Oversight, or some special handling of color or some other non-spatial dimension?

[SID-6921]

Checked history. Both functions were added together in f13e760 (2020-04-29, "Add itk.vtk_image_from_image and itk.image_from_vtk_image"), and the is_vector check goes back to that same commit, unchanged since.

The original code was actually two separate branches, not one shared trim:

if is_vector and dims[-1] == 1:
    dims = dims[:2]
    dims.reverse()
    dims.append(point_data.GetScalars().GetNumberOfComponents())
else:
    dims.reverse()

The vector branch needs is_vector specifically because it has to append the component count as its own trailing axis, which only makes sense for a vector image. The else branch just reverses all 3 dims unconditionally, including the padded 1, so a 2D scalar image always kept its spurious third axis.

The PR's own test suite only ever covered a 3D scalar round trip and a 3D vector round trip, never 2D of either kind, so this never got exercised. Nothing in the commit message, code, or tests points to intentional handling of color or some other non-spatial dimension for the scalar case. Looks like a plain oversight to me, not a deliberate choice.

[dzenanz]

LGTM. It would be good if Matt reviewed, too.