[vtk-developers] vtkImageData, C versus Fortran ordering

Andy Bauer andy.bauer at kitware.com
Wed Jul 19 13:28:19 EDT 2017


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.

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?

On Wed, Jul 19, 2017 at 1:11 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> On Wed, Jul 19, 2017 at 10:55 AM, Marcus D. Hanwell <
> marcus.hanwell at kitware.com> wrote:
>
>> On Wed, Jul 19, 2017 at 12:35 PM, David Thompson <
>> david.thompson at kitware.com> wrote:
>>
>>> Hi Marcus,
>>>
>>> > We work on Tomviz, and one of its primary goals is to work with
>>> volumes in an intuitive way making heavy use of the volume rendering code.
>>> It also needs to interact with several libraries that operate on volumes,
>>> ideally using our Python NumPy integration and zero copy approaches to
>>> process data in place.
>>> >
>>> > One of the challenges has been preserving the Fortran ordering of the
>>> single component scalar data. We will also be adding support for
>>> multi-component data soon. What are people's thoughts on potentially adding
>>> some API to vtkImageData to mark it as C ordered?
>>> >
>>> > That would largely just geometrically transform how the volume is
>>> rendered, but ensure a contour is correctly extracted and aligned. It would
>>> then let us use the default C ordering, simplifying our application code,
>>> and the current order could remain the default. I would suggest considering
>>> the same for the vtk.js work too.
>>> >
>>> > It is feasible to make these changes in the application logic too, but
>>> this feels like a fairly common problem that others would also hit from
>>> time to time. Maybe I am missing more corner cases, so I am posting this in
>>> hopes of feedback before writing any code (or asking someone else to).
>>>
>>> I think a common problem would be that many image filters choose a
>>> particular order to process data because access is much faster in one plane
>>> than others. Are you thinking that those filters would also adjust their
>>> algorithms/traverse order to accommodate FORTRAN ordering when it is
>>> present on the input (and presumably output)?
>>
>>
>> My ideal scenario is to mark a vtkImageData as C ordered (default it to
>> Fortran/what it is now). It may be easier to manage more of that at an
>> application level though too, I was more thinking out loud and wondering if
>> other people had explored this or solved it in other ways. I get the
>> historical perspective, and possibly that what I want may not be needed by
>> the wider VTK community.
>>
>> I would like to leave as much of VTK alone as possible, and so let most
>> VTK stuff continue as it always has, but be able to pass a vtkImageData to
>> a 3D NumPy array as C ordered, operate on it, and then render the result.
>> We currently go to great pains to ensure if comes back as Fortran ordered,
>> and there is no way to set a default. I also find that most stuff assumes
>> the C ordering, so it can require some reshuffling of the data which can
>> involve large volumes.
>>
>
> It's already possible to add extra flags to any VTK data set, without
> making any changes to VTK itself.
>
> The simplest way is to add an array to the vtkFieldData of the data set.
> You could add a field data array called "ImageOrdering" that would hold the
> flag.
>
> Another way (a little trickier) is to add your own information key.  For
> example, for my VTK DICOM pipelines I've defined a key
> called PATIENT_MATRIX that stores a 4x4 matrix to define the image
> orientation.
>
>  - David
>
>
>
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170719/59df8a2f/attachment-0001.html>


More information about the vtk-developers mailing list