[Insight-users] Re: Bug 1056

[Mathieu Malaterre]

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
>