[Insight-users] Re: Bug 1056

Tue Dec 21 09:48:58 EST 2004

> > Please give it a try and let us know if it is working fine now, this
> > is one of those changes that may seem inocuous but actually can have
> > quite dangerous consequences. (e.g. when the images are used for
> > treatement planning).

I would like to ask for some verification of your last point Luis
regarding treatment planning using ITK.  Has the Insight Toolkit been
FDA approved?  That is, are you allowed to make clinical decisions using
software based on the Insight Toolkit?

Best regards,

Tuhin Sinha

On Tue, 2004-12-21 at 08:27, Mark Wyszomierski wrote:
> Hello all,
> 
> I was just reading this message and was surprised to learn that the
> tag pixel spacing (0028,0030) has the Y spacing as the first number,
> followed by the X spacing. Where in the DICOM standard is this noted?
> (I know the standard's home is http://medical.nema.org/) but in which
> of these documents does it say Y is first?
> 
> Thanks!
> 
> 
> On Wed, 15 Dec 2004 10:42:23 -0500, Li, George (NIH/NCI)
> <ligeorge at mail.nih.gov> wrote:
> > (0028,0030) is officially labeled as DS, which is
> > a decimal string. You have to convert it to floating
> > point.
> > 
> > George
> > 
> > 
> > -----Original Message-----
> > From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
> > Sent: Wednesday, December 15, 2004 10:35 AM
> > To: Miller, James V (Research)
> > Cc: Insight-users at itk.org
> > Subject: Re: [Insight-users] Re: Bug 1056
> > 
> > Jim,
> > 
> >        From http://medical.nema.org/dicom/2004/04_06PU.PDF
> > 
> > Pixel spacing is:
> > 
> > ...
> > (0028,0030) Pixel Spacing DS 2
> > ...
> > 
> > So this is a string representing a floating point number (DS) with a
> > value multiplicity of 2.
> > 
> > HTH
> > Mathieu
> > 
> > Miller, James V (Research) wrote:
> > > Luis,
> > >
> > > Should the representation for 0x0028,0x0030 be VR_SH instead of VR_FL?
> > > (short string instead of float)
> > >
> > > If so, we could handle the tag like we do the ImagePositionPatient
> > > tag. Which may clean up the new code you added a little.
> > >
> > > Jim
> > >
> > >
> > > -----Original Message-----
> > > From: Luis Ibanez [mailto:luis.ibanez at kitware.com]
> > > Sent: Wednesday, December 15, 2004 8:35 AM
> > > To: UKoehler at dhzb.de
> > > Cc: Insight-users at itk.org
> > > Subject: [Insight-users] Re: Bug 1056
> > >
> > >
> > >
> > > Hi Uwe,
> > >
> > > Thanks for trying the changes and letting us know about the order of
> > > the spacing.
> > >
> > > Following your indications we just committed a change to
> > > the CVS repository. The pixel spacing along X and Y should now be in
> > > the correct order.
> > >
> > > Please give it a try and let us know if it is working fine now, this
> > > is one of those changes that may seem inocuous but actually can have
> > > quite dangerous consequences. (e.g. when the images are used for
> > > treatement planning).
> > >
> > >
> > >   Regards
> > >
> > >
> > >        Luis
> > >
> > >
> > > --------------------------
> > > Dr. Uwe Kohler wrote:
> > >
> > >
> > >>Dear Luis,
> > >>
> > >>many thanks for the quick help. I updated the DICOMAppHelper.cxx only
> > >>in
> > >>Version 1.8.1 and I do get different values for the pixel spacing in x-
> > and
> > >
> > >
> > >>y-direction now. However, after a discussion with the manufacturer of
> > >>the
> > >>MR-Scanner (Bruker) and after checking the standard (my quote below is
> > >
> > > taken
> > >
> > >>directly from the DICOM standard document), I am convinced it is
> > >
> > > Row-spacing
> > >
> > >>(spacing in Y (PixelSpacing[1])) first. Nothing much about DICOM can
> > >
> > > supprise
> > >
> > >>me anymore ...
> > >>
> > >>I was convinced of the opposite, like you, before talking to Bruker
> > >>(and
> > >>checking the standard ;-). Bruker also mentioned that almost nobody uses
> > >>non-isotrope in-plane pixels. Well, we do and you are almost there.
> > >>
> > >>Many thanks again
> > >>
> > >>Uwe
> > >>
> > >>Am Dienstag, 14. Dezember 2004 23:58 schrieben Sie:
> > >>
> > >>
> > >>
> > >>>Hi Uwe,
> > >>>
> > >>>Thanks a lot for your detailed message and for editing
> > >>>the bug in the database.
> > >>>
> > >>>Following your hints, we just added an extra step to the parsing in
> > >>>order to recover the second number in the tag 0028x0030.  We are now
> > >>>searching for the separator and taking the second part of the string.
> > >>>
> > >>>This has been committed to CVS so you can give it a try.
> > >>>
> > >>>We are still unclear regarding the order of the spacing. That is,
> > >>>whether the first value is suppossed to be the spacing in X
> > >>>(PixelSpacing[0]) or the spacing in Y
> > >>>(PixelSpacingg[1])
> > >>>
> > >>>
> > >>>If you have a chance, please give it a try at the CVS version and let
> > >>>us konw what you find.
> > >>>
> > >>>
> > >>>   Thanks
> > >>>
> > >>>
> > >>>
> > >>>      Luis
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>-------------------------
> > >>>
> > >>>Dr. Uwe Kohler wrote:
> > >>>
> > >>>
> > >>>
> > >>>>-----BEGIN PGP SIGNED MESSAGE-----
> > >>>>Hash: SHA1
> > >>>>
> > >>>>Dear Luis,
> > >>>>
> > >>>>I tried to post a comment to the bug, but the system forgot most of
> > >>>>it:
> > >>>>
> > >>>>I have images with non-isotropic in-plane resolution and ITK cannot
> > >>>>interpret the pixel spacing. According to the DICOM standard you do
> > >>>>get the ROW spacing first and then the COL spacing.
> > >>>>
> > >>>>- From the standard:
> > >>>>Physical distance in the patient between the center of each pixel,
> > >>>>specified by a numeric pair - adjacent row spacing (delimiter)
> > >>>>adjacent column spacing in mm.
> > >>>>
> > >>>>I also seem to get rounding errors, however I can live with those. I
> > >>>>just cannot fix the DICOM code  if (len > 0)
> > >>>>   {
> > >>>>   fval = DICOMFile::ReturnAsFloat(val,
> > >>>>parser->GetDICOMFile()->GetPlatformIsBigEndian());
> > >>>>   }
> > >>>>
> > >>>> if (group == 0x0028 && element == 0x0030)
> > >>>>   {
> > >>>>   this->PixelSpacing[0] = this->PixelSpacing[1] = fval;
> > >>>>   }
> > >>>> else if (group == 0x0018 && element == 0x0050)
> > >>>>   {
> > >>>>   this->PixelSpacing[2] = fval;
> > >>>>   }
> > >>>>
> > >>>>since val should have more than one value. Could you fix that?
> > >>>>
> > >>>>Cheers
> > >>>>
> > >>>>Uwe
> > >>>>- --
> > >>>>
> > >>>>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Insight-users mailing list
> > > Insight-users at itk.org
> > > http://www.itk.org/mailman/listinfo/insight-users
> > > _______________________________________________
> > > Insight-users mailing list
> > > Insight-users at itk.org
> > > http://www.itk.org/mailman/listinfo/insight-users
> > >
> > 
> > _______________________________________________
> > Insight-users mailing list
> > Insight-users at itk.org http://www.itk.org/mailman/listinfo/insight-users
> > _______________________________________________
> > Insight-users mailing list
> > Insight-users at itk.org
> > http://www.itk.org/mailman/listinfo/insight-users
> >
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users