[Insight-developers] image information reset by gradient magnitude filter

Thu Feb 5 12:23:00 EST 2009

MetaDictionary is not currently passed through the pipeline.

I don't think PipelineMonitor should check the image information. The
image information can change (e.g. ShrinkImnage).

Bill

On Thu, Feb 5, 2009 at 12:16 PM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> I have been thinking about adding in some built in methods to
> PipelineMonitorImageFilter to verify that the pipeline has been executed
> normally. If on places the monitor before and after the filter to be tested,
> the two monitors could be told of each other and then verify that the image
> information is as expected.
> Also shouldn't the MetaDictonary also be checked in the SameInformation
> method?
> Brad
>
>
> On Feb 5, 2009, at 11:50 AM, Bill Lorensen wrote:
>
> I guess the advantage of changing the Image class is that if
> additional information is added in the future, then the method in
> image could be changed. However, the types of the two images does not
> need to be the same. That's why I templated the current check over the
> two image types. I guess a dynamic cast to image base would fix this.
> But, a new image subclass might have additional information that would
> need checking.
>
> Maybe we need to think on this a bit.
>
> Bill
>
> On Thu, Feb 5, 2009 at 11:37 AM, Luis Ibanez <luis.ibanez at kitware.com>
> wrote:
>
> It may have been the use of
>
>             TImage::Pointer
>
> without a "typename".
>
> This was replaced with
>
>            const TImage * image
>
> which is more consistent with our standard way
>
> of managing inputs.
>
>
> So, yes, the templated function by itself may not
>
> have been the problem. Due to past (bad) experiences
>
> with VS6, I try to avoid templated functions....
>
> -----
>
> What do you think about moving this class to Common
>
> and expanding it with futher check methods that we
>
> could use from the tests ?
>
> It ties up with the discussion about improving and
>
> simplyfying our testing infrastructure.
>
> Arguably, it could also be a method of the image class.
>
>
>   image1->HasSameInformation( image2 );
>
> although, touching the image class is a higher
>
> proposition... it seem simpler to add a testing
>
> helper class.
>
>
>
>    Luis
>
>
>
> -----------------------
>
> Bill Lorensen wrote:
>
> I'm surprised it didn't compile.  I use templated functions in Slicer3
>
> command line programs frequently. Maybe there was another issue that
>
> caused it to fail.
>
> On Thu, Feb 5, 2009 at 11:21 AM, Luis Ibanez <luis.ibanez at kitware.com>
>
> wrote:
>
> Brad,
>
> That's a great idea.
>
> It will be useful to have a set of basic checking
>
> methods in a central class that we can reuse in
>
> many different tests.
>
>
> BTW: In order to get the check to compile in gcc 4.2
>
>  I converted the templated function into a templated
>
>  class with an static method.
>
> We could take this class out of the test, rename it
>
> to something more general, and add to it more static
>
> check method.
>
> Names that come to mind are:
>
>  * ImageTester
>
>  * ImageChecker
>
>  * ImageComparision
>
> The class should go to a central place, like
>
> Code/Common...
>
>
> Any suggestions/preferences ?
>
>
> Thanks
>
>
>    Luis
>
>
>
> -----------------------------
>
> Bradley Lowekamp wrote:
>
> Hello,
>
> I have a comment about testing.
>
> I am very surprised that Bill had to implement an
>
> ImageInformationIsEqual
>
> function to compare. I had to implement a methods to method to compare
>
> images from memory and files based on the DifferenceImageFilter. It
>
> really
>
> seems like there should be a common place for these kinds of methods (
>
> and
>
> classes like itkPipelineMonitorImageFilter :) And other easy and
>
> standard
>
> ways to verify the execution and output of a pipeline. Has anyone else
>
> noticed that  the standard --compare flag for tests  doesn't verify the
>
> geometry is correct? </gripe>
>
> Brad
>
>
>
> On Feb 5, 2009, at 10:49 AM, Gaëtan Lehmann wrote:
>
>
> Hi,
>
> Le 5 févr. 09 à 16:29, Bill Lorensen a écrit :
>
>
> Luis,
>
> This error has always been present I believe.
>
> I reproduced the problem using CVS HEAD. I modified the filter's test
>
> by adding non-default image information to the test input. Then, after
>
> the filter runs, I compared the input and output image information.
>
> Before my fix, the information differed. You can duplicate the failure
>
> with my new test, if you comment out my fix (one line) and re-run the
>
> test.
>
> This filter creates an internal image to accumulate results over each
>
> dimension. Since the internal image never copied the image information
>
> from the input image, the internal image had default settings for the
>
> information. This internal image was used as the input to a mini
>
> pipeline. The output of the internal mini-pipeline is grafted onto the
>
> output of the filter.
>
>
> This design has not always been there. I have introduced it to add the
>
> multithreading support.
>
>
>
> http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/BasicFilters/itkGradientMagnitudeRecursiveGaussianImageFilter.txx?root=Insight&r1=1.18&r2=1.19
>
> <http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/BasicFilters/itkGradientMagnitudeRecursiveGaussianImageFilter.txx?root=Insight&r1=1.18&r2=1.19>
>
> The changes looked quite simple and not dangerous to me. The lack of
>
> failing test has comforted me in that opinion.
>
> That bug show that I was wrong.
>
> My apologies for that bug.
>
> Gaëtan
>
>
> --
>
> Gaëtan Lehmann
>
> Biologie du Développement et de la Reproduction
>
> INRA de Jouy-en-Josas (France)
>
> tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
>
> http://voxel.jouy.inra.fr  http://www.mandriva.org
>
> http://www.itk.org  http://www.clavier-dvorak.org
>
> <PGP.sig><ATT00001.txt>
>
>
> ========================================================
>
> Bradley Lowekamp
>
> Lockheed Martin Contractor for
>
> Office of High Performance Computing and Communications
>
> National Library of Medicine
>
> blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
>
> Insight-developers mailing list
>
> Insight-developers at itk.org
>
> http://www.itk.org/mailman/listinfo/insight-developers
>
> _______________________________________________
>
> Insight-developers mailing list
>
> Insight-developers at itk.org
>
> http://www.itk.org/mailman/listinfo/insight-developers
>
>
>
>
>
> ========================================================
>
> Bradley Lowekamp
>
> Lockheed Martin Contractor for
>
> Office of High Performance Computing and Communications
>
> National Library of Medicine
>
> blowekamp at mail.nih.gov
>
>