[ITK] Dicom read error

Thu Jul 6 16:23:39 EDT 2017

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/20170706/92bd7563/attachment.html>