BUG: PyBuffer _GetImageViewFromArray should reject non-contiguous buffer

[N-Dekker]

The C++ function PyBuffer::_GetImageViewFromArray cannot support a non-contiguous Python buffer as input, because the buffer is imported into an itk::Image, via itk::ImportImageContainer::SetImportPointer.

Note that the Python function GetImageViewFromArray (from Modules/Bridge/NumPy/wrapping/PyBuffer.i.in) does support a non-contiguous NumPy array as input, by calling numpy.ascontiguousarray:

https://github.com/InsightSoftwareConsortium/ITK/blob/d36dfc65c7c3734872dc1bfedf16ce388e4ef33c/Modules/Bridge/NumPy/wrapping/PyBuffer.i.in#L90-L91

[blowekamp]

Tangentially related to this code, I have encounter big endian numpy arrays coming from reading OME-ZARR imaging files. How does this code work with non-native byte orders?

[dzenanz]

Presumably, byte order should be taken care of when reading/writing from disk, so there should be no issues with it once in memory.

[blowekamp]

Presumably, byte order should be taken care of when reading/writing from disk, so there should be no issues with it once in memory.

It is reasonable to think that, but numpy does have representation to support non-native byte orders: https://numpy.org/doc/stable/reference/generated/numpy.dtype.byteorder.html

And this have been encountered in the real world reading OME ZARR files generated by popular java libraries.

[thewtex]

And this have been encountered in the real world reading OME ZARR files generated by popular java libraries.

@blowekamp Are there public samples of these we could use in tests?

[blowekamp]

And this have been encountered in the real world reading OME ZARR files generated by popular java libraries.

@blowekamp Are there public samples of these we could use in tests?

The raw2ometiff or the GUI NGFF-Converter tools produces big endian of data type more that 2 bytes.