[ITK] Dicom read error

Tue Jul 11 16:25:02 EDT 2017

Thank you Ying for the follow-up. I am glad you solved your problem.

On Tue, Jul 11, 2017 at 3:11 PM, Ying Wang <neuying at gmail.com> wrote:

> Hi Francois,
>
> Thanks your help. We have solve the problem. The bug is related
> with SOPClassUID, current we saved as "SecondaryCaptureImageStorage",
> after I changed to "MRImageStorage", the data can load correctly in
> ITK-SNAP.
>
> So, I think ITK must have some restriction on the "
> SecondaryCaptureImageStorage" data, it returned here and failed to read
> the actual image parameters.
>
> Thanks!
>
> Ying
>
> On Fri, Jul 7, 2017 at 4:42 PM, Francois Budin <francois.budin at kitware.com
> > wrote:
>
>> 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/MediaStorageAndFile
>>>> Format/gdcmImageHelper.cxx#L1096-L1161
>>>> [2] https://github.com/InsightSoftwareConsortium/ITK/blob/master
>>>> /Modules/ThirdParty/GDCM/src/gdcm/Source/DataStructureAndEnc
>>>> odingDefinition/gdcmMediaStorage.cxx#L520-L585
>>>> [3] https://github.com/InsightSoftwareConsortium/ITK/blob/master
>>>> /Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFile
>>>> Format/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
>>>
>>
>>
>
>
> --
> 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/20170711/f305d9f7/attachment-0001.html>