[ITK] Invalid read in itkImageIOBase.cxx:167 when setting ImageIO on itkSeriesWriter

[Matt McCormick]

Hi Coert,

Yes, it is quite a tricky bug, but I am glad that you came across it, too :-).

The ImageSeriesWriter is in a difficult situation for DICOM.  It is
going from, e.g., a 3D image to a series of 2D images.  It has to
supplement the 2D writer with 3D metadata if GDCMImageIO is going to
use that information.  Note that the type of the ImageFileWriter used
internally to ImageSeriesWriter in this case is a 2D writer.

Thanks,
Matt

On Sat, Apr 12, 2014 at 3:41 AM, Coert Metz <c.metz at quantib.com> wrote:
> Hi Matt,
>
> In line 354 of itkImageSeriesWriter.hxx, the inputImageDimension is
> encapsulated in the dictionary of the ImageIO object. This ImageIO object is
> set in the slice writer at line 304. When writing the slice, the
> itkGDCMImageIO.cxx file reads this dimension again from the ImageIO object
> at line 707 and resizes the direction matrix according to this dimension
> (line 711).
>
> Hope this helps somewhat. It also took us approximately a day to track down
> the issue :).
>
> Regards,
> Coert
>
>
> On Fri, Apr 11, 2014 at 10:11 PM, Matt McCormick
> <matt.mccormick at kitware.com> wrote:
>>
>> Hi Coert,
>>
>> I am having a hard time following -- which file/line numbers are is
>> the input image in the ImageIO object?
>>
>> Thanks,
>> Matt
>>
>> On Fri, Apr 11, 2014 at 4:01 PM, Coert Metz <c.metz at quantib.com> wrote:
>> > Dear Matt,
>> >
>> > Thanks for your reply. I see that the fix consists of changing the loop
>> > condition at line 166 of itkImageIOBase.cxx. The thing I still do not
>> > understand is why the itkImageSeriesWriter is setting the input image in
>> > the
>> > ImageIO object. It seems to me that the actual problem lies there, but I
>> > might be wrong. Can you explain this?
>> >
>> > Kind regards,
>> > Coert Metz
>> >
>> >
>> > On Fri, Apr 11, 2014 at 5:33 PM, Matt McCormick
>> > <matt.mccormick at kitware.com>
>> > wrote:
>> >>
>> >> Hi Coert,
>> >>
>> >> Thank you for you detailed description of the issue and discussing it
>> >> with the community.
>> >>
>> >> This bug has been around for quite some time, but it was discovered
>> >> and fixed [1] recently when improving test coverage.
>> >>
>> >> The fix is available in the v4.5.2 release.
>> >>
>> >> Thanks,
>> >> Matt
>> >>
>> >> [1]
>> >>
>> >> http://itk.org/gitweb?p=ITK.git;a=commit;h=895c6fb83f0670e8464d11a023043639f399ea55
>> >>
>> >> On Fri, Apr 11, 2014 at 11:21 AM, Coert Metz <c.metz at quantib.com>
>> >> wrote:
>> >> > Dear ITK developers,
>> >> >
>> >> > We think we have spotted a bug in the itkImageSeriesWriter which is
>> >> > causing
>> >> > a valgrind warning. The valgrind warning is the following:
>> >> >
>> >> > ====================
>> >> > 0xB3D961: itk::ImageIOBase::SetDirection(unsigned int,
>> >> > vnl_vector<double>
>> >> > const&) (itkImageIOBase.cxx:167)
>> >> > 0x680501: itk::ImageFileWriter<itk::Image<short, 2u> >::Write()
>> >> > (itkImageFileWriter.hxx:223)
>> >> > 0x67739A: itk::ImageFileWriter<itk::Image<short, 2u> >::Update()
>> >> > (itkImageFileWriter.h:166)
>> >> > 0x684673: itk::ImageSeriesWriter<itk::Image<float, 3u>,
>> >> > itk::Image<short,
>> >> > 2u> >::WriteFiles() (itkImageSeriesWriter.hxx:372)
>> >> > 0x684A44: itk::ImageSeriesWriter<itk::Image<float, 3u>,
>> >> > itk::Image<short,
>> >> > 2u> >::GenerateData() (itkImageSeriesWriter.hxx:178)
>> >> > 0x68A1D2: itk::ImageSeriesWriter<itk::Image<float, 3u>,
>> >> > itk::Image<short,
>> >> > 2u> >::Write() (itkImageSeriesWriter.hxx:105)
>> >> > 0x677178: itk::ImageSeriesWriter<itk::Image<float, 3u>,
>> >> > itk::Image<short,
>> >> > 2u> >::Update() (itkImageSeriesWriter.h:138)
>> >> > ====================
>> >> >
>> >> > We are using ITK 4.5.
>> >> >
>> >> > The code we use basically boils down to:
>> >> >
>> >> > ====================
>> >> > // Create GDCM Image IO object.
>> >> > typedef itk::GDCMImageIO ImageIOType;
>> >> > ImageIOType::Pointer gdcm_io = ImageIOType::New();
>> >> >
>> >> > // Set Image Type tag.
>> >> > itk::MetaDataDictionary& dictionary =
>> >> > gdcm_io->GetMetaDataDictionary();
>> >> > std::string tagkey, value;
>> >> > tagkey = "0008|0008";  // Image Type
>> >> > value = "DERIVED\\SECONDARY";
>> >> > itk::EncapsulateMetaData<std::string>(dictionary, tagkey, value);
>> >> >
>> >> > // Write DICOM series.
>> >> > typename SeriesWriterType::Pointer writer = SeriesWriterType::New();
>> >> > writer->SetInput(quantib_to_itk);
>> >> > writer->SetImageIO(gdcm_io);
>> >> > writer->SetFileNames(...filenames...);
>> >> > writer->Update();
>> >> > ====================
>> >> >
>> >> > We have tracked down the issue to the following:
>> >> >
>> >> > As set the ImageIO object explicitly, the code at line 354 of
>> >> > itkImageSeriesWriter.hxx is executed:
>> >> >
>> >> > ====================
>> >> > EncapsulateMetaData<  unsigned int   >(dictionary,
>> >> > ITK_NumberOfDimensions,
>> >> > inputImageDimension);
>> >> > ====================
>> >> >
>> >> > This explicitly sets the number of image dimensions of the dictionary
>> >> > input
>> >> > image in the ImageIO instance. In this case we have a 3D image and
>> >> > write
>> >> > 2D
>> >> > slices, so 3 will be set in the ImageIO instance dictionary and
>> >> > passed
>> >> > to
>> >> > the itkImageFileWriter when writing the 2D slices. The
>> >> > itkImageFileWriter
>> >> > reads the ITK_NumberOfDimensions tag from the dictionary to set the
>> >> > size
>> >> > of,
>> >> > among others, the direction matrix (line 704 of itkGDCMImageIO.cxx).
>> >> > This
>> >> > will in the end result in reading an invalid memory location in
>> >> > itkImageIOBase at line 167, which loops over 3 dimensions while it
>> >> > should
>> >> > loop over 2 dimensions. The code at line 356-368 also seems strange
>> >> > to
>> >> > me,
>> >> > as the direction matrix should be 2x2, I think.
>> >> >
>> >> > Maybe we are overlooking something, so I am curious if this is a real
>> >> > bug,
>> >> > or that we maybe use the writer and the ImageIO object in the wrong
>> >> > way.
>> >> > Curious for your insights.
>> >> > --
>> >> > Coert Metz, PhD
>> >> > Research & Development Engineer  |  Quantib B.V.
>> >> > c.metz at quantib.com  |  +31 650 68 60 28
>> >> >
>> >> > This message may contain confidential or privileged information. If
>> >> > you
>> >> > are
>> >> > not the addressee, please return the message to its sender and delete
>> >> > it
>> >> > from your files.
>> >> > _______________________________________________
>> >> > Community mailing list
>> >> > Community at itk.org
>> >> > http://public.kitware.com/cgi-bin/mailman/listinfo/community
>> >> >
>> >
>> >
>> >
>> >
>> > --
>> > Coert Metz, PhD
>> > Research & Development Engineer  |  Quantib B.V.
>> > c.metz at quantib.com  |  +31 650 68 60 28
>> >
>> > This message may contain confidential or privileged information. If you
>> > are
>> > not the addressee, please return the message to its sender and delete it
>> > from your files.
>
>
>
>
> --
> Coert Metz, PhD
> Research & Development Engineer  |  Quantib B.V.
> c.metz at quantib.com  |  +31 650 68 60 28
>
> This message may contain confidential or privileged information. If you are
> not the addressee, please return the message to its sender and delete it
> from your files.