<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:

.7005218-E000\1018.7005210-E which produces: this->PixelSpacing[0] = 0.7005218 this->PixelSpacing[1] = 1018.7005210 You'll notice that the Big endian version of the string is swapped by blocks of 4 bytes.

In the ReadNextRecord method of the DICOMParser class, the Pixel spacing tag is set to be swapped. That tag being a string, does it really need to be swapped? Is the spacing tag always an 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>