[ITK] Dicom read error
Ying Wang
neuying at gmail.com
Tue Jul 11 15:11:30 EDT 2017
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/MediaStorageAndFil
>>> eFormat/gdcmImageHelper.cxx#L1096-L1161
>>> [2] https://github.com/InsightSoftwareConsortium/ITK/blob/master
>>> /Modules/ThirdParty/GDCM/src/gdcm/Source/DataStructureAndEn
>>> codingDefinition/gdcmMediaStorage.cxx#L520-L585
>>> [3] https://github.com/InsightSoftwareConsortium/ITK/blob/master
>>> /Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFil
>>> eFormat/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/660b34bc/attachment-0001.html>
More information about the Community
mailing list