[vtk-developers] TestSobel2D-image dashboard failures, anyone know anything about this?

[Bill Lorensen]

Matthieu,

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.

Bill


On 7/10/07, Mathieu Coursolle <mcoursolle at rogue-research.com> wrote:
>
> Hi,
>
> You were right, TestSobel2D started to fail after the 2006/05/03 change
> of the DICOMAppHelper.cxx file. The change was good, but it made the
> spacing
> values to be set individually. They were set to the same value before. It
> then
> made visible a problem that was already there.
>
> In fact, the string we want to convert is the following:
>
> 007.812500E-01\07.812500E-01
>
> On little endians, it is read as follow:
>
> this->PixelSpacing[0] = 0.78125
> this->PixelSpacing[1] = 0.78125
>
> 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?
>
> If I comment the VR_FL case from the switch case statement which
> determine what need
> to be swapped, TestSobel2D then pass on both intel and PPC.
>
> I attached a patch, for which all tests passed on both intel and PPC
> with TCL enabled.
> (Except for TestImageTracerWidget on my machine, but this is some other
> issue).
>
> Thanks.
>
> Mathieu
>
>
> >On 7/9/07, Sebastien BARRE <sebastien.barre at kitware.com> wrote:
> >>
> >>  At 7/6/2007 07:59 PM, Bill Lorensen wrote:
> >>
> >> I see a change to DICOMAppHelper.cxx
> >> http://public.kitware.com/cgi-bin/viewcvs.cgi/Utilities/DICOMParser/
> >DICOMAppHelper.cxx.diff?cvsroot=VTK&r1=1.25&r2=1.26
> >>
> >
> >Sean, can you confirm that applying the reversed (patch -R) patch you
> >get a clean dashboard ?
> >
> >>  Now to be honest I think the DICOM code in VTK should be yanked and
> >> replaced with support for GDCM. The DICOM protocol is too complex and
> too
> >> time consuming to be maintained in different libraries any longer, and
> GDCM
> >> has been used in ITK (or internally at Kitware) with good success so
> far, if
> >> I'm correct.
> >
> >GDCM is a pretty good choice indeed ;-P
> >As a side note, it took me quite a while to get GDCM to compile on the
> >mulitple compilers supported by ITK. I think it will be an even
> >greater challenge to get it supported by all compilers VTK supports...
> >Not mentionning the jpeg8/12/16/j2k library addition
> >
> >--
> >Mathieu
> >_______________________________________________
> >vtk-developers mailing list
> >vtk-developers at vtk.org
> >http://www.vtk.org/mailman/listinfo/vtk-developers
> >
>
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20070710/3a6ee726/attachment.html>