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

[Luis Ibanez]

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
>>
> 
>