<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div> </div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Andreas,<div><br></div><div>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 <a href="http://www.vtk.org/Bug/view.php?id=8470&nbn=5">http://www.vtk.org/Bug/view.php?id=8470&nbn=5</a> </div><div><br></div><div>So i have to update and change the namespace again! grrr. I will write a perlscript to do that for future releases.</div><div><br></div><div>Regards,</div><div>Andreas</div><div><br><div><div>Am 30.03.2009 um 15:06 schrieb Andreas Schuh:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi Andreas,<br><br>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<br>of the itk::ImageFileReader. As you're reading a 2D image, the third components of the direction cosines get lost.<br>So resulting in an direction matrix of [1 0; 0 0] in your case. However, itk::ImageFileReader handles this case and<br>sets the direction to [1 0; 0 1]. But you should check this by printing the direction matrix right after reading the<br>image. But you would get exactly the exception you mentioned, if the itk::ImageFileReade does not handle the<br>degraded direction matrix. So if the direction matrix was correct after you read the image, the question is,<br>when is the direction been changed? Does the filter you've mentioned change it? Then this filter might do<br>something wrong. The writer won't cause this exception if you updated the inputs before, as he won't modify<br>the direction of the input image. So the exception isn't caused by the writer, but the filters before.<br><br>BTW: If you write a 2D image as DICOM file, the third components of the row and column direction cosines<br>are set to zero, if you don't pass this DICOM header entry with the MetaData dictionary. But if you read it<br>back as 2D, this shouldn't matter.<br><br>--<br>regards<br>Andreas<br><br>Mathieu Malaterre schrieb:<br><blockquote type="cite">On Mon, Mar 30, 2009 at 1:40 PM, Andreas Hahn <<a href="mailto:zweikaesehoch@gmx.de">zweikaesehoch@gmx.de</a>> wrote:<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"><blockquote type="cite">Hi Mathieu!<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I use ITK 3.10.2.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I got an error which may be related to the GDCM bug you described:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Am 25.03.2009 um 19:46 schrieb Mathieu Malaterre:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Thanks !<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">A couple of notes though:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">1. There is bug currently in GDCM 2.0.10 where the z-spacing (3rd<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">dimension) is not properly computed for the new Enhanced [CT|MR] Image<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Storage and images contained in the multi-frames volume would not have<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the same Image Orientation (Patient) (=Direction Cosines).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">2. I am working on the next release (GDCM 2.0.11) and gdcminfo will<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">even be able to report whether or not the image is lossy or<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">lossless(*). This is a key feature to have in high quality environment<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">(such as clinical trial).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">My error occurs when i try to write a DICOM series after i loaded, applied a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">filter on it and made some changes in only the following DICOM values:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">std::string entrySeriesUID("0020|000e"); //Series UID<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">std::string entryStudy( "0008|1030" ); //Study Description<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">std::string entrySeries( "0008|103e" ); //Series Description<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">std::string entryProtocol( "0018|1030" ); //Protocol Type<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The error message (don't mind about the change in my namespace):<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Exception thrown while writing the series<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">itk3102::ExceptionObject (0xa90d60)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Location: "void<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">itk3102::ImageBase<VImageDimension>::ComputeIndexToPhysicalPointMatrices()<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">[with unsigned int VImageDimension = 2u]"<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">File: ./ITK3102/Code/Common/itkImageBase.txx<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Line: 188<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Description: itk3102::ERROR: Image(0xa8fd00): Bad direction, determinant is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">0. Direction is 1 0<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">0 0<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The DICOM pairs of origin and direction:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">0020|0032 = -176.00362324715\31.713768005371\198<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">0020|0037 = 1\0\0\0\0\-1<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Do you think the error is caused by the GDCM bug?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">If yes: How can i fix it?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">If no: What did i do wrong? There was at least one series where my code<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">worked with.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> <br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If you are using ITK 3.10.2 with default gdcm library then in no way<br></blockquote><blockquote type="cite">can you be impacted by the issue I described.<br></blockquote><blockquote type="cite">There has been an internal change in ITK which make it now more picky<br></blockquote><blockquote type="cite">with invalid direction cosines, I do not believe this has anything to<br></blockquote><blockquote type="cite">do with GDCM (IMHO). Hopefully someone can help you out on your issue.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Good luck<br></blockquote><blockquote type="cite"> <br></blockquote></div></blockquote></div><br></div></div></blockquote></div><br></body></html>