[Insight-users] Read Write Dicom Image

[Andreas Hahn]

>
> Hi Andreas,
>
> thank you for your detailed answer. You were right! It is a bug that  
> has to to with ImageFileReader and has been fixed since 3.12. See http://www.vtk.org/Bug/view.php?id=8470&nbn=5
>
> So i have to update and change the namespace again! grrr. I will  
> write a perlscript to do that for future releases.
>
> Regards,
> Andreas
>
> Am 30.03.2009 um 15:06 schrieb 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
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090331/1ba697cc/attachment-0001.htm>