[Insight-users] Read Write Dicom Image

[Andreas Schuh]

Hi Andreas,

I guess the series it worked with had a patient orientation of, for 
instance, 1/0/0/0/1/0. I had a look at the source
of the itk::ImageFileReader. As you're reading a 2D image, the third 
components of the direction cosines get lost.
So resulting in an direction matrix of [1 0; 0 0] in your case. However, 
itk::ImageFileReader handles this case and
sets the direction to [1 0; 0 1]. But you should check this by printing 
the direction matrix right after reading the
image. But you would get exactly the exception you mentioned, if the 
itk::ImageFileReade does not handle the
degraded direction matrix. So if the direction matrix was correct after 
you read the image, the question is,
when is the direction been changed? Does the filter you've mentioned 
change it? Then this filter might do
something wrong. The writer won't cause this exception if you updated 
the inputs before, as he won't modify
the direction of the input image. So the exception isn't caused by the 
writer, but the filters before.

BTW: If you write a 2D image as DICOM file, the third components of the 
row and column direction cosines
are set to zero, if you don't pass this DICOM header entry with the 
MetaData dictionary. But if you read it
back as 2D, this shouldn't matter.

--
regards
Andreas

Mathieu Malaterre schrieb:
> On Mon, Mar 30, 2009 at 1:40 PM, Andreas Hahn <zweikaesehoch at gmx.de> wrote:
>   
>> Hi Mathieu!
>> I use ITK 3.10.2.
>> I got an error which may be related to the GDCM bug you described:
>> Am 25.03.2009 um 19:46 schrieb Mathieu Malaterre:
>>
>> Thanks !
>>
>> A couple of notes though:
>>
>> 1. There is bug currently in GDCM 2.0.10 where the z-spacing (3rd
>> dimension) is not properly computed for the new Enhanced [CT|MR] Image
>> Storage and images contained in the multi-frames volume would not have
>> the same Image Orientation (Patient) (=Direction Cosines).
>> 2. I am working on the next release (GDCM 2.0.11) and gdcminfo will
>> even be able to report whether or not the image is lossy or
>> lossless(*). This is a key feature to have in high quality environment
>> (such as clinical trial).
>>
>> My error occurs when i try to write a DICOM series after i loaded, applied a
>> filter on it and made some changes in only the following DICOM values:
>> std::string entrySeriesUID("0020|000e"); //Series UID
>> std::string entryStudy( "0008|1030" ); //Study Description
>> std::string entrySeries( "0008|103e" ); //Series Description
>> std::string entryProtocol( "0018|1030" ); //Protocol Type
>> The error message (don't mind about the change in my namespace):
>> Exception thrown while writing the series
>> itk3102::ExceptionObject (0xa90d60)
>> Location: "void
>> itk3102::ImageBase<VImageDimension>::ComputeIndexToPhysicalPointMatrices()
>> [with unsigned int VImageDimension = 2u]"
>> File: ./ITK3102/Code/Common/itkImageBase.txx
>> Line: 188
>> Description: itk3102::ERROR: Image(0xa8fd00): Bad direction, determinant is
>> 0. Direction is 1 0
>> 0 0
>> The DICOM pairs of origin and direction:
>> 0020|0032 = -176.00362324715\31.713768005371\198
>> 0020|0037 = 1\0\0\0\0\-1
>>
>> Do you think the error is caused by the GDCM bug?
>> If yes: How can i fix it?
>> If no: What did i do wrong? There was at least one series where my code
>> worked with.
>>     
>
> If you are using ITK 3.10.2 with default gdcm library then in no way
> can you be impacted by the issue I described.
> There has been an internal change in ITK which make it now more picky
> with invalid direction cosines, I do not believe this has anything to
> do with GDCM (IMHO). Hopefully someone can help you out on your issue.
>
> Good luck
>