[Insight-users] Re: Bug 1056

[Mark Wyszomierski]

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
>