[ITK] Dicom read error

Fri Jul 7 12:41:45 EDT 2017

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/MediaStorageAndFileFormat/gdcmImageHelper.cxx#L1096-L1161
[2]
https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/ThirdParty/GDCM/src/gdcm/Source/DataStructureAndEncodingDefinition/gdcmMediaStorage.cxx#L520-L585
[3]
https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20170707/e445a0e8/attachment.html>