[Insight-developers] Image as an OrientedImage Progress

[Rupert Brooks]

I've used ITK for a lot of image registration tasks, including some
not exclusively medical ones.  In computer vision and geomatics work,
2D images that are really 2D are pretty common.   Genuinely 2D in that
there is not particularly an implied third dimension.  In this case,
having a 2x2 set of direction cosines makes perfect sense.    For me,
conceptually speaking, a 2D slice that is embedded in a 3D volume is
actually a 3D volume, one voxel thick, and should be read as a 3D
image.

I'm definitely not a fan of embedding all 2D images in 3D.  Would all
image gradients then have to be computed in 3D, although they would be
meaningless in the direction normal to the image?

Perhaps a less painful way to fix the issue is, if the image is read
in 2D, but has 3D direction cosines, the 2D direction cosines are set
to the identity.  Alternatively, one could project the appropriate set
of coordinate axes onto the 3D image axes and come up with a set of 2D
direction cosines related to the original embedding.  Honestly im not
sure such a projection would actually mean very much.  However, either
of these approaches would not give degenerate results.

Cheers,

Rupert


On Tue, Sep 16, 2008 at 11:49 AM, kent williams
<norman-k-williams at uiowa.edu> wrote:
> There is a similar problem in the Analyze ImageIO, and it's rather baffling
> that it doesn't show up in e.g. The NIfTI ImageIO.
>
> I'm not sure about how to fix this, but the thing about 2D images is that
> they always have an implied third dimension, which is perpendicular to the
> acquisition plane.  The ideal situation would be this: if ITK reads a 2D
> image, it should embed it correctly in a 3D volume. As you point out, that's
> how DICOM works.
>
> I can think of only a couple ways to fix this; one easy and probably wrong
> in ways that won't matter a large percentage of the time, and one hard and
> correct.
>
> Easy: Stop throwing the exception, and silently allow degenerate dir cosines
> in 2D.
> Hard: Make 3 the minimum size for a direction cosine.
>
> The 'hard' solution means these things:
>
> 1. Verify that every ImageIO class fills out 3 vectors even in 2D
> 2. Look for and verify that every class in the library, every example
> program, and every InsightApplications program, that diddles dir cosines
> directly does something reasonable in the 2D case.
>
> As far as programs by Insight Users go, just going to OrientedImage as the
> default will break a few of them.
>
> On 9/16/08 9:57 AM, "Bill Lorensen" <bill.lorensen at gmail.com> wrote:
>
>> Here is the problem with the remaining failing tests. This issue has
>> been raised before.
>> See http://public.kitware.com/Bug/view.php?id=5573
>>
>> There are really two "dimensions" of an image.
>>
>> 1) ImageDimension is the number of dimensions in the image container,
>> 1, 2, 3, ...
>> 2) I'll call it SpatialDimension, the number of dimensions in the
>> coordinate system of the image. This dimension is the dimension used
>> for origin, spacing and the direction.
>>
>> For example, in general, DICOM images have an image dimension of 2,
>> yet the image position patient and directions are of dimension 3.
>> Analyze images have the same issue. And I'm sure nrrd's also.
>>
>> In the failing tests, single dicom images are selected and the direction
>> 1 0 0
>> 0 0 -1
>> 0 -1 0
>>
>> The current logic in ImageFileReader, simply truncates the direction to:
>> 1 0
>> 0 0
>> which is singular.
>>
>> So... we need some further thought about this problem.
>>
>
>
>
> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>



-- 
--------------------------------------------------------------
Rupert Brooks