[ITK] Dicom read error

Thu Jul 6 19:40:00 EDT 2017

According to the itkGDCMSeriesFileNames documentation, file names
should not affect the order of the slices if image position patient
and image position orientation are present.
We use 0020|0032 for image position patient
and 0020|0037 for image orientation.

/** \class GDCMSeriesFileNames
 * \brief Generate a sequence of filenames from a DICOM series.
 *
 * This class generates a sequence of files whose filenames point to
 * a DICOM file. The ordering is based on the following strategy:
 * Read all images in the directory (assuming there is only one study/series)
 *
 *   1. Extract Image Orientation & Image Position from DICOM images, and then
 *      calculate the ordering based on the 3D coordinate of the slice.
 *   2. If for some reason this information is not found or failed, another
 *      strategy is used: the ordering is based on 'Image Number'.
 *   3. If this strategy also failed, then the filenames are ordered by
 *      lexicographical order.
 *
 *  If multiple volumes are being grouped as a single series for your
 *    DICOM objects, you may want to try calling SetUseSeriesDetails(true)
 *    prior to calling SetDirectory().

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 is 0.5x0.5x1 mm^3
>>>>> which is collapsed to a dataset of  1x1x2 mm^3.
>>>>>
>>>>> 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

-- 
Unpaid intern in BillsBasement at noware dot com