<br><br><div class="gmail_quote">On Fri, Apr 25, 2008 at 3:19 PM, Mathieu Malaterre <<a href="mailto:mathieu.malaterre@gmail.com">mathieu.malaterre@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On Fri, Apr 25, 2008 at 3:01 PM, Jesús Spínola <<a href="mailto:jspinola@gmail.com">jspinola@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
><br>
> On Fri, Apr 25, 2008 at 2:28 PM, Mathieu Malaterre<br>
> <<a href="mailto:mathieu.malaterre@gmail.com">mathieu.malaterre@gmail.com</a>> wrote:<br>
> > Hi Jesús,<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Fri, Apr 25, 2008 at 2:15 PM, Jesús Spínola <<a href="mailto:jspinola@gmail.com">jspinola@gmail.com</a>><br>
> wrote:<br>
> > ><br>
> > ><br>
> > ><br>
> > > On Fri, Apr 25, 2008 at 12:24 PM, Mathieu Malaterre<br>
> > > <<a href="mailto:mathieu.malaterre@gmail.com">mathieu.malaterre@gmail.com</a>> wrote:<br>
> > > > Hi Jesús,<br>
> > > ><br>
> > > > The short answer:<br>
> > > > Indeed this is a bug in the code. This is fixed in the current ITK<br>
> CVS:<br>
> > > ><br>
> > > > $ cvs ci -m"ENH: When gdcm cannot read, it means gdcm cannot read..."<br>
> > > > itkGDCMImageIO.cxx<br>
> > > > /cvsroot/Insight/Insight/Code/IO/itkGDCMImageIO.cxx,v <--<br>
> > > itkGDCMImageIO.cxx<br>
> > > > new revision: 1.136; previous revision: 1.135<br>
> > > ><br>
> > > > $ cvs ci -m"ENH: prevent segfault. The last else should not always<br>
> > > > call the jpeg decompressor when the image is NOT jpeg"<br>
> > > ><br>
> /cvsroot/Insight/Insight/Utilities/gdcm/src/gdcmJPEGFragmentsInfo.cxx,v<br>
> > > > <-- src/gdcmJPEGFragmentsInfo.cxx<br>
> > > > new revision: 1.6; previous revision: 1.5<br>
> > > > /cvsroot/Insight/Insight/Utilities/gdcm/src/gdcmPixelReadConvert.cxx,v<br>
> > > > <-- src/gdcmPixelReadConvert.cxx<br>
> > > > new revision: 1.9; previous revision: 1.8<br>
> > > ><br>
> > ><br>
> > > So, if apply this changes it would prevent the application to crash, but<br>
> it<br>
> > > would not be able to open the images. Is that right?<br>
> > ><br>
> > ><br>
> > > ><br>
> > > > The long answer:<br>
> > > ><br>
> > > > I have had a look at your image, and those are the famous ELSCINT1 /<br>
> > > > PMSCT_RLE1 compressed image. They are falsely declared as MR Image<br>
> > > > Storage (1.2.840.10008.5.1.4.1.1.4), they contains all information but<br>
> > > > are missing the most important one: Pixel Data (7fe0,0010). Instead it<br>
> > > > is being replaced with a binary blob at Private Data Element<br>
> > > > (07a1,xx0a,ELSCINT1), with an unknown compression algorithm.<br>
> > > > This issue has very recently been raised in the comp.protocols.dicom,<br>
> > > ><br>
> > > ><br>
> > ><br>
> <a href="http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/f07b8ffda372f4f7" target="_blank">http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/f07b8ffda372f4f7</a><br>
> > > ><br>
> > > > As of now, I do not know of any library that can read your image<br>
> > > > (please get in touch with Yves Martel, CC in this email, if you want<br>
> > > > more info). But again there is no guarantee that this image will ever<br>
> > > > be read by something else than the original Scanner. As a side note,<br>
> > > > you should rather contact your PACS admin, and ask him to properly<br>
> > > > export those images (instead of directly ftp'ing into the machine).<br>
> > > ><br>
> > ><br>
> > > Thanks a lot for this information. I'm in touch with the PACS admin to<br>
> solve<br>
> > > this problem. I hope he could solve this problem making the appropriatte<br>
> > > export to standard DICOM.<br>
> > ><br>
> > ><br>
> > > ><br>
> > > > HTH<br>
> > > > -Mathieu<br>
> > > > Ps: so when you say vtk is able to open the image, you mean it does<br>
> > > > not crash ? I would be *very* surprised if vtkDICOMImageReader would<br>
> > > > be able to read, say your image: study1/s10/i10 :)<br>
> > ><br>
> > > You're right, It does not crash with vtk, but i didn't tried to view the<br>
> > > image. I miss to tell that detail.<br>
> > > But dcmtk is able to open it correctly, because I create the preview<br>
> > > thubmnails with dcmtk, so with dcmtk I can render the image.<br>
> ><br>
> > Would you be kind enough and tell me how you are generating this<br>
> > thumbnail ? The only -believable- option I can think of is that you<br>
> > are running your program on the original image (pre anonymization) and<br>
> > they still contain the Icon Image Sequence (a small screenshot<br>
> > generally 64x64) that is *not* compressed and is perfectly readable by<br>
> > all reader. But -again- this is NOT the Pixel Data, and Icon Image<br>
> > Sequence is absolutely not passed to ITK.<br>
> ><br>
><br>
> I generate the thumbnail based on this code:<br>
> <a href="http://forum.dcmtk.org/viewtopic.php?t=120&highlight=pixmap" target="_blank">http://forum.dcmtk.org/viewtopic.php?t=120&highlight=pixmap</a><br>
><br>
> I've made a dicom dump of the original image and surprisingly it contains<br>
> the Pixel Data (7fe0,0010)! Maybe the ELSCINT1 compression is made by the<br>
> philips sofware when anonymazing the images.<br>
><br>
> So, beacause the anonymization by philips is introducing some errors that<br>
> impede to check the real problem, I've attached an anonymized image by hand<br>
> ( with dcmtk's dcmmodify ). That's the first image of the first series.<br>
><br>
> I hope we can find the real problem<br>
<br>
</div></div>LOL !<br>
<br>
This is the best anonymization software I have ever seen, they really<br>
hide *all* patient information :)<br>
<br>
Thanks for the file, I'll check why gdcm 1.2 is reporting it as<br>
non-readable, but gdcm 1.3 can read it fine...<br>
</blockquote><div><br>Does the latest version of itk (3.6.0) comes with gdcm 1.2 or 1.3? Updating to the latest version of itk solves the problem or may I have to apply some patch?<br>thanks for your help!<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Thanks,<br>
--<br>
<font color="#888888">Mathieu<br>
</font></blockquote></div><br>