[Insight-developers] Analyze IO
Bill Lorensen
bill.lorensen at gmail.com
Sun Feb 25 08:38:14 EST 2007
I would prefer to see a rather long, obnoxious warning that explicitly
explains the problem and how to fix it. We know from our VTK experience how
frustrated our users got when VTK changed something because it was "the
right thing to do".
I vote for a warning and not an excpetion.
Bill
On 2/25/07, Stephen R. Aylward <Stephen.Aylward at kitware.com> wrote:
>
>
> Well - I don't think you can set the cosines to all zeros. The
> GetInverse will fail in the setdirection command, etc.
>
> Shouldn't it throw an exception or warning or not set the direction
> cosines?
>
> s
>
>
>
> Hans J. Johnson wrote:
> > Stephan,
> >
> > I agree. The reader should set the orientation to unknown when it is
> not
> > specified as one of the known values.
> >
> > This would mean that the direction cosines should probably be set to:
> > 0 0 0
> > 0 0 0
> > 0 0 0
> >
> > For the image returned.
> >
> > Hans
> >
> >
> >
> > On 2/24/07 3:12 PM, "Stephen R. Aylward" <Stephen.Aylward at Kitware.com>
> > wrote:
> >
> >> This can be argued many different ways. Seems like analyze is now
> >> making use-case assumptions for its users, when it did not before.
> >> That's up to the analyze guys.
> >>
> >> For such things, we need to report to the community when backward
> >> compatibility is lost. We need to keep track of such things in the
> >> release notes and wiki so that it doesn't look like ITK isn't following
> >> its backward compatibility policy.
> >>
> >> Also - for the Analyze guys...it seems like analyze reader also needs
> to
> >> be updated. Right now it picks a default orientation if one isn't
> >> specified - and it does not throw an exception or warning. It should
> >> probably at least throw a warning - it will help others know when
> >> orientation guesses are being made...or perhaps it should set the
> >> orientation to unknown instead of supplying a guessed orientation.
> >>
> >> Stephen
> >>
> >> Jim Miller wrote:
> >>> Stephen,
> >>>
> >>> For your particular case, can you assign an (arbitrary) orientation to
> >>> your microscopy images to satisfy the Analyze writer? For instance,
> >>> your microscopy images could default to "axials".
> >>>
> >>> I think Hans is on the right track here. The Analyze format was meant
> >>> for medical images and Analyze the application is very careful about
> the
> >>> orientation of imagery. Unfortunately, there are a lot of
> applications
> >>> that claim to support the Analyze file format but end up screwing up
> the
> >>> orientations, making the files produced "unusable" for other
> >>> applications. This in turn gives the Analyze format a bad name, one
> that
> >>> it does not deserve. Where possible, we should try to do the right
> >>> thing so that ITK does not become one of the tools producing bad
> Analyze
> >>> files.
> >>>
> >>> Coincidently, we hit upon this same "bug" this week. Recompiled some
> >>> code that was sitting on shelf for a few months and it no longer ran.
> >>> At first, we were rather upset. But in our case, a fix to our
> program's
> >>> use of the ResampleImageFilter (we were actually using it incorrectly)
> >>> worked around the change in the AnalyzeImageIO and made our code more
> >>> correct.
> >>>
> >>> Jim
> >>>
> >>>
> >>>
> >>> On 2/24/07, *Stephen R. Aylward* <Stephen.Aylward at kitware.com
> >>> <mailto:Stephen.Aylward at kitware.com>> wrote:
> >>>
> >>> Hi Hans,
> >>>
> >>> According to the ITK survey, 45% of ITK users are using ITK
> outside of
> >>> the medical field.
> >>>
> http://www.itk.org/Wiki/2006_Survey_Summary#Areas_of_Use_of_the_Toolkit
> >>> <
> http://www.itk.org/Wiki/2006_Survey_Summary#Areas_of_Use_of_the_Toolkit>
> >>>
> >>> If ITK only did anatomic images, I'd probably agree that an
> undefined
> >>> image orientation is not needed - but the solution to the lack of
> an
> >>> orientation should probably be fixed in the readers and image
> sources
> >>> and not in the writers.
> >>>
> >>> For me, the problem came about because of microscopy work that I
> began
> >>> at UNC. They asked for some changes, I did them, recompiled using
> the
> >>> latest ITK, and now the programs no longer work for them. They
> can no
> >>> longer create analyze formatted images which are required by
> another
> >>> program in their pipeline.
> >>>
> >>> The changes to itkAnalyze mean that we can no longer use analyze
> for
> >>> microscopy images, for data from any other domain for which image
> >>> orientation is (and should be) undefined, for images that
> originated as
> >>> stacks of jpegs, etc in which orientation is undefined, for
> >>> phantom/simulated data studies, etc.
> >>>
> >>> Stephen
> >>>
> >>> Hans J. Johnson wrote:
> >>>> Stephan,
> >>>>
> >>>> The problem with this is that it introduces the very real
> >>> possiblility of
> >>>> getting right/left swaps in your images. The ITK implementation
> >>> was written
> >>>> to meet the file format definition as specified by the original
> >>> developers
> >>>> (i.e. Mayo clinic as part of the Analyze program). The bug
> >>> fixes occurred
> >>>> close to the time when the switch from metadata orientation to
> >>> direction
> >>>> cosines was done. This is mostly because that is when the bug was
> >>>> discovered, isolated, and a fix was made. The original buggy
> >>> meta-data code
> >>>> was written prior to images having a well defined definition
> >>> concept of
> >>>> orientation, and during the implementation of the orientation
> >>> code (via
> >>>> direction cosines) this definition became clear and well defined
> >>> across all
> >>>> file format readers.
> >>>>
> >>>> The behavior did change, but it was a bug fix.
> >>>>
> >>>> I have very strong feelings on this because analyze files that
> >>> are written
> >>>> to disk with ambiguity have cost me weeks of time tracking down
> >>> problems.
> >>>> Because of this dangerous situation, I believe quite strongly
> >>> that any file
> >>>> format that claims to respect orientation should do so
> >>> consistently across
> >>>> all file formats.
> >>>>
> >>>> You proposal below would map the following 3 direction cosign
> >>> inputs to the
> >>>> analyze file filter correctly:
> >>>>
> >>>> itk::SpatialOrientationAdapter<3>::DirectionType SAGdir=
> >>>>
> >>>
> >>>
> SpatialOrientationAdapter<3>().ToDirectionCosines(itk::SpatialOrientation::I
> >>>> TK_COORDINATE_ORIENTATION_PIR);
> >>>> SAGITTAL 133124
> >>>> 0 0 1
> >>>> -1 0 0
> >>>> 0 1 0
> >>>>
> >>>> itk::SpatialOrientationAdapter<3>::DirectionType CORdir=
> >>>>
> >>>
> >>>
> itk::SpatialOrientationAdapter<3>().ToDirectionCosines(itk::SpatialOrientati
> >>>> on::ITK_COORDINATE_ORIENTATION_RIP);
> >>>> CORONAL 264194
> >>>> 1 0 0
> >>>> 0 0 -1
> >>>> 0 1 0
> >>>>
> >>>> itk::SpatialOrientationAdapter<3>::DirectionType AXIdir=
> >>>>
> >>>
> >>>
> SpatialOrientationAdapter<3>().ToDirectionCosines(itk::SpatialOrientation::I
> >>>> TK_COORDINATE_ORIENTATION_RPI);
> >>>> AXIAL 525314
> >>>> 1 0 0
> >>>> 0 -1 0
> >>>> 0 0 1
> >>>>
> >>>> ===============================
> >>>> But the other 45 possible orientations of a 3D dataset would also
> >>> map to the
> >>>> RPI definition. This means that I could only trust SAGITTAL and
> >>> CORONAL
> >>>> image definitions, and would be forced to assume all other
> >>> definitions are
> >>>> "best guesses"
> >>>>
> >>>> ###############################
> >>>> ###############################
> >>>> ###############################
> >>>> Another acceptable solution would be to reorient the image data
> >>> for those
> >>>> other 45 possibilities to the RPI orientation prior to
> >>> writing. I assume
> >>>> that the main problem is that the default direction cosign of
> >>>> 1 0 0
> >>>> 0 1 0
> >>>> 0 0 1
> >>>>
> >>>> Is not a legal tag for analyze file formats.
> >>>>
> >>>> ###############################
> >>>> ###############################
> >>>> ###############################
> >>>> Finally, there is a bit of a compromise. I was originally
> >>> advised not to
> >>>> use analyze orient codes of "3,4,5,6" because they are so often
> >>> mis-used by
> >>>> improper 3rd party analyze image implementors:
> >>>>
> >>>> typedef enum _analyze75_orient_code
> >>>> {
> >>>> a75_transverse_unflipped = 0,
> >>>> a75_coronal_unflipped = 1,
> >>>> a75_sagittal_unflipped = 2,
> >>>> a75_transverse_flipped = 3,
> >>>> a75_coronal_flipped = 4,
> >>>> a75_sagittal_flipped = 5,
> >>>> a75_orient_unknown = 6
> >>>> }
> >>>> analyze_75_orient_code;
> >>>>
> >>>> Conversations with the Analyze folks indicated that to respect
> >>> the original
> >>>> intent of the file format, that orient codes of "3,4,5,6" were
> >>> only to be
> >>>> used internal to the Analyze program for display purposes, and
> >>> were never
> >>>> supposed to be written to disk.
> >>>>
> >>>> I would be quite comfortable with having this implementation put
> >>> into place.
> >>>> I would like to put a prohibition on reading or writing
> >>> orientaiton codes
> >>>> with the unknown orientation flag. Again force re-orientation of
> >>> the image
> >>>> to a valid (preferably code 0,1,2) orientation before writing.
> >>>>
> >>>> Sorry to be so draconian about this, but I have been very embarrassed
> >>>> because I depended on ITK getting these orientation done
> >>> correctly. When
> >>>> using ITK to convert dicom images to both nifti and analyze
> >>> images, about 5%
> >>>> of the 500 images were right left swapped when the nifti and
> >>> analyze images
> >>>> were loaded with ITK tools. I confirmed the problem by using a
> >>> simple image
> >>>> difference program, and the dicom-nifti always gave 0, but 5% of the
> >>>> nifti-analyze showed the right left swap.
> >>>>
> >>>> I'm leaving town tomorrow, so won't be able to put this into
> >>> place, but
> >>>> perhaps I can get some help? If this is something that needs to
> >>> be done
> >>>> quickly, Kent Williams should have time during the middle to end
> >>> of this
> >>>> week to work on the changes and tests. There should be a test to
> >>> ensure
> >>>> that only valid accepted codes can be read and written to
> >>> disk. If the
> >>>> difference between reading and writing analyze or nifti (or any other
> >>>> sufficiently tagged format Meta/Dicom) should be un-ambiguous.
> >>>>
> >>>> Ok...enough ranting ;)
> >>>>
> >>>> Regards,
> >>>> Hans
> >>>>
> >>>>
> >>>>
> >>>> On 2/24/07 10:49 AM, "Stephen R. Aylward"
> >>> <Stephen.Aylward at Kitware.com <mailto:Stephen.Aylward at Kitware.com>>
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> The behavior of the Analyze writer has changed. Now if the
> >>> orientation
> >>>>> of the image isn't known, an exception is thrown.
> >>>>>
> >>>>> The changes are related to the switch from metadata orientation
> >>> usage to
> >>>>> oriented image usage.
> >>>>>
> >>>>> I suggest that if the orientation is unknown/undefined, then we
> >>> throw a
> >>>>> warning, but continue under the assumption of RPI (the default
> >>> used in
> >>>>> other cases). Only if the orientation is explicit and not a
> >>> supported
> >>>>> type should we throw an exception.
> >>>>>
> >>>>> I've make the changes in my local version and can forward them
> >>> to anyone
> >>>>> with cvs access.
> >>>>>
> >>>>> Stephen
> >>>>
> >>> --
> >>> =============================================================
> >>> Stephen R. Aylward, Ph.D.
> >>> Chief Medical Scientist
> >>> Kitware, Inc. - Chapel Hill Office
> >>> http://www.kitware.com
> >>> Phone: (518)371-3971 x300
> >>> _______________________________________________
> >>> Insight-developers mailing list
> >>> Insight-developers at itk.org <mailto:Insight-developers at itk.org>
> >>> http://www.itk.org/mailman/listinfo/insight-developers
> >>>
> >>>
> >
> >
>
> --
> =============================================================
> Stephen R. Aylward, Ph.D.
> Chief Medical Scientist
> Kitware, Inc. - Chapel Hill Office
> http://www.kitware.com
> Phone: (518)371-3971 x300
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.itk.org/mailman/private/insight-developers/attachments/20070225/ff39a3a6/attachment-0001.htm
More information about the Insight-developers
mailing list