[Insight-users] Re: Bug 1056

[Li, George (NIH/NCI)]

(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