[Insight-users] Re: Bug 1056

[Miller, James V (Research)]

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