[ITK] Dicom read error
Francois Budin
francois.budin at kitware.com
Fri Jul 7 16:42:43 EDT 2017
Hello Ying,
I do not know why this design was chosen in GDCM (default DICOM library
used in ITK) for this type of MediaStorage. Maybe a DICOM expert can chip
in.
However, you can also use DCMTK by activating Module_ITKDCMTK and
Module_ITKIODCMTK in ITK's CMake configuration and then use
itk::DCMTKImageIO as your image IO.
I was successful reading your resampled DICOM after renaming your images
(1->01, 2->02,...)
Hope this helps,
Francois
On Fri, Jul 7, 2017 at 3:35 PM, Ying Wang <neuying at gmail.com> wrote:
> Thanks for these information!
>
> I have a question about the second dataset, although it is defined as "SecondaryCaptureImageStorage",
> why it use the default value "1" for spacing between slices? We already
> put "2" in tag (0018,0088).
>
> Ying
>
> On Fri, Jul 7, 2017 at 12:41 PM, Francois Budin <
> francois.budin at kitware.com> wrote:
>
>> Hello Ying and Sean,
>>
>> You are correct, you did change the image position of the patient. The
>> spacing is actually computed differently based on what information is
>> provided in the DICOM tags.
>> In your case, the first DICOM you sent (before resampling), the z-spacing
>> is correct only because it is "1". If it had been a different value in your
>> DICOM, ITK (GDCM) would still have
>> set the spacing to the value "1". The image is defined as
>> "MRImageStorage" and it reads the z-spacing in tag 0x0018,0x0088 [1] which
>> is not set. So it sets the default value of "1", which in this
>> case matches what you expect.
>> In the case of the second dataset you sent (after resampling), the image
>> modality is defined as "SecondaryCaptureImageStorage" [2], so it also sets
>> the spacing to the default value "1".
>>
>> As for the order in which the files are read, Bill is correct. The files
>> are ordered by IPP, except if the image modality is
>> "SecondaryCaptureImageStorage". [3]
>>
>> I hope this helps,
>> Francois
>>
>> [1] https://github.com/InsightSoftwareConsortium/ITK/blob/
>> master/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStor
>> ageAndFileFormat/gdcmImageHelper.cxx#L1096-L1161
>> [2] https://github.com/InsightSoftwareConsortium/ITK/blob/
>> master/Modules/ThirdParty/GDCM/src/gdcm/Source/DataStruc
>> tureAndEncodingDefinition/gdcmMediaStorage.cxx#L520-L585
>> [3] https://github.com/InsightSoftwareConsortium/ITK/blob/
>> master/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStor
>> ageAndFileFormat/gdcmImageHelper.cxx#L468-L484
>>
>> On Thu, Jul 6, 2017 at 4:23 PM, Ying Wang <neuying at gmail.com> wrote:
>>
>>> Our function is down-sample/interpolation, to clear the confusion, the
>>> example is down-sample the slice thickness from 1 to 2 mm/pixel.
>>> We use the z orientation and the first slice image position with the
>>> slice thickness to update all the image positions.
>>>
>>> Ying
>>>
>>> On Thu, Jul 6, 2017 at 4:18 PM, Ying Wang <neuying at gmail.com> wrote:
>>>
>>>> Hi Francois,
>>>>
>>>> Does ITK use the tag (0020,0032) to read the image position of patient?
>>>> Actually, we already update this information after the interpolation on
>>>> each of slices.
>>>>
>>>> The original image,
>>>> 1st slice, (0020,0032) DS [-99.730746057061\-117.69366503814\-55.15114060703]
>>>> # 50, 3 ImagePositionPatient
>>>> 2nd slice, (0020,0032) DS [-99.730746057061\-117.56660042109\-54.159246165521]
>>>> # 50, 3 ImagePositionPatient
>>>> That's mean the slice thickness is 1mm/pixel.
>>>>
>>>> While after interpolation, we saved the image,
>>>> 1st slice, (0020,0032) DS [-99.7307\-117.694\-55.1511] #
>>>> 26, 3 ImagePositionPatient
>>>> 2nd slice,(0020,0032) DS [-99.7307\-117.44\-53.1674] #
>>>> 26, 3 ImagePositionPatient
>>>> That's mean the slice thickness is 2mm/pixel.
>>>>
>>>> Does these right? we want to know which tag are you using and we can
>>>> modify our software for writing DICOM. Thanks again!
>>>>
>>>> Ying
>>>>
>>>>
>>>>
>>>> On Thu, Jul 6, 2017 at 4:01 PM, Francois Budin <
>>>> francois.budin at kitware.com> wrote:
>>>>
>>>>> Hello Sean,
>>>>>
>>>>> As Bill said, it is the slice location that is used to compute the
>>>>> image spacing: The average spacing between all slices is computed and sets
>>>>> as your output image interslice spacing.
>>>>> For the order of the files though, it is based on the order in which
>>>>> the files are given to the image reader. Typically, one uses
>>>>> "itk::GDCMSeriesFileNames" and sets an input directory. This will create a
>>>>> list of all the files contained in that directory and these files will be
>>>>> ordered alphabetically. That means that 1.dcm is after 01.dcm, 2.dcm is
>>>>> after 11.dcm, and so on. You can either rename your files to make sure that
>>>>> they are ordered correctly, as you did, or use a customized function to
>>>>> generate your series of files to read that fits your need.
>>>>>
>>>>> Hope this helps,
>>>>> François
>>>>>
>>>>> On Thu, Jul 6, 2017 at 3:42 PM, Sean Sethi <sethisea at gmail.com> wrote:
>>>>>
>>>>>> Hi Bill,
>>>>>>
>>>>>> I shared this information with our developer. We already rewrite
>>>>>> image position in our processed data. Can you please look at the data sets
>>>>>> which I linked?
>>>>>>
>>>>>> And I have to disagree about the display of the image. I attached
>>>>>> image showing ITK's display of dicoms before and after I renamed the
>>>>>> filenames only. You can see the beforehand image where the discontinuities
>>>>>> are in coronal and sagittal view. Those headers should be the same since I
>>>>>> did not change them.
>>>>>>
>>>>>> Sean
>>>>>>
>>>>>> On Thu, Jul 6, 2017 at 2:59 PM, Bill Lorensen <
>>>>>> bill.lorensen at gmail.com> wrote:
>>>>>>
>>>>>>> It's uses the image position patient tag to determine slice
>>>>>>> location. Image spacing is not used. Also, it does not use the name of them
>>>>>>> for ordering. Once again it uses Ipp.
>>>>>>>
>>>>>>> This is common practice in medical image processing software.
>>>>>>>
>>>>>>> Sent from my iPad
>>>>>>>
>>>>>>> On Jul 6, 2017, at 12:11 PM, Sean Sethi <sethisea at gmail.com> wrote:
>>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I am encountering a dicom read issue with data that was processed
>>>>>>> using a collapsing filter by our software. The original data
>>>>>>> <https://www.dropbox.com/s/wsf6rb3edoritj9/02-MPRAGE%20T1.zip?dl=0> is
>>>>>>> 0.5x0.5x1 mm^3 which is collapsed to a dataset of 1x1x2 mm^3.
>>>>>>> <https://www.dropbox.com/s/7f34ahrmho938gb/KCROP1X1X2.zip?dl=0>
>>>>>>>
>>>>>>> The first error that is noticed is the data appear squished axially,
>>>>>>> and the slice thickness is incorrectly read, even though the header file
>>>>>>> has the correct information. (slice thickness=2, spacing between slices=2).
>>>>>>>
>>>>>>> The second error that I see is due to it incorrectly reading the
>>>>>>> numbering of the dicoms. It shows every 11th or so image as out of order,
>>>>>>> which is coming from reading the numbers in order of 1, 10, 11, 12 etc
>>>>>>> instead of 1, 2,3. When the files are number 01, 02, 03, the issue is
>>>>>>> corrected, but image still appears squashed.
>>>>>>>
>>>>>>> Both the issues are also corrected when the collapsed data is
>>>>>>> converted to NIFTI. So my question is how should we write our DICOM files
>>>>>>> so they are read correctly? Are the thicknesses and spacings computed from
>>>>>>> other tag(s)?
>>>>>>>
>>>>>>> Thank you for consideration,
>>>>>>>
>>>>>>> Sean
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sean Sethi, M.S.
>>>>>>> Research, The MRI Institute for Biomedical Research
>>>>>>> Data processing, Magnetic Resonance Innovations, Inc.
>>>>>>> 440 East Ferry Street, Unit #1
>>>>>>> Detroit, MI 48202
>>>>>>> (313) 758-0065 - Tel
>>>>>>> (313) 758-0068 - Fax
>>>>>>> sethisea at gmail.com
>>>>>>> http://www.mrimaging.com/
>>>>>>> http://www.mrinnovations.com
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Community mailing list
>>>>>>> Community at itk.org
>>>>>>> http://public.kitware.com/mailman/listinfo/community
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sean Sethi, M.S.
>>>>>> Research, The MRI Institute for Biomedical Research
>>>>>> Data processing, Magnetic Resonance Innovations, Inc.
>>>>>> 440 East Ferry Street, Unit #1
>>>>>> Detroit, MI 48202
>>>>>> (313) 758-0065 - Tel
>>>>>> (313) 758-0068 - Fax
>>>>>> sethisea at gmail.com
>>>>>> http://www.mrimaging.com/
>>>>>> http://www.mrinnovations.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> Community mailing list
>>>>>> Community at itk.org
>>>>>> http://public.kitware.com/mailman/listinfo/community
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Ying Wang
>>>> Research Assistant
>>>> Department of Biomedical Engineering
>>>> Wayne State University
>>>>
>>>> 440 East Ferry Street
>>>> Detroit, MI 48202
>>>> 313-758-0065 - Tel Ext: 30
>>>> 313-758-0068 - Fax
>>>> neuying at gmail.com - Email
>>>>
>>>
>>>
>>>
>>> --
>>> Ying Wang
>>> Research Assistant
>>> Department of Biomedical Engineering
>>> Wayne State University
>>>
>>> 440 East Ferry Street
>>> Detroit, MI 48202
>>> 313-758-0065 - Tel Ext: 30
>>> 313-758-0068 - Fax
>>> neuying at gmail.com - Email
>>>
>>
>>
>
>
> --
> Ying Wang
> Research Assistant
> Department of Biomedical Engineering
> Wayne State University
>
> 440 East Ferry Street
> Detroit, MI 48202
> 313-758-0065 - Tel Ext: 30
> 313-758-0068 - Fax
> neuying at gmail.com - Email
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20170707/6b596e8a/attachment-0001.html>
More information about the Community
mailing list