MantisBT - ITK
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006038ITKpublic2007-11-10 11:452010-11-07 01:19
ReporterRupert Brooks 
Assigned ToLuis Ibanez 
PrioritynormalSeveritymajorReproducibilityalways
StatusassignedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Resolution Date
Sprint
Sprint Status
Summary0006038: ITKMINC2IO requires fixes to read certain files.
DescriptionThe ITKMINC2IO classes, currently in the review directory, need fixes before they can be integrated with the main distribution. They have difficulty importing data that is not in particular orientations. Tests were developed by Andrew Janke to test all possible orientations. I would also recommend that the cases of ranged MINC data (where the range 0-1024 is mapped to 8 bits, for example) be thorougly tested.
Steps To Reproduce
Additional InformationI'm attaching a zip of what im currently using for testing, etc. This
should build and run against the ITK 3.4 release (with Review code on)
- i.e. using the itkMINC2IO that is currently in Insight/Code/Review.
It fails the majority of these tests for me on both
WinXP/VC++ 2003 and Ubuntu/Gcc4.0.3.

I am nearly 100% certain that these problems are due to problems in
the itkMINCImageIO class. All these files cause no problems
whatsoever for the minc tools. I think that when the data is not
stored in a "standard" ordering, this is not accounted for and the
data is read in scrambled. In certain cases, it seems to try to read
beyond the end of the file.

The file "this breaks reader" causes so many problems when read that it actually locked up CTest. (This file is experimental data, please only use this file for testing purposes and do not distribute)
TagsNo tags attached.
Relationships
Attached Fileszip testmincio.zip (46,496) 2007-11-10 11:45
https://public.kitware.com/Bug/file/1220/testmincio.zip
gz testmincio-smr.tar.gz (3,802) 2009-01-07 01:30
https://public.kitware.com/Bug/file/1978/testmincio-smr.tar.gz
Issue History
Date ModifiedUsernameFieldChange
2007-11-10 11:45Rupert BrooksNew Issue
2007-11-10 11:45Rupert BrooksFile Added: testmincio.zip
2007-11-10 11:57Rupert BrooksNote Added: 0009662
2008-01-23 10:44Luis IbanezStatusnew => assigned
2008-01-23 10:44Luis IbanezAssigned To => Andinet
2008-02-16 13:30Rupert BrooksNote Added: 0010527
2009-01-07 01:29Steve RobbinsNote Added: 0014471
2009-01-07 01:30Steve RobbinsFile Added: testmincio-smr.tar.gz
2009-01-09 03:51Luis IbanezAssigned ToAndinet => Luis Ibanez
2009-01-09 03:53Luis IbanezNote Added: 0014494
2009-01-14 01:40Steve RobbinsNote Added: 0014550
2009-01-14 01:46Steve RobbinsNote Added: 0014551
2010-11-07 01:14Luis IbanezNote Added: 0022973
2010-11-07 01:19Steve RobbinsNote Added: 0022986

Notes
(0009662)
Rupert Brooks   
2007-11-10 11:57   
The thisbreaksreader.mnc file is not experimental data - it is intentionally a file of all zeros. It is the structure of this file that somehow breaks the reader. The data contents are meaningless.

Sorry for any confusion this may have caused. Not enough coffee for me apparently.

-rb
(0010527)
Rupert Brooks   
2008-02-16 13:30   
I have noticed another strange property of this class. I am not sure whether this is a bug, or a feature. The class will reorder the dimensions of the incoming file so that the axis that varies the most in Z, is the third axis, the one that varies the most in Y is the second and so forth.

I found this a very unnatural behavior - i have a number of ultrasound slices to import, at varying locations in space. Some come in with dimensions 1x240x320, some come in as 240x320x1, some come in as 320x240x1. They are all ordered identically in the incoming file.

This is a designed behavior, not an accident. It is explicitly done in the function
void MINC2ImageIO::XYZFromDirectionCosines(midimhandle_t *hdims, int *dim_indices, int *numberOfComponents)
in itkMINC2ImageIO.cxx

I think a more logical behavior would be to either read them in in the order they are in the MINC file, or to assign zspace, yspace, xspace in minc to Z,Y,X in ITK.
(0014471)
Steve Robbins   
2009-01-07 01:29   
Over the recent holiday, I wrote more test cases and tried modifying MINC2ImageIO to get them passing. Along the way I discovered that it fails completely for 2D images and that Read() doesn't pay attention to the ImageIORegion as it should.

I'm attaching the test cases (written using Googletest) even though they are a long way from complete, in the hope that someone else will help complete them.

Using these tests I started a rewrite of MINC2ImageIO, which also remains unfinished (but does past the test suite so far). Write me if you want the code.
(0014494)
Luis Ibanez   
2009-01-09 03:53   
We are reviewing the support for Streaming in the ImageFileWriter, and along with it, the behavior expected for the ImageIORegion. We will like to see your modifications to the MINC2ImageIO.
(0014550)
Steve Robbins   
2009-01-14 01:40   
Luis: I put my tests and code into a GIT repository; you can retrieve it using "git clone git://github.com/smr99/itk-mincimageio.git" [^]
(0014551)
Steve Robbins   
2009-01-14 01:46   
Further to the git repository: you can also obtain the fails in tar or zip format using the "Download" button on this page: http://github.com/smr99/itk-mincimageio/tree/master [^]
(0022973)
Luis Ibanez   
2010-11-07 01:14   
Steve,
Is this still an issue ?

Should we use the MINC2ImageIO from your Git repository in order to update the class in ITKv4 ?
(0022986)
Steve Robbins   
2010-11-07 01:19   
Luis,

I have not touched this since January, 2009. I assume what I wrote then still holds. I think the unit tests improved coverage, but my fixes were just the beginning. This class needs a whole lot of attention before I'd trust it with my data.