[vtk-developers] vtkImageData, C versus Fortran ordering

[Marcus D. Hanwell]

On Thu, Jul 20, 2017 at 1:05 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>
> Hi,
>
> On Wed, Jul 19, 2017 at 6:38 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
> > On Wed, Jul 19, 2017 at 1:28 PM, Andy Bauer <andy.bauer at kitware.com> wrote:
> >>
> >> Couldn't you do things in the same way that the VTK SOA zero-copy array
> >> was done? That way it's transparent to whatever is using the data array how
> >> the memory is stored.
> >
> >
> > That felt like it would be way more invasive, and possibly not worth it. We
> > can just keep doing what we are doing too.
> >>
> >>
> >> Also, on a side note I'm not a big fan of calling these C vs. Fortran
> >> ordering as it's more how we traverse the data most efficiently. It looks
> >> like your most efficient way would be to go through Z fastest, then Y and
> >> finally X (opposite for current vtkImageData arrays). How about something
> >> like ZYX vs. XYZ ordering for identifying the difference?
> >
> >
> > It is a commonly used term, and works well when searching. It is the
> > terminology used by the Python community, Eigen, VisIt even, and so I would
> > say it is reasonable. I am mainly looking at a mismatch between different
> > toolkits, but I would say using the same terminology as most other
> > communities seems reasonable.
>
> Point taken, although we had a big-ish argument over on the Numpy
> mailing list about the kinds of confusion that can arise in conflating
> the memory layout with the index ordering - thread starting at:
>
> https://mail.python.org/pipermail/numpy-discussion/2013-March/065949.html
>
That is quite a thread! I wasn't trying to oversimplify, but didn't
really want to get into a terminology debate. Like it or not many
toolkits use this terminology, I first encountered it in Eigen, I am
totally open to additional descriptions too. If others make sense
people should use them, but please map them to this terminology. I
don't want to relearn it, and the NumPy docs on this subject have
confused me several times in the past!

These are big volumes in many cases, so I am eager to avoid copies of
the mismatched orders whatever we call them. The bridges to NumPy,
ITK, and potentially other toolkits would be smoother if we could
present a C ordered array to them as most default to that ordering
anyway. I found the idea of a geometric transformation appealing, but
raised it here in case there were better approaches.