[vtk-developers] vtkImageData, C versus Fortran ordering

Andras Lasso lasso at queensu.ca
Thu Jul 20 23:49:51 EDT 2017


> My approach with this kind of change has been to create a new subclass of vtkDataSet. If you add some meta-data to vtkImageData that is then ignored by all or most of algorithms, you will end up with confused users.

We’ve been working on this for several years, as a background task. Adding support in VTK for reading, processing, and displaying arbitrarily oriented images would simplify many VTK-based medical image computing applications. Some information about this effort is available here:

https://docs.google.com/document/d/e/2PACX-1vQiHT2IpeCtfpphJ9vFtq_dQ3dJHsayZTcvJZUMWM9lhJdItd1qQed0449pOpYIfE3Bqgd2uZaXN4iR/pub

I know that it is a sensitive topic and a large number of files are involved (around 400 core classes + test/examples), but in many cases the changes are trivial (changing a few lines in a class to indicate that it can accept oriented image) and it is not necessary to update all classes at once, but gradually, as the need emerges.

I would love to hear from anyone who would be interested in having orientation support, have any comments or suggestions, or might be willing to contribute.

Andras


From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci
Sent: Thursday, July 20, 2017 12:57 PM
To: Marcus D. Hanwell <marcus.hanwell at kitware.com>
Cc: VTK Developers <vtk-developers at vtk.org>; David Gobbi <david.gobbi at gmail.com>
Subject: Re: [vtk-developers] vtkImageData, C versus Fortran ordering

My approach with this kind of change has been to create a new subclass of vtkDataSet. If you add some meta-data to vtkImageData that is then ignored by all or most of algorithms, you will end up with confused users. You could potentially do something at the executive layer that can automatically transform this new dataset to vtkImageData when using vtkImageData algorithms. It should be trivial to add support to the volume rendering code after that.

Given that we are looking at VTK-m for much of the future algorithm, I would suggest that VTK-m natively supports both ordering. Then if we replace any VTK algorithms with VTK-m implementations, it would work out of box.

On Wed, Jul 19, 2017 at 1:34 PM, Marcus D. Hanwell <marcus.hanwell at kitware.com<mailto:marcus.hanwell at kitware.com>> wrote:
On Wed, Jul 19, 2017 at 1:11 PM, David Gobbi <david.gobbi at gmail.com<mailto:david.gobbi at gmail.com>> wrote:
On Wed, Jul 19, 2017 at 10:55 AM, Marcus D. Hanwell <marcus.hanwell at kitware.com<mailto:marcus.hanwell at kitware.com>> wrote:
On Wed, Jul 19, 2017 at 12:35 PM, David Thompson <david.thompson at kitware.com<mailto: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.

Totally, I knew about that, but VTK wouldn't particularly use that information in rendering, but we could then use it at an application level. Thanks for the pointers on how you are using it.

_______________________________________________
Powered by www.kitware.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com&data=02%7C01%7Classo%40queensu.ca%7Cfa78c43ac53c4f900a3608d4cf906adf%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636361666553212166&sdata=IDDPUhdQtFMHPxjPwjPV%2BBBjcO5hdM73DxXuD6VztO0%3D&reserved=0>

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7Cfa78c43ac53c4f900a3608d4cf906adf%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636361666553212166&sdata=JDzZfoOH86zfXMnaUqi4Tz6hV8XqP2T459a%2F0EnQCkc%3D&reserved=0>

Search the list archives at: http://markmail.org/search/?q=vtk-developers<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7Cfa78c43ac53c4f900a3608d4cf906adf%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636361666553212166&sdata=Y8NLZhdLnccyK4Dhm743xWgDuHz51yHgiyKf4WQFsR8%3D&reserved=0>

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7Cfa78c43ac53c4f900a3608d4cf906adf%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636361666553212166&sdata=PYDIvDv4Kpc5fFCXI4xRpsWwzlWHZUbd%2BSoc5ZYV1o8%3D&reserved=0>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170721/89e7d893/attachment-0001.html>


More information about the vtk-developers mailing list