No subject

expressed in?

I had a similar question a month or so ago and got this response from 
Luis saying that ITK used the LPS world coordinate system ( 
http://www.itk.org/pipermail/insight-users/2008-August/027102.html ).  I 
think the choice of LPS should be better documented then it is at the 
moment.

But once that is made more clear, I don't see what the problem is? It 
seems like having the filereaders bring the files directional cosines 
matrix into the LPS world frame is the correct thing to do. If we want 
to add the functionality of being able to grab the location of a pixel 
in another world frame (RAS for example) then it seems like the proper 
place to put this would be in
TransformIndexToPhysicalPoint(), GetDirection() and GetOrigin(). They 
could take a flag specifying the desired frame of the output and convert 
the internal LPS stored directional cosines into what ever the user 
wanted. This way the functionality would be available for all image 
types as opposed to only NRRD.

-Luke





Gordon Kindlmann wrote:
>
> This patch confuses two independent issues:
>
> 1) turning on ITK_USE_ORIENTED_IMAGE_DIRECTION.  It sounds like you're 
> happy with this, specifically the resulting enhancements in 
> orientation behavior to itkVectorImage.  Great.
>
> 2) itkNrrdImageIO.cxx's conversion of explicitly RAS orientation to 
> the implicit LPS orientation of ITK.  You're understandably not happy 
> with this.
>
> The patch you suggest confuses the issues by disabling (2) when (1) is 
> off, but the two things are completely unrelated, so I'm not going to 
> commit this.
>
> The real solution is to enable explicit run-time control of whether 
> the RAS -> LPS orientation conversion happens inside itkNrrdImageIO.  
> This would replace how you used ITK_USE_ORIENTED_IMAGE_DIRECTION in 
> your patch, with some new member variable (and would use "if ()" 
> instead of "#ifndef").
>
> Before I try anything like that, though, I need others to comment on
>
> 1) Whether there are any existing examples of state variables in file 
> input, so that at run-time users can vary the handling of data after 
> its read from disk, and before its returned to ITK.
>
> 2) Documentation of ITK's use of LPS for 3-D orientation 
> specification.  Is it really the policy, or not?
>
> Gordon
>
> On Oct 19, 2008, at 9:31 PM, Daniel Betz wrote:
>
>> Hello Gordon,
>>
>> as far as I can see are the following files affected
>>
>> itkNrrdImageIO.cxx
>> itkNiftiImageIO.cxx
>> itkAnalyzeImageIO.cxx
>> itkGE4ImageIO.cxx
>> itkGE5ImageIO.cxx
>> itkGEAdwImageIO.cxx
>> itkPolygonGroupSpatialObjectXMLFile.cxx
>> itkSiemensVisionImageIO.cxx
>>
>>
>> With the new oriented itk::Image it is actually very easy to get
>> a file correctly loaded. With the commit to itkVectorImage.txx a
>> few ours ago I need only three "#ifndef" in itkNrrdImageIO.cxx and
>> my test program from the beginning of this thread passed.
>>
>> <diff>
>> Index: Code/IO/itkNrrdImageIO.cxx
>> ===================================================================
>> RCS file: /cvsroot/Insight/Insight/Code/IO/itkNrrdImageIO.cxx,v
>> retrieving revision 1.38
>> diff -u -r1.38 itkNrrdImageIO.cxx
>> --- Code/IO/itkNrrdImageIO.cxx  16 May 2007 19:44:55 -0000  1.38
>> +++ Code/IO/itkNrrdImageIO.cxx  19 Oct 2008 23:48:47 -0000
>> @@ -442,6 +442,7 @@
>>        case nrrdSpacingStatusDirection:
>>          if (AIR_EXISTS(spacing))
>>            {
>> +#ifndef ITK_USE_ORIENTED_IMAGE_DIRECTION
>>            // only set info if we have something to set
>>            switch (nrrd->space)
>>              {
>> @@ -464,6 +465,7 @@
>>                // to LPS is well-defined
>>                break;
>>              }
>> +#endif
>>            this->SetSpacing(axii, spacing);
>>
>>            for (unsigned int saxi=0; saxi < nrrd->spaceDim; saxi++)
>> @@ -496,6 +498,7 @@
>>          {
>>          spaceOrigin[saxi] = nrrd->spaceOrigin[saxi];
>>          }
>> +#ifndef ITK_USE_ORIENTED_IMAGE_DIRECTION
>>        switch (nrrd->space)
>>          {
>>          // convert non-LPS coords into LPS coords, when we can
>> @@ -514,6 +517,7 @@
>>            // to LPS is well-defined
>>            break;
>>          }
>> +#endif
>>        for (unsigned int saxi=0; saxi < nrrd->spaceDim; saxi++)
>>          {
>>          this->SetOrigin(saxi, spaceOrigin[saxi]);
>> @@ -641,13 +645,16 @@
>>        case nrrdSpaceRightAnteriorSuperior:
>>        case nrrdSpaceLeftAnteriorSuperior:
>>        case nrrdSpaceLeftPosteriorSuperior:
>> +#ifndef ITK_USE_ORIENTED_IMAGE_DIRECTION
>>          // in all these cases we could convert
>>          EncapsulateMetaData<std::string>(thisDic, std::string(key),
>> -                                         std::string( 
>> airEnumStr(nrrdSpace,
>> nrrdSpaceLeftPosteriorSuperior )));
>> +                                         std::string( 
>> airEnumStr(nrrdSpace,
>> +                                         
>> nrrdSpaceLeftPosteriorSuperior )));
>>          break;
>>        default:
>>          // we're not coming from a space for which the conversion
>>          // to LPS is well-defined
>> +#endif
>>          EncapsulateMetaData<std::string>(thisDic, std::string(key),
>>                                           std::string(val));
>>          break;
>> </diff>
>>
>> Regards
>> Daniel Betz
>>
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users