[ITK] Dicom read error

Thu Jul 6 16:18:47 EDT 2017

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20170706/1b9d9cd9/attachment-0001.html>