[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dicom support
From: |
Andy Buckle |
Subject: |
Re: dicom support |
Date: |
Sun, 2 May 2010 21:45:16 +0100 |
Thanks, I did mean DS. My implementation gets that right now. (I hope
to have something to share in a few days).
Another request for help:
I hope to implement dicomwrite too. I am not sure there is an easy and
sane way to get back from a name (eg PatientsName) to a tag (eg
0x10,0x10). Any ideas appreciated. I am not too hot at c++, so I may
be missing something in the GDCM doxygen.
Thanks,
Andy
BTW, I switched from the offis dcmdump to the gdcm gdcmdump recently.
It seems to be much faster.
On Sun, May 2, 2010 at 8:12 PM, Judd Storrs <address@hidden> wrote:
> On Sun, May 2, 2010 at 6:52 AM, Andy Buckle <address@hidden> wrote:
>> Also, there are these odd dicom variable representations that store
>> numbers in strings. I don't know if matlab gives them as char arrays,
>> or parses them to arrays of doubles.
>
> I think you are referring to the DS (Decimal String) value
> representation? I did some tests using this DICOM file:
> http://barre.nom.fr/medical/samples/files/MR-MONO2-16-head.gz
>
> Here, I just verify that SpatialResolution is DS using dcmdump from dcmtk:
>
> $ dcmdump +P SpatialResolution MR-MONO2-16-head
> (0018,1050) DS [1.145833\0.859375] # 18, 2
> SpatialResolution
> $ grep "1\.145833.0\.859375" MR-MONO2-16-head
> Binary file MR-MONO2-16-head matches
>
> In matlab SpatialResolution is loaded as a 2x1 double vector:
>
>>> dcm = dicominfo('MR-MONO2-16-head') ;
>>> dcm.SpatialResolution
>
> ans =
>
> 1.1458
> 0.8594
>
>>> class(dcm.SpatialResolution)
>
> ans =
>
> double
>
>
>
> --judd
>
--
/* andy buckle */
- dicom support, Andy Buckle, 2010/05/02
- Re: dicom support, Judd Storrs, 2010/05/02
- Re: dicom support, Judd Storrs, 2010/05/02
- Re: dicom support,
Andy Buckle <=
- Re: dicom support, Judd Storrs, 2010/05/02
- Re: dicom support, Judd Storrs, 2010/05/02
- Re: dicom support, Andy Buckle, 2010/05/03
- Message not available
- Re: dicom support, Judd Storrs, 2010/05/03
- Re: dicom support, Andy Buckle, 2010/05/03
- Re: dicom support, Søren Hauberg, 2010/05/03