[Insight-users] Description: itk::ERROR: MattesMutualInformationImageToImageMetric(0x1db9020): Joint PDF summed to zero

Luis Ibanez luis.ibanez at kitware.com
Fri Oct 9 13:41:02 EDT 2009


Hi John,

Thanks for the clarification.

That makes a lot of sense.


      Luis


--------------------------------------------------------
On Fri, Oct 9, 2009 at 1:28 PM, John Drozd <john.drozd at gmail.com> wrote:
> Hi Luis,
>
> I am using 3D Slicer to view the images.  Bill Lorensen on your mailing list
> emailed me that 3D Slicer does view the orientation of dicom files
> correctly.  I am developing code for clinical purposes for developing
> software to detect the early onset of Alzheimer's disease in people, by
> measuring changes in ventricle and hippocampal volumes, intracranial
> volumes, and quantifying amyloid plaques.
> A couple days ago I wrote a program that read in a dicom series from The
> Alzheimer's Disease Neuroimaging Inititative (ADNI) database and wrote out a
> dicom volume of the same unaltered series. When I turned off the meta data
> dictionary, then the outputted volume when viewed in 3D Slicer was fine
> (i.e., not flipped, ie., in the radiologist view), but when I do not turn
> off the meta data dictionary, then the outputted volume is flipped (i.e., in
> the neurologist view) when viewed in 3D Slicer. I got the idea to turn off
> the meta data dictionary from the ITK Software Guide's discussion of
> Examples/IO/DicomImageReadWrite.cxx (at the bottom of page 291 of the ITK
> Software Guide book that I purchased from Kitware).
>
> thanks,
> john
>
> On Fri, Oct 9, 2009 at 1:11 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>>
>> Hi John,
>>
>> The .mhd extensions are not required. However, ITK expects "some"
>> extension in the filename, since the IO factory uses the filename
>> extension  to select the actual ImageIO class that will be used for
>> saving the file.
>>
>> It is interesting (and maybe suspicious) that the image is appearing
>> flipped when you turn off the meta data dictionary.
>>
>> You may want to double check on what is the correct behavior,
>> specially if you are developing code for clinical purposes.
>>
>> What program are you using as a Image Viewer for verifying
>> the orientation of the images ?
>>
>>
>>   Please let us know,
>>
>>
>>        Thanks
>>
>>
>>          Luis
>>
>>
>> ----------------------------------------------
>> On Fri, Oct 9, 2009 at 12:40 PM, John Drozd <john.drozd at gmail.com> wrote:
>> > Hi Luis (again),
>> >
>> > Also, I forgot to mention that also this time I used ".mhd" extensions
>> > on
>> > the output files.  I did not know that extensions were required.  BTW,
>> > if I
>> > used a .dcm extension for the output files, I had to set the writer to:
>> > writer->UseInputMetaDataDictionaryOff(), otherwise the images came out
>> > flipped.  Maybe it's because my original input files were dicom series.
>> >
>> > thanks again,
>> > john
>> >
>> > On Fri, Oct 9, 2009 at 12:35 PM, John Drozd <john.drozd at gmail.com>
>> > wrote:
>> >>
>> >> Hi Luis,
>> >>
>> >> Thank you very much for your help.  The images were not overlapping
>> >> because my two images were too different. One image was ours and the
>> >> other I
>> >> got from the internet from a 3D Slicer workshop.  This time, I used
>> >> dicom
>> >> series from two different brain subjects that were from the same
>> >> database.
>> >> These subjects wer from two different people.  This time, the
>> >> DeformableRegistration8.cxx  program was able to successfully register
>> >> them.
>> >>
>> >> thanks again,
>> >> john
>> >>
>> >> On Thu, Oct 8, 2009 at 9:08 PM, Luis Ibanez <luis.ibanez at kitware.com>
>> >> wrote:
>> >>>
>> >>> Hi John,
>> >>>
>> >>> Typical suspects are:
>> >>>
>> >>> 1) Your readers are failing to load the DICOM images correctly.
>> >>>
>> >>> 2) The images intensities are not interpreted correctly.
>> >>>
>> >>> 3) The images are not overlapping with the current parameters
>> >>>    of the transform.
>> >>>
>> >>>
>> >>> I would suggest you to test for (1) and (2) first.
>> >>>
>> >>>
>> >>> This can easily be done by connecting Writers to the two readers
>> >>> that you are using for loading the DICOM images.  Then save
>> >>> those images in a format such as MHD, that can be easily load
>> >>> in many applications (Slicer, VV, ITK-SNAP, VolView, Paraview).
>> >>>
>> >>> BTW, Why is that the other command line arguments do not
>> >>> have extensions ?
>> >>>
>> >>> Are they intended to be directory names ?
>> >>>
>> >>>
>> >>>    Please let us know what you find.
>> >>>
>> >>>
>> >>>          Thanks
>> >>>
>> >>>
>> >>>                 Luis
>> >>>
>> >>>
>> >>> ----------------------------------------------
>> >>> On Thu, Oct 8, 2009 at 6:00 PM, John Drozd <john.drozd at gmail.com>
>> >>> wrote:
>> >>> > Hello,
>> >>> >
>> >>> > I ran DeformableRegistration8.cxx using the following command:
>> >>> > (I altered the reading of files suitable for DICOM)
>> >>> >
>> >>> > ./DeformableRegistration8 subjectout.dcm atlasout.dcm
>> >>> > outputImagefile
>> >>> > differenceOutputfile differenceBeforeRegistration deformationField
>> >>> >
>> >>> > Starting Registration
>> >>> > ExceptionObject caught !
>> >>> >
>> >>> > itk::ExceptionObject (0x4f51fd0)
>> >>> > Location: "void
>> >>> > itk::MattesMutualInformationImageToImageMetric<TFixedImage,
>> >>> > TMovingImage>::GetValueAndDerivative(const typename
>> >>> > itk::ImageToImageMetric<TFixedImage, TMovingImage>::ParametersType&,
>> >>> > typename itk::ImageToImageMetric<TFixedImage,
>> >>> > TMovingImage>::MeasureType&,
>> >>> > typename itk::ImageToImageMetric<TFixedImage,
>> >>> > TMovingImage>::DerivativeType&) const [with TFixedImage =
>> >>> > itk::Image<short
>> >>> > int, 3u>, TMovingImage = itk::Image<short int, 3u>]"
>> >>> > File:
>> >>> >
>> >>> >
>> >>> > /trumpet/downloads/3DSlicer/Slicer3-lib/Insight/Code/Review/itkOptMattesMutualInformationImageToImageMetric.txx
>> >>> > Line: 1034
>> >>> > Description: itk::ERROR:
>> >>> > MattesMutualInformationImageToImageMetric(0x1db9020): Joint PDF
>> >>> > summed
>> >>> > to
>> >>> > zero
>> >>> >
>> >>> > Does anyone know what this error means?
>> >>> >
>> >>> > john
>> >>> >
>> >>> >
>> >>> > On Thu, Oct 8, 2009 at 5:19 PM, John Drozd <john.drozd at gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> Sorry, my oversight. The parameters file was for
>> >>> >> DeformableRegistration1.cxx.
>> >>> >> The parameters file just happened to be listed in the ITK Software
>> >>> >> Guide
>> >>> >> directly after the code listing for DeformableRegistration8.cxx,
>> >>> >> and
>> >>> >> that's
>> >>> >> why I thought a parameter file was needed for
>> >>> >> DeformableRegistration8.cxx.
>> >>> >> Looking at the code for DeformableRegistration8.cxx, I see that
>> >>> >> only a
>> >>> >> fixedImageFile, movingImageFile and outputImageFile are required.
>> >>> >>
>> >>> >> Thanks,
>> >>> >> john
>> >>> >>
>> >>> >> On Thu, Oct 8, 2009 at 3:14 PM, John Drozd <john.drozd at gmail.com>
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> Hello,
>> >>> >>>
>> >>> >>> I have two brain volumes, that I successfully loaded into ITK from
>> >>> >>> two
>> >>> >>> different sets of dicom series, namely,
>> >>> >>>
>> >>> >>> image 1 data: (header info that I obtained when I saved my first
>> >>> >>> volume
>> >>> >>> as a nrrd file in Slicer)
>> >>> >>> type: short
>> >>> >>> dimension: 3
>> >>> >>> space: left-posterior-superior
>> >>> >>> sizes: 256 256 124
>> >>> >>> space directions: (0,0.9375,0) (0,0,-0.9375) (-1.3,0,0)
>> >>> >>> kinds: domain domain domain
>> >>> >>> endian: little
>> >>> >>> encoding: gzip
>> >>> >>> space origin: (-79.9,-125.9,121.8)
>> >>> >>>
>> >>> >>> image 2 data: (header info that I obtained when I saved my second
>> >>> >>> volume
>> >>> >>> as a nrrd file in Slicer)
>> >>> >>> type: unsigned short
>> >>> >>> dimension: 3
>> >>> >>> space: left-posterior-superior
>> >>> >>> sizes: 256 256 166
>> >>> >>> space directions: (0,0,-0.93905) (0,0.93905,0) (1.2024,0,0)
>> >>> >>> kinds: domain domain domain
>> >>> >>> endian: little
>> >>> >>> encoding: gzip
>> >>> >>> space origin: (198.396,-0,-0)
>> >>> >>>
>> >>> >>> I want to use a deformable registration such that I will deform
>> >>> >>> the
>> >>> >>> first
>> >>> >>> image into the the second image.  Because the images will have
>> >>> >>> different
>> >>> >>> modalities, I am planning to use a modified version of either
>> >>> >>> DeformableRegistration8.cxx (which uses
>> >>> >>> itk::BSplineDeformableTransform,
>> >>> >>> itk::MattesMutualInformationImageToImageMetric with the LBFGSB
>> >>> >>> Optimizer).
>> >>> >>> I may also try using DeformableRegistration14.cxx which uses a
>> >>> >>> gradientsteepestdescent optimizer. As a final refinement, maybe a
>> >>> >>> multiresolution scheme of these routines to speed up the
>> >>> >>> computation.
>> >>> >>>
>> >>> >>> I noticed that in the parameter file for
>> >>> >>> DeformableRegistration8.cxx,
>> >>> >>> only one size Nx, Ny, Nz is specified for both images, but my
>> >>> >>> images
>> >>> >>> have
>> >>> >>> different sizes and different space directions, and different
>> >>> >>> space
>> >>> >>> origins
>> >>> >>> as listed in the nrrd headers above for these images.
>> >>> >>>
>> >>> >>> I will try on my own, but I was wondering if someone has some
>> >>> >>> helpful
>> >>> >>> insight or hints as to whether there are many modifications that I
>> >>> >>> have to
>> >>> >>> do, to refine DeformableRegistration8.cxx or
>> >>> >>> DeformableRegistration14.cxx
>> >>> >>> and their associated classes to make this workable for my
>> >>> >>> situation.
>> >>> >>>
>> >>> >>> Any suggestions are welcome.
>> >>> >>>
>> >>> >>> Thank you.
>> >>> >>>
>> >>> >>> john
>> >>> >>>
>> >>> >>> --
>> >>> >>> John Drozd
>> >>> >>> Postdoctoral Fellow
>> >>> >>> Imaging Research Laboratories
>> >>> >>> Robarts Research Institute
>> >>> >>> Room 1256
>> >>> >>> 100 Perth Drive
>> >>> >>> London, Ontario, Canada
>> >>> >>> N6A 5K8
>> >>> >>> (519) 661-2111 ext. 25306
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> John Drozd
>> >>> >> Postdoctoral Fellow
>> >>> >> Imaging Research Laboratories
>> >>> >> Robarts Research Institute
>> >>> >> Room 1256
>> >>> >> 100 Perth Drive
>> >>> >> London, Ontario, Canada
>> >>> >> N6A 5K8
>> >>> >> (519) 661-2111 ext. 25306
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > John Drozd
>> >>> > Postdoctoral Fellow
>> >>> > Imaging Research Laboratories
>> >>> > Robarts Research Institute
>> >>> > Room 1256
>> >>> > 100 Perth Drive
>> >>> > London, Ontario, Canada
>> >>> > N6A 5K8
>> >>> > (519) 661-2111 ext. 25306
>> >>> >
>> >>> > _____________________________________
>> >>> > Powered by www.kitware.com
>> >>> >
>> >>> > Visit other Kitware open-source projects at
>> >>> > http://www.kitware.com/opensource/opensource.html
>> >>> >
>> >>> > 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://www.itk.org/mailman/listinfo/insight-users
>> >>> >
>> >>> >
>> >>
>> >>
>> >>
>> >> --
>> >> John Drozd
>> >> Postdoctoral Fellow
>> >> Imaging Research Laboratories
>> >> Robarts Research Institute
>> >> Room 1256
>> >> 100 Perth Drive
>> >> London, Ontario, Canada
>> >> N6A 5K8
>> >> (519) 661-2111 ext. 25306
>> >
>> >
>> >
>> > --
>> > John Drozd
>> > Postdoctoral Fellow
>> > Imaging Research Laboratories
>> > Robarts Research Institute
>> > Room 1256
>> > 100 Perth Drive
>> > London, Ontario, Canada
>> > N6A 5K8
>> > (519) 661-2111 ext. 25306
>> >
>
>
>
> --
> John Drozd
> Postdoctoral Fellow
> Imaging Research Laboratories
> Robarts Research Institute
> Room 1256
> 100 Perth Drive
> London, Ontario, Canada
> N6A 5K8
> (519) 661-2111 ext. 25306
>


More information about the Insight-users mailing list