[Insight-users] One error and one issue with itkImagePCAShapeModelEstimator
Luis Ibanez
luis.ibanez@kitware.com
Sat May 15 05:06:06 EDT 2004
Hi Zach,
If you are throwing exceptions during the process of the
pipeline negotiation, those exception get caught by a
superclass of the filters, probably by the ProcessObject.
This is necessary because the pipeline must be reset
before attempting to run it again.
Jim, will be in a better position for giving you details
on the intermediate catch for exceptions and the
policy for reseting the pipeline.
Regards,
Luis
------------------
Zachary Pincus wrote:
> Luis,
>
> (1) I'll put together a patch for this later tonight. I've got it
> working already, but it's a bit of a mess. One question: in the
> GenerateInputRequestedRegion method, of an ImageToImageFilter subclass,
> MUST Superclass::GenerateInputRequestedRegion be called?
>
> Calling it causes some problems that I have to undo later in the
> PCAShapeModelEstimator's implementation of that method. If It needn't be
> called, great. If however, some bookkeeping gets done somewhere up the
> chain, I'll keep the call in there and just fix the damage.
>
> (2) No offense about the compiler bugs for gcc/darwin/ppc -- it's being
> modified at a rapid rate, and we all know what that does for the bug count.
>
> Anyhow, I just recompiled a recent CVS checkout of ITK (from scratch in
> a new directory, on a new machine with a fresh dev tools install, no
> less...) with static libraries and ran my test code again. (code
> attached) Again, the exception is not caught. However, the backtrace is
> less broken. (included below).
>
> Interestingly enough, if I comment out lines 145 and 146 of
> itkImagePCAShapeModelEstimator.txx, then an exception gets raised -- and
> caught properly -- in some code elsewhere.
> If I fix this problem by further commenting out lines 121 and 151 (see 1
> above), the test runs properly.
> If I try to throw an exception elsewhere in the "negotiation" code
> (GenerateInputRequestedRegion, EnlargeOutputRequestedRegion), the
> exception is not caught. If I try to throw an exception elsewhere in the
> code (e.g. GenerateData), this exception gets caught properly.
>
> Strange. Does the provided test code work right on other platforms?
>
> Zach
>
>
> Backtrace for provided code:
> (gdb) run
> Starting program: /Users/zpincus/Developer/Code/PCACalc/pcatest
> Reading symbols for shared libraries . done
>
> Program received signal SIGABRT, Aborted.
> 0x90042aac in kill ()
> (gdb) where
> #0 0x90042aac in kill ()
> #1 0x9009ec5c in abort ()
> #2 0x000843e4 in __cxxabiv1::__terminate(void (*)()) () at
> /Users/zpincus/Developer/ITK-CVS-src/Insight/Code/Common/itkImage.h:89
> #3 0x00084428 in std::terminate() () at
> /Users/zpincus/Developer/ITK-CVS-src/Insight/Code/Common/itkImage.h:89
> #4 0x00084440 in __cxxabiv1::__unexpected(void (*)()) () at
> /Users/zpincus/Developer/ITK-CVS-src/Insight/Code/Common/itkImage.h:89
> #5 0x0005a5c4 in __cxa_call_unexpected () at
> /Users/zpincus/Developer/ITK-CVS-src/Insight/Code/Common/itkImage.h:89
> #6 0x0000590c in itk::DataObject::PropagateRequestedRegion() () at
> /Users/zpincus/Developer/ITK-CVS-src/Insight/Code/Common/itkImage.h:89
> #7 0x000054a0 in itk::DataObject::Update() () at
> /Users/zpincus/Developer/ITK-CVS-src/Insight/Code/Common/itkImage.h:89
> #8 0x0000a9c0 in itk::ProcessObject::Update() () at
> /Users/zpincus/Developer/ITK-CVS-src/Insight/Code/Common/itkImage.h:89
> #9 0x00003258 in main () at
> /Users/zpincus/Developer/Code/PCACalc/pcatest.cxx:129
>
>
>
>
> On May 13, 2004, at 12:59 PM, Luis Ibanez wrote:
>
>>
>> Hi Zach,
>>
>>
>>
>> 1) It seems reasonable to allow the ImagePCAShapeModelEstimator
>> to accept images of different origin, different StartIndex
>> and only enforce the pixel spacing and the image size (in
>> pixel along every dimension) to be the same among all the
>> input images.
>>
>> Please send us a patch...
>>
>>
>>
>> 2) It is strange what you report regarding the exception...
>>
>> It may look like a missmatch between the version of your
>> compiler and the version of the debugger...
>>
>> No offense, ... but the Mac have proven to have many
>> compiler bugs in the past...
>>
>>
>> Just out of curiosity: Have you tried this same test
>> by builng ITK in static libraries ?
>>
>>
>>
>> Regards,
>>
>>
>>
>> Luis
>>
>>
>> ---------------------
>> Zachary Pincus wrote:
>>
>>> Hello,
>>> I've run into a problematic situation: I want to estimate a PCA model
>>> of several regions (same size) from the same image. I just run an
>>> ExtractImageFilter a few times to get a bunch of sub-images, and feed
>>> them to the model estimator. This should be no problem, but:
>>> (1) itk::ImagePCAShapeModelEstimator will not accept images with
>>> different LargestPossibleRegions, regardless of whether they are the
>>> same size. This seems unnecessarily restrictive to me. If others
>>> agree, I'll happily submit a patch to remedy this behavior.
>>> The more problematic thing is that I had a really hard time tracking
>>> down this bug because:
>>> (2) Somehow the exception reporting from this class seems to be
>>> broken. I'm not sure if it's just me, but even though I've got a
>>> try/catch block, I can't catch the exception raised by an
>>> ImagePCAShapeModelEstimator object when you try to feed it
>>> wrong-sized images. This exception is raised on line 146 of
>>> itkImagePCAShapeModelEstimator.txx -- I know this because when I put
>>> a bunch of printfs (well, std::cout <<, but you get my drift) in the
>>> template code, I get output right up until where the exception is to
>>> be called. Somehow, the exception doesn't get propagated back properly.
>>> I've included some stripped-down test code (derived from the test
>>> code in the ITK tree) that on my machine reproduces this problem.
>>> The code tries to feed an ImagePCAShapeModelEstimator images with
>>> different regions (though the sizes are the same). All of this is
>>> done within a try/catch block; however the exception raised on line
>>> 146 of itkImagePCAShapeModelEstimator.txx never gets caught. (My
>>> setup: OS X 10.3.3, GCC 3.3 using c++ (not g++) compiler, with a CVS
>>> version of ITK updated last night, built with shared libraries.)
>>> Strange,
>>> Zach Pincus
>>> Attached is the test code. Here follows a backtrace of what I get
>>> when I run it in GDB. There is some strangeness afoot even in the
>>> backtrace -- note the "itkOctreeNode" source files erroneously
>>> assigned to symbols from the standard c++ library.
>>> #0 0x90042aac in kill ()
>>> #1 0x9009ec5c in abort ()
>>> #2 0x00018034 in __cxxabiv1::__terminate(void (*)()) () at
>>> /Volumes/Atlotl/Developer/ITK/ITK-CVS-src/Insight/Code/Common/
>>> itkSmartPointer.h:66
>>> #3 0x00018078 in std::terminate() () at
>>> /Volumes/Atlotl/Developer/ITK/ITK-CVS-src/Insight/Code/Common/
>>> itkSmartPointer.h:66
>>> #4 0x028079fc in __cxxabiv1::__unexpected(void (*)()) () at
>>> /Volumes/Atlotl/Developer/ITK/ITK-CVS-src/Insight/Code/Common/
>>> itkOctreeNode.h:117
>>> #5 0x027f607c in __cxa_call_unexpected () at
>>> /Volumes/Atlotl/Developer/ITK/ITK-CVS-src/Insight/Code/Common/
>>> itkOctreeNode.h:117
>>> #6 0x027d3e94 in itk::DataObject::PropagateRequestedRegion()
>>> (this=0x2501110) at
>>> /Volumes/Atlotl/Developer/ITK/ITK-CVS-src/Insight/Code/Common/
>>> itkDataObject.h:90
>>> #7 0x027d3388 in itk::DataObject::Update() (this=0x25009e0) at
>>> /Volumes/Atlotl/Developer/ITK/ITK-CVS-src/Insight/Code/Common/
>>> itkDataObject.cxx:343
>>> #8 0x0000343c in main () at
>>> /Volumes/Atlotl/Developer/ITK/ITK-CVS-src/Insight/Code/Common/
>>> itkSmartPointer.h:71
>>
>>
>>
>>
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users@itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>>
More information about the Insight-users
mailing list