[ITK] Dicom read error

[Francois Budin]

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