<div>Matthieu,</div>
<div> </div>
<div>I notice that the code in ITK's version of DICOMParser just "break"'s for both VR_FL and VR_FD. No swapping is done. I have more confidence in the ITK implementation than I do in the VTK implementation. Note though, we recommend using GDCM in ITK. DICOMParser remains for backward compatibility.
</div>
<div> </div>
<div>Bill<br><br> </div>
<div><span class="gmail_quote">On 7/10/07, <b class="gmail_sendername">Mathieu Coursolle</b> <<a href="mailto:mcoursolle@rogue-research.com">mcoursolle@rogue-research.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi,<br><br>You were right, TestSobel2D started to fail after the 2006/05/03 change<br>of the DICOMAppHelper.cxx
file. The change was good, but it made the spacing<br>values to be set individually. They were set to the same value before. It then<br>made visible a problem that was already there.<br><br>In fact, the string we want to convert is the following:
<br><br>007.812500E-01\07.812500E-01<br><br>On little endians, it is read as follow:<br><br>this->PixelSpacing[0] = 0.78125<br>this->PixelSpacing[1] = 0.78125<br><br>However, on Big endian, the string is read as follow:
<br><br>.7005218-E000\1018.7005210-E<br><br>which produces:<br><br>this->PixelSpacing[0] = 0.7005218<br>this->PixelSpacing[1] = 1018.7005210<br><br>You'll notice that the Big endian version of the string<br>is swapped by blocks of 4 bytes.
<br><br>In the ReadNextRecord method of the DICOMParser class, the Pixel spacing tag<br>is set to be swapped.<br><br>That tag being a string, does it really need to be swapped? Is the<br>spacing tag always an<br>ASCII string in the DICOM files?
<br><br>If I comment the VR_FL case from the switch case statement which<br>determine what need<br>to be swapped, TestSobel2D then pass on both intel and PPC.<br><br>I attached a patch, for which all tests passed on both intel and PPC
<br>with TCL enabled.<br>(Except for TestImageTracerWidget on my machine, but this is some other<br>issue).<br><br>Thanks.<br><br>Mathieu<br><br><br>>On 7/9/07, Sebastien BARRE <<a href="mailto:sebastien.barre@kitware.com">
sebastien.barre@kitware.com</a>> wrote:<br>>><br>>> At 7/6/2007 07:59 PM, Bill Lorensen wrote:<br>>><br>>> I see a change to DICOMAppHelper.cxx<br>>> <a href="http://public.kitware.com/cgi-bin/viewcvs.cgi/Utilities/DICOMParser/">
http://public.kitware.com/cgi-bin/viewcvs.cgi/Utilities/DICOMParser/</a><br>>DICOMAppHelper.cxx.diff?cvsroot=VTK&r1=1.25&r2=1.26<br>>><br>><br>>Sean, can you confirm that applying the reversed (patch -R) patch you
<br>>get a clean dashboard ?<br>><br>>> Now to be honest I think the DICOM code in VTK should be yanked and<br>>> replaced with support for GDCM. The DICOM protocol is too complex and too<br>>> time consuming to be maintained in different libraries any longer, and GDCM
<br>>> has been used in ITK (or internally at Kitware) with good success so<br>far, if<br>>> I'm correct.<br>><br>>GDCM is a pretty good choice indeed ;-P<br>>As a side note, it took me quite a while to get GDCM to compile on the
<br>>mulitple compilers supported by ITK. I think it will be an even<br>>greater challenge to get it supported by all compilers VTK supports...<br>>Not mentionning the jpeg8/12/16/j2k library addition<br>><br>
>--<br>>Mathieu<br>>_______________________________________________<br>>vtk-developers mailing list<br>><a href="mailto:vtk-developers@vtk.org">vtk-developers@vtk.org</a><br>><a href="http://www.vtk.org/mailman/listinfo/vtk-developers">
http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>><br><br>_______________________________________________<br>vtk-developers mailing list<br><a href="mailto:vtk-developers@vtk.org">vtk-developers@vtk.org</a><br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br><br><br></blockquote></div><br>