[ITK-users] [ITK] itk Python: origin of DICOM slice does not change

Tue Sep 20 13:03:26 EDT 2016

Hi Fabio,

In the example, a 3D non-DICOM is written to the output (e.g. NRRD).
Your code must have something different if it is writing 2D DICOM
files. DicomImageReadWrite is also deprecated [1].

DICOM writing support in ITK could be improved. It is recommended to
write to other output formats.

HTH,
Matt

[1] https://github.com/InsightSoftwareConsortium/ITK/blob/077527e86d96daf88663fda6bf7abeb1e92b9d9d/Examples/IO/DicomSeriesReadImageWrite.cxx#L22-L28

On Tue, Sep 20, 2016 at 10:26 AM, D'Isidoro  Fabio <fisidoro at ethz.ch> wrote:
> Hi,
>
> I tried this
>
> ImageIOType = itk.GDCMImageIO
> gdcmImageIO = ImageIOType.New()
> reader.SetImageIO(gdcmImageIO)
> reader.Update()
>
> ...
>
> writer_output.SetInput(filter.GetOutput())
> writer_output.UseInputMetaDataDictionaryOff()
> gdcmImageIO_output = ImageIOType.New()
> writer_output.SetImageIO(gdcmImageIO_output)
>
> but the written DICOM image has default origin (0,0) mm and default spacing (1., 1.).
>
> Also, the example "DicomImageReadWrite" too does not create a new instance of the gdcmImageIO.
>
>
>
>
> -----Original Message-----
> From: Matt McCormick [mailto:matt.mccormick at kitware.com]
> Sent: Dienstag, 20. September 2016 16:03
> To: D'Isidoro Fabio
> Cc: Dženan Zukić; insight-users at itk.org; Timothee Evain
> Subject: Re: [ITK-users] [ITK] itk Python: origin of DICOM slice does not change
>
> Hi Fabio,
>
> Also, if
>
>   writer_output.SetImageIO(gdcmImageIO)
>
> is called, and gdcmImageIO is being re-used, then gdcmImageIO will re-use its MetaDataDictionary. So a new instance of GDCMImageIO shoulrd be passed to avoid using the old MetaDataDictionary.
>
> HTH,
> Matt
>
> On Tue, Sep 20, 2016 at 9:14 AM, Matt McCormick <matt.mccormick at kitware.com> wrote:
>> Hi Fabio,
>>
>> As suggested by Tim, call  ->UseInputMetaDataDictionaryOff() to use
>> the Origin from the itk::Image. The MetaDataDictionary tags will
>> indicate an Origin that is not correct.
>>
>> HTH,
>> Matt
>>
>> On Tue, Sep 20, 2016 at 9:06 AM, D'Isidoro  Fabio <fisidoro at ethz.ch> wrote:
>>> Hi,
>>>
>>>
>>>
>>> It doesn’t work.
>>>
>>>
>>>
>>> Filter.GetOuput() already has the new origin (I can print it and it’s
>>> right). Something wrong is in the writing process.
>>>
>>>
>>>
>>> By the way, I noticed this problem occurs for change of the origin
>>> and of rescaling intensities. It does not occur for changes in size and spacing.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Fabio
>>>
>>>
>>>
>>> From: Dženan Zukić [mailto:dzenanz at gmail.com]
>>> Sent: Dienstag, 20. September 2016 14:46
>>> To: D'Isidoro Fabio
>>> Cc: Timothee Evain; insight-users at itk.org
>>> Subject: Re: [ITK-users] [ITK] itk Python: origin of DICOM slice does
>>> not change
>>>
>>>
>>>
>>> Hi Fabio,
>>>
>>>
>>>
>>> did you try setting the origin directly on the result image:
>>>
>>> filter->Update();
>>>
>>> outImage=filter->GetOutput();
>>>
>>> outImage->SetOrigin(new_origin);
>>>
>>> writer_output->SetInput(outImage);
>>>
>>>
>>>
>>> Regards,
>>>
>>> Dženan
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Sep 20, 2016 at 8:34 AM, D'Isidoro Fabio <fisidoro at ethz.ch> wrote:
>>>
>>> Hi,
>>>
>>> I am currently using the command:
>>>
>>> writer_output.UseInputMetaDataDictionaryOff()
>>>
>>> If I don't use it, the image is saved with default origin (0,0) mm
>>> and default spacing (1., 1.).
>>>
>>> According to the manual for UseInputMetaDataDictionaryOff(), "this
>>> flag defines whether the MetaDataDictionary to use will be the one
>>> from the input image or the one already set in the ImageIO object."
>>> My understanding is that if I set it off, the DICOM slice will be
>>> written with current values (and not the input values), which is what
>>> I want. But this seems not to happen.
>>>
>>> Relevant parts of my code:
>>>
>>> filter.SetOutputOrigin( new_origin )
>>> writer_output.SetInput(filter.GetOutput())
>>> writer_output.UseInputMetaDataDictionaryOff()
>>> writer_output.SetImageIO(gdcmImageIO)
>>> writer_output.Update()
>>>
>>> Maybe the function UseInputMetaDataDictionaryOff() does not work
>>> properly for the itk with Python wrapping?
>>>
>>> Thanks for your answer.
>>>
>>> Fabio.
>>>
>>>
>>> -----Original Message-----
>>> From: Timothee Evain [mailto:tevain at telecom-paristech.fr]
>>> Sent: Dienstag, 20. September 2016 10:35
>>> To: D'Isidoro Fabio
>>> Cc: insight-users at itk.org
>>> Subject: Re: [ITK] [ITK-users] itk Python: origin of DICOM slice does
>>> not change
>>>
>>> Hi,
>>>
>>> You refer to the DICOMImageReadWrite example. If you don't change the
>>> writing part, I think your problem comes from the fact that you
>>> assign the read metadata directly to the output (
>>> ->UseInputMetaDataDictionaryOff() ) so the original origin will be saved.
>>>
>>> HTH,
>>>
>>> Tim
>>>
>>> ----- Mail original -----
>>> De: "D'Isidoro Fabio" <fisidoro at ethz.ch>
>>> À: insight-users at itk.org
>>> Envoyé: Lundi 19 Septembre 2016 22:09:39
>>> Objet: [ITK] [ITK-users] itk Python: origin of DICOM slice does not
>>> change
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> Following the code ResampleImageFilter2.cxx, I am applying an
>>> Identity Transform to a single DICOM slice, I change the origin to
>>>
>>>
>>>
>>> output_origin = reader.GetOutput().GetOrigin() + offset
>>>
>>>
>>>
>>> and I write the transformed DICOM slice into a new DICOM slice
>>> (following the code DICOMImageReadAndWrite.cxx).
>>>
>>>
>>>
>>> I visualize the written DICOM slice with a viewer (it’s an itk-vtk
>>> segmentation software).
>>>
>>>
>>>
>>> The transformed DICOM slice looks as it should. Surprisingly however
>>> the viewer shows the original input values as origin. This is
>>> confirmed by the fact that if I read with an itk script the written
>>> DICOM slice again, and I print the information of the DICOM slice,
>>> the origin is still the original one and not the modified one.
>>>
>>>
>>>
>>> How could this be?
>>>
>>>
>>>
>>> Original DICOM slice:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Transformed DICOM slice:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Thank you for help,
>>>
>>>
>>>
>>> Fabio.
>>>
>>> _____________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://www.kitware.com/products/protraining.php
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/insight-users
>>>
>>> _______________________________________________
>>> Community mailing list
>>> Community at itk.org
>>> http://public.kitware.com/mailman/listinfo/community
>>> _____________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://www.kitware.com/products/protraining.php
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/insight-users
>>>
>>>
>>>
>>>
>>> _____________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://www.kitware.com/products/protraining.php
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/insight-users
>>>