[Insight-users] Re: Insight-users digest, Vol 1 #1499 - 8 msgs
Josiane Yankam Njiwa--DEA Clarysse--Fin 11/04
njiwa@creatis.insa-lyon.fr
Sun May 16 13:39:38 EDT 2004
Hi
I want to calculate similarity measure in the case of using
DeformableRegistration1.cxx and DeformableRegistration2.cxx.
For the second example, i try to connect a metric to the warp filter and
it doesn't work. I don't how to use the fact that i have a registration
procedure to get my similarity measure.
I have read carefully the registration examples, but i haven't solve my
problème.
Thank for you help.
Josiane
> Send Insight-users mailing list submissions to
> insight-users@itk.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.itk.org/mailman/listinfo/insight-users
> or, via email, send a message with subject or body 'help' to
> insight-users-request@itk.org
>
> You can reach the person managing the list at
> insight-users-admin@itk.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Insight-users digest..."
>
>
> Today's Topics:
>
> 1. Re: Similarity measure (Luis Ibanez)
> 2. Re: co-occurrence matrix (Glenn Pierce)
> 3. Re: derivative calculation (Luis Ibanez)
> 4. Re: co-occurrence matrix (Luis Ibanez)
> 5. RE: PCAShapeModelEstimator -- seems way too slow? (Lydia Ng)
> 6. Re: Regarding One of the Application (Luis Ibanez)
> 7. Re: PCAShapeModelEstimator -- seems way too slow? (Zachary Pincus)
> 8. RE: PCAShapeModelEstimator -- seems way too slow? (Sayan Pathak)
>
> --__--__--
>
> Message: 1
> Date: Fri, 14 May 2004 10:32:19 -0400
> From: Luis Ibanez <luis.ibanez@kitware.com>
> To: Josiane Yankam Njiwa--DEA Clarysse--Fin 11/04
> <njiwa@creatis.insa-lyon.fr>
> Cc: insight-users@itk.org
> Subject: Re: [Insight-users] Similarity measure
>
> This is a multi-part message in MIME format.
> --------------050909020004040107010204
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 8bit
>
>
> Hi Josiane,
>
>
> Many small details:
>
>
> A) You are missing to connect the transform to the metric, like
>
> metric->SetTransform( transform );
>
> B) you are passing the transform as argument to the GetValue()
> method of the metric. That shouldn't even compile... :-/
> GetValue() expects an array of doubles, those are the
> parameters for the transform.
>
> C) You are missing to connect an interpolator to the metric,
> probably you want to use the NearestNeighborhood interpolator.
>
> D) You are not calling Initialize() in the metric before invoking
> GetValue();
>
>
> Please find attached the code that will do the Metric computation.
>
>
> You will find useful to read the Registration chapter from the
> SoftwareGuide.
>
>
> Note also that if you have images that are already registered,
> there are much faster and simpler ways to do this computation.
>
>
>
> Regards,
>
>
>
> Luis
>
>
>
> ----------------------------------------------------------------------
> Josiane Yankam Njiwa--DEA Clarysse--Fin 11/04 wrote:
>
>> Hello
>>
>>
>> I have two images and i want to calculate the square difference métric
>> beetween the two images. I have the code below which is not work and
>> return zero when i run the programm. Can you help me to solve my
>> problem?
>> Thanks for your help
>>
>> Josiane
>>
>>
>> --------------------------------------------------------------------------
>> typedef itk::MeanSquaresImageToImageMetric<
>> FixedImageType,
>> MovingImageType > MetricType;
>> typedef itk::AffineTransform< PixelType, Dimension > TransformType;
>> TransformType::Pointer transform = TransformType::New();
>> MetricType::Pointer metric = MetricType::New();
>> TransformType::OutputVectorType translation;
>> translation[0] = 0; // X translation in millimeters
>> translation[1] = 1; // Y translation in millimeters
>> transform->Translate( translation );
>> transform->Rotate2D(0,false);
>> metric->SetFixedImage( fixedImageReader->GetOutput() );
>> metric->SetMovingImage( caster->GetOutput() );
>> metric->SetFixedImageRegion(
>> fixedImageReader->GetOutput()->GetBufferedRegion() );
>> const double bestValue = metric->GetValue(transform);
>> std::cout << " Metric value = " << bestValue << std::endl;
>> ---------------------------------------------------------------------------
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users@itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>>
> -------------------------------------------------------------------
>
>
> --------------050909020004040107010204
> Content-Type: text/plain;
> name="meanSquaredDifferences.cxx"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
> filename="meanSquaredDifferences.cxx"
>
>
> #include "itkImage.h"
> #include "itkImageFileReader.h"
> #include "itkImageFileWriter.h"
> #include "itkMeanSquaresImageToImageMetric.h"
> #include "itkTranslationTransform.h"
> #include "itkNearestNeighborInterpolateImageFunction.h"
> #include "itkLinearInterpolateImageFunction.h"
>
>
> int main( int argc, char * argv[] )
> {
> if( argc < 3 )
> {
> std::cerr << "Usage: " << std::endl;
> std::cerr << argv[0] << " fixedImage movingImage" << std::endl;
> return 1;
> }
>
> const unsigned int Dimension = 2;
> typedef unsigned char PixelType;
>
> typedef itk::Image< PixelType, Dimension > ImageType;
> typedef itk::Image< PixelType, Dimension > ImageType;
>
>
> typedef itk::ImageFileReader< ImageType > ReaderType;
>
> ReaderType::Pointer fixedReader = ReaderType::New();
> ReaderType::Pointer movingReader = ReaderType::New();
>
> fixedReader->SetFileName( argv[ 1 ] );
> movingReader->SetFileName( argv[ 2 ] );
>
> try
> {
> fixedReader->Update();
> movingReader->Update();
> }
> catch( itk::ExceptionObject & excep )
> {
> std::cerr << "Exception catched !" << std::endl;
> std::cerr << excep << std::endl;
> }
>
>
> typedef itk::MeanSquaresImageToImageMetric< ImageType, ImageType >
> MetricType;
>
> MetricType::Pointer metric = MetricType::New();
>
>
>
> typedef itk::TranslationTransform< double, Dimension > TransformType;
>
> TransformType::Pointer transform = TransformType::New();
>
>
>
> typedef itk::NearestNeighborInterpolateImageFunction<
> ImageType, double > InterpolatorType;
>
> InterpolatorType::Pointer interpolator = InterpolatorType::New();
>
>
> metric->SetInterpolator( interpolator );
> metric->SetTransform( transform );
>
>
> transform->SetIdentity();
>
> ImageType::ConstPointer fixedImage = fixedReader->GetOutput();
> ImageType::ConstPointer movingImage = movingReader->GetOutput();
>
> metric->SetFixedImage( fixedImage );
> metric->SetMovingImage( movingImage );
>
> metric->SetFixedImageRegion( fixedImage->GetBufferedRegion() );
>
> try
> {
> metric->Initialize();
> }
> catch( itk::ExceptionObject & excep )
> {
> std::cerr << "Exception catched !" << std::endl;
> std::cerr << excep << std::endl;
> return -1;
> }
>
>
> const double value = metric->GetValue( displacement );
>
> std::cout << "Mean Squares difference " << value << std::endl;
>
> return 0;
> }
>
>
> --------------050909020004040107010204--
>
>
>
> --__--__--
>
> Message: 2
> Subject: Re: [Insight-users] co-occurrence matrix
> From: Glenn Pierce <glennpierce@connectfree.co.uk>
> To: Luis Ibanez <luis.ibanez@kitware.com>
> Cc: insight-users@itk.org
> Date: Fri, 14 May 2004 16:04:41 +0100
>
> On Fri, 2004-05-14 at 10:17 -0400, Luis Ibanez wrote:
>>
>> Hi Glenn
>>
>>
>> You don't really need to write much code in order
>> to compute a coocurrence matrix in ITK because a
>> Coocurrence Matrix is simply a 2D Histogram.
>>
>> The itk::Statistics::Histogram class has been desigened
>> from the beginning for supporting multicomponent data.
>> Actually if you look at the Histogram example in the
>> SoftwareGuide, it is a 2D histogram case:
>>
>> http://www.itk.org/ItkSoftwareGuide.pdf
>>
>> Section 10.1.3, pdf-page 428.
>>
>> --
>>
>> You should be fine by just taking your two input images
>> and composing a Vector image with them. For this you can
>> use the Compose3DVectorImageFilter:
>> http://www.itk.org/Insight/Doxygen/html/classCompose2DVectorImageFilter.html
>>
>
>
> Ah I think I must have the wrong terminology, As I am working with only
> one grey scale image.
> Or maybe I am missing something fundamental.
>
> I was thinking of a grey-level co-occurence matrix.
> ie for each pixel in a grey scale image I would record the intensity
> level and also the intensity level of one of the adjacent pixels (Can do
> this for each of the adjacent pixels). I would then use the two
> intensity values as an index in maybe a 2d histogram where I increment
> the value at that index.
>
> This can provide information about the regions of the image
>
> (Sorry about the poor explanation)
> probably better description at
> http://www.engr.panam.edu/ee/faculty/harlow/6399/notes/Ch24.pdf.
>
>
> Sorry if I have misunderstood.
>
> Thanks for the feedback
>
>
>
>>
>> Then, passing this vector image to the ImageToHistogramGenerator:
>> http://www.itk.org/Insight/Doxygen/html/classitk_1_1Statistics_1_1ImageToHistogramGenerator.html
>>
>> and you get the 2D histogram at the end, which is exactly
>> a Coocurrence Matrix. Note that you must define the bin
>> sizes along every dimension, as well as the min and max
>> values to cover with the his domain of the histogram.
>>
>>
>>
>> The pipeline will look like
>>
>>
>> Image1---+
>> |
>> V
>> Compose2DVectorImage ---> ImageToHistogramGenerator ---> Histogram
>> ^
>> |
>> Image2---+
>>
>>
>>
>> Please let us know if you find any problem,
>>
>>
>> Thanks
>>
>>
>>
>> Luis
>>
>>
>>
>>
>> -------------------
>> Glenn Pierce wrote:
>> > Hi
>> >
>> > I was wondering what the best way of implementing a co-occurrence
>> > matrix.
>> > I was thinking of just using itk::Statistics::ImageToListAdaptor or a
>> > subclass to loop through the image's
>> > pixel values and counting each co-occurrence in a histogram.
>> >
>> > Would there be a better way for itk, with respect to contributing the
>> > code back to ITK?
>> > Maybe basing my code on another filter?
>> >
>> > Thanks
>> >
>> > Glenn
>> >
>> >
>> > Glenn Pierce
>> > email: glennpierce@connectfree.co.uk
>> >
>> > _______________________________________________
>> > Insight-users mailing list
>> > Insight-users@itk.org
>> > http://www.itk.org/mailman/listinfo/insight-users
>> >
>>
>>
>>
> Glenn Pierce
>
> email: glennpierce@connectfree.co.uk
>
>
> --__--__--
>
> Message: 3
> Date: Fri, 14 May 2004 11:04:48 -0400
> From: Luis Ibanez <luis.ibanez@kitware.com>
> To: Michael <michakuhn@gmx.ch>
> Cc: insight-users <insight-users@itk.org>
> Subject: Re: [Insight-users] derivative calculation
>
>
>
> Hi Michael,
>
>
> Thanks for pointing this out.
>
>
> This actually qualifies as a bug. It has been
> entered in the bug tracker with ID # 843
> http://www.itk.org/Bug/bug.php?op=show&bugid=843&pos=0
>
>
> As you pointed out it will be more appropriate to
> have a SetDelta()/GetDelta() methods for setting
> the value of differential to be used for computing
> the derivative. This value was fixed in good faith :-)
> under the assumption that the values to optimizer are
> in the [-1:1] range. In practice, there is no way
> for the Metric to enforce this range...
>
> The scaling parameters are in practice applied to
> the optimizer, where they are taken into account.
>
> --
>
> This bug has now been fixed.
>
> Please update your CVS checkout in order to get
> the modifications.
>
> Let us know if you find any other problem.
>
>
>
> Thanks
>
>
>
> Luis
>
>
> ---------------
> Michael wrote:
>
>> Hi,
>>
>> I've noticed, that the for the derivative calculation, the
>> MeanReciprocalSquareDifferenceImageToImageMetric and the
>> GradientDifferenceImageToImageMetric make uses of a fix-coded (0.00011)
>> delta for their derivative calculation. It seems to me, that the
>> HistogramImageToImageMetric uses a flexible derivative step length and
>> scalings for each parameters dimension for the same thing. I hope I
>> understood this correctely...
>>
>> Is there a reason for the fix coded 0.00011 delta, and why 0.00011?
>>
>> Thanks,
>>
>> Michael
>>
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users@itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>>
>
>
>
>
> --__--__--
>
> Message: 4
> Date: Fri, 14 May 2004 11:12:27 -0400
> From: Luis Ibanez <luis.ibanez@kitware.com>
> To: Glenn Pierce <glennpierce@connectfree.co.uk>
> Cc: insight-users@itk.org
> Subject: Re: [Insight-users] co-occurrence matrix
>
>
> Hi Glenn,
>
> Thanks for the clarification.
>
> Well...
>
> You probably will have to write that
> ImageToListAdaptor class after alll :-)
>
>
> I would suggest you to write it as a
>
> ImageToListFilter
>
>
> and take advantage of the Neighborhood
> Iterators. You probably can get very
> close by looking at the code used for
> the Morphological filters.
>
> Please read the Iterators chapter on
> the SoftwareGuide. That will help you
> find your way.
>
> It will be nice let the option to the
> user for defining what neighbors to
> use as cliques for the coorcurrence
> matrix.
>
> Your filter will populate a List of
> 2D vector values having all the pairs
> of cliques from your images.
>
>
> Please let us know if you need any
> help implementing this filter.
>
> and... of course, we will be happy
> to get it back into the toolkit
> once you are done :-)
>
>
>
> Thanks
>
>
> Luis
>
>
>
> --------------------
> Glenn Pierce wrote:
>
>> On Fri, 2004-05-14 at 10:17 -0400, Luis Ibanez wrote:
>>
>>>Hi Glenn
>>>
>>>
>>>You don't really need to write much code in order
>>>to compute a coocurrence matrix in ITK because a
>>>Coocurrence Matrix is simply a 2D Histogram.
>>>
>>>The itk::Statistics::Histogram class has been desigened
>>>from the beginning for supporting multicomponent data.
>>>Actually if you look at the Histogram example in the
>>>SoftwareGuide, it is a 2D histogram case:
>>>
>>> http://www.itk.org/ItkSoftwareGuide.pdf
>>>
>>>Section 10.1.3, pdf-page 428.
>>>
>>>--
>>>
>>>You should be fine by just taking your two input images
>>>and composing a Vector image with them. For this you can
>>>use the Compose3DVectorImageFilter:
>>>http://www.itk.org/Insight/Doxygen/html/classCompose2DVectorImageFilter.html
>>>
>>
>>
>>
>> Ah I think I must have the wrong terminology, As I am working with only
>> one grey scale image.
>> Or maybe I am missing something fundamental.
>>
>> I was thinking of a grey-level co-occurence matrix.
>> ie for each pixel in a grey scale image I would record the intensity
>> level and also the intensity level of one of the adjacent pixels (Can do
>> this for each of the adjacent pixels). I would then use the two
>> intensity values as an index in maybe a 2d histogram where I increment
>> the value at that index.
>>
>> This can provide information about the regions of the image
>>
>> (Sorry about the poor explanation)
>> probably better description at
>> http://www.engr.panam.edu/ee/faculty/harlow/6399/notes/Ch24.pdf.
>>
>>
>> Sorry if I have misunderstood.
>>
>> Thanks for the feedback
>>
>>
>>
>>
>>>Then, passing this vector image to the ImageToHistogramGenerator:
>>>http://www.itk.org/Insight/Doxygen/html/classitk_1_1Statistics_1_1ImageToHistogramGenerator.html
>>>
>>>and you get the 2D histogram at the end, which is exactly
>>>a Coocurrence Matrix. Note that you must define the bin
>>>sizes along every dimension, as well as the min and max
>>>values to cover with the his domain of the histogram.
>>>
>>>
>>>
>>>The pipeline will look like
>>>
>>>
>>>Image1---+
>>> |
>>> V
>>> Compose2DVectorImage ---> ImageToHistogramGenerator ---> Histogram
>>> ^
>>> |
>>>Image2---+
>>>
>>>
>>>
>>>Please let us know if you find any problem,
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> Luis
>>>
>>>
>>>
>>>
>>>-------------------
>>>Glenn Pierce wrote:
>>>
>>>>Hi
>>>>
>>>>I was wondering what the best way of implementing a co-occurrence
>>>>matrix.
>>>>I was thinking of just using itk::Statistics::ImageToListAdaptor or a
>>>>subclass to loop through the image's
>>>>pixel values and counting each co-occurrence in a histogram.
>>>>
>>>>Would there be a better way for itk, with respect to contributing the
>>>>code back to ITK?
>>>>Maybe basing my code on another filter?
>>>>
>>>>Thanks
>>>>
>>>>Glenn
>>>>
>>>>
>>>>Glenn Pierce
>>>>email: glennpierce@connectfree.co.uk
>>>>
>>>>_______________________________________________
>>>>Insight-users mailing list
>>>>Insight-users@itk.org
>>>>http://www.itk.org/mailman/listinfo/insight-users
>>>>
>>>
>>>
>>>
>> Glenn Pierce
>>
>> email: glennpierce@connectfree.co.uk
>>
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users@itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>>
>
>
>
>
> --__--__--
>
> Message: 5
> Subject: RE: [Insight-users] PCAShapeModelEstimator -- seems way too slow?
> Date: Fri, 14 May 2004 10:23:25 -0700
> From: "Lydia Ng" <lng@insightful.com>
> To: "Zachary Pincus" <zpincus@stanford.edu>,
> "ITK" <insight-users@itk.org>
>
> Zach,
>
> Out of curiosity - could you post info about the compiler and compile =
> flags
> that you used on your G4?
>
> - Lydia
>
>> -----Original Message-----
>> From: Zachary Pincus [mailto:zpincus@stanford.edu]
>> Sent: Friday, May 14, 2004 12:20 AM
>> To: ITK
>> Subject: [Insight-users] PCAShapeModelEstimator -- seems way too slow?
>>=20
>> Hello,
>>=20
>> Recently, I've been doing some PCA work, and I noticed that itk's
>> ImagePCAShapeModelEstimator seems to be surprisingly slow.
>>=20
>> I have, for example, 1100 images of size 20x15 -- a pretty modest data
>> set to do PCA on. Matlab (running on a 450 MHz ultrasparc-II) can
>> compute the principal components on such a dataset in a few seconds,
>> even when I intentionally do things in a particularly slow way.
>>=20
>> Using the ITK PCA estimator, this same operation takes 15+ minutes on
>> my personal machine (867 mhz g4). It's not a RAM or VM issue since the
>> process never seems to grab more than 100 megs of RAM, and doesn't hit
>> the disk at all.
>>=20
>> This seems especially strange given the effort in the PCA class's
>> implementation toward efficiency. (Though I do realize that a dataset
>> such as mine with more images than pixels per image does defeat some =
> of
>> the optimizations rolled in...)
>>=20
>> What could I possibly be doing wrong? I profiled the itk PCA code, and
>> nothing looks overtly wrong -- it just seems to take way too long!
>>=20
>> Zach Pincus
>>=20
>> Department of Biochemistry and Program in Biomedical Informatics
>> Stanford University School of Medicine
>>=20
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users@itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>
> --__--__--
>
> Message: 6
> Date: Fri, 14 May 2004 16:27:50 -0400
> From: Luis Ibanez <luis.ibanez@kitware.com>
> To: "Dwivedi, Shekhar (Research, Non-ge)" <shekhar.dwivedi@ge.com>
> Cc: Insight-users@itk.org
> Subject: [Insight-users] Re: Regarding One of the Application
>
>
>
> Hi Shekhar
>
>
> 1) This application is unfortunately quite missleading.
> (we should probably remove it from the repository).
>
> It is only illustrating how to put together all the
> components of the registration framework. They are
> not fine tunned for working together, so it will be
> useless to attempt to perform a real registration
> with this application.
>
> If you are looking for an application to try, please
> look at
>
> LandmarkInitializedMutualInformationRegistration
>
>
> 2) When you change the tolerance in the RegularStepGradient
> descent optimizer you may force the optimizer to look
> for a more stable solution, and this can take more
> iterations. It doesn't necessarily means that you
> are going to get a different answer, it simply means
> that the precision of the answer has been verified
> further.
>
> Note that this optimizer returs the criteria that
> triggered the process to stop. Please call
> GetStopCondition() just after the registration finish.
> That will tell you if you used all the iteration or
> stopped due to the step length size, or due to the
> magnitude of the derivative.
>
>
> 3) If you want to write you own optimizer, please take
> a look at the superclasses of the RegularStepGradient
> descent. There are a number of standard methods that
> you may have to implement. In general the optimizer
> receives an array of parameters (this is the parametric
> space for the optimization), and has access to a cost
> function (that in image registration is the image
> metric). You should decide if your optimizer requires
> the metric to compute derivatives or not.
>
> Make sure that you invoke IterationEvents at each
> iteration of your optimizer, that will allow you to
> connect an observer and follow the progression of your
> optimizer at run time.
>
>
>
>
> Regards,
>
>
> Luis
>
>
>
> ----------------------------------------
> Dwivedi, Shekhar (Research, Non-ge) wrote:
>
>> Hi luis ,
>>
>> I have a question regarding one of the example in InsightApplications
>> directory.
>>
>> 1-
>> In the directory InsightApplications/ImageRegistration
>>
>> There is a interface in which there is a choice to select any one of the
>> optimizer among
>> Regular Step , Gradient Descent , Conjugate Gradient.
>>
>> I am wondering whether this functionality is implemented or not.As I
>> have seen the code where the optimizers is
>> selected from the file liImageRegistrationConsoleBase.cxx , there is no
>> parameter setting for any of the optimizers.
>> I have checked other files as well , please clarify the doubt that if
>> the optimizers are selected then where is the
>> exact location of setting up of the parameters for the corresponding
>> optimizer.
>>
>> 2-
>>
>> I have one more question regarding the Regular Step Gradient Descent
>> optimizer.
>>
>> I tried to include the tolerance factor also for this optimizer for my
>> 3D image registration , but the output was same as
>> without tolerance factor and it took more time for the registration ,
>> what may be the likely reason for this.
>>
>> Finally can u tell me which all parameters of Conjugate Descent
>> optimizer are required to be called for image registration.
>>
>> 3-
>>
>> If I plan about writing my own optimizer(specific to image registration)
>> then what all things I must consider beside the
>> implementation.
>>
>> Yours,
>> Shekhar.
>>
>
>
>
>
> --__--__--
>
> Message: 7
> Cc: "ITK" <insight-users@itk.org>
> From: Zachary Pincus <zpincus@stanford.edu>
> Subject: Re: [Insight-users] PCAShapeModelEstimator -- seems way too slow?
> Date: Fri, 14 May 2004 13:36:22 -0700
> To: "Lydia Ng" <lng@insightful.com>
>
>> Out of curiosity - could you post info about the compiler and compile
>> flags
>> that you used on your G4?
>
> I compiled both ITK and my project with GCC 3.3 (using c++, not g++).
> Here's the "c++ -v" info: gcc version 3.3 20030304 (Apple Computer,
> Inc. build 1495)
>
> The cmake flags I set for ITK were to compile as shared libs, and the
> build style was RelWithDebInfo. I didn't mess with the default flags
> for this.
> Additionally, I compiled my project with both Debug and RelWithDebInfo
> settings, which didn't seem to make much difference.
>
> Do you think I have drastically hindered the ITK/VNL performance with
> these compiler settings? Or might my problems lie elsewhere?
>
> Thanks so much,
> Zach
>
>
>>
>>> -----Original Message-----
>>> From: Zachary Pincus [mailto:zpincus@stanford.edu]
>>> Sent: Friday, May 14, 2004 12:20 AM
>>> To: ITK
>>> Subject: [Insight-users] PCAShapeModelEstimator -- seems way too slow?
>>>
>>> Hello,
>>>
>>> Recently, I've been doing some PCA work, and I noticed that itk's
>>> ImagePCAShapeModelEstimator seems to be surprisingly slow.
>>>
>>> I have, for example, 1100 images of size 20x15 -- a pretty modest data
>>> set to do PCA on. Matlab (running on a 450 MHz ultrasparc-II) can
>>> compute the principal components on such a dataset in a few seconds,
>>> even when I intentionally do things in a particularly slow way.
>>>
>>> Using the ITK PCA estimator, this same operation takes 15+ minutes on
>>> my personal machine (867 mhz g4). It's not a RAM or VM issue since the
>>> process never seems to grab more than 100 megs of RAM, and doesn't hit
>>> the disk at all.
>>>
>>> This seems especially strange given the effort in the PCA class's
>>> implementation toward efficiency. (Though I do realize that a dataset
>>> such as mine with more images than pixels per image does defeat some
>>> of
>>> the optimizations rolled in...)
>>>
>>> What could I possibly be doing wrong? I profiled the itk PCA code, and
>>> nothing looks overtly wrong -- it just seems to take way too long!
>>>
>>> Zach Pincus
>>>
>>> Department of Biochemistry and Program in Biomedical Informatics
>>> Stanford University School of Medicine
>>>
>>> _______________________________________________
>>> Insight-users mailing list
>>> Insight-users@itk.org
>>> http://www.itk.org/mailman/listinfo/insight-users
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users@itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>>
>
>
> --__--__--
>
> Message: 8
> Subject: RE: [Insight-users] PCAShapeModelEstimator -- seems way too slow?
> Date: Fri, 14 May 2004 14:19:58 -0700
> From: "Sayan Pathak" <spathak@insightful.com>
> To: <zpincus@stanford.edu>
> Cc: <insight-users@itk.org>
>
> Hi Zach,
> Classically, the PCA can be calculated by identifying the eigen vectors
> corresponding to the k largest eigen values in the covariance matrix
> (generated from the data). Owing to the fact that in image processing, =
> one
> uses images with large number of pixels, the implementation in ITK is =
> bit
> different and the logic behind choosing such an approach is explained in =
> the
> documentation of the itkImagePCAShapeModelEstimator class. Here is an =
> excerpt
> from the class documentation explaining the logic:
>
>
> * To speed the computation instead of performing the eigen analysis of =
> the=20
> * covariance vector A*A' where A is a matrix with p x t, p =3D number =
> of
> * pixels or voxels in each images and t =3D number of training images, =
> we
> * calculate the eigen vectors of the inner product matrix A'*A. The
> resulting
> * eigen vectors (E) are then multiplied with the matrix A to get the=20
> * principal components. The covariance matrix has a dimension of p x p.
> Since=20
> * number of pixels in any image being typically very high the eigen=20
> * decomposition becomes computationally expensive. The inner product on =
> the=20
> * other hand has the dimension of t x t, where t is typically much =
> smaller=20
> * that p. Hence the eigen decomposition (most compute intensive part) =
> is
> * orders of magnitude faster.
>
> Lets consider a typical data set of 100 images each of the size 256 x =
> 256
> pixels. The A matrix will have a dimension of 256^2 x 100. As per the
> classical approach, the covariance matrix will have a dimension of 256^2 =
> x
> 256^2. Using our approach the inner product matrix dimension reduces to =
> 100 x
> 100. These leads to a huge reduction in both computation and the memory
> requirements.
>
> In your case, the A matrix will have a size of 300 x 1100. The =
> covariance
> matrix will have a dimension of 300 x 300, while the inner product =
> matrix
> dimension will 1100 x 1100. This would explain the large computation =
> time you
> are seeing.
>
> One approach could be to compute the covariance matrix followed by k =
> largest
> eigen vector identification using the existing functions in ITK. =
> Ideally, the
> approach would be to have both the methods implemented and switch =
> between one
> or the other depending on the size of the training set, the two =
> scenarios
> being large images with fewer training sets (use inner product =
> matrix)and
> small images with large number of training sets (use the covariance =
> matrix).
>
> Hope this explanation helps. Thanks,
>
> Sayan
>
>
>
>
>
>>Hello,
>
>>Recently, I've been doing some PCA work, and I noticed that itk's=20
>>ImagePCAShapeModelEstimator seems to be surprisingly slow.
>
>>I have, for example, 1100 images of size 20x15 -- a pretty modest data=20
>>set to do PCA on. Matlab (running on a 450 MHz ultrasparc-II) can=20
>>compute the principal components on such a dataset in a few seconds,=20
>>even when I intentionally do things in a particularly slow way.
>
>>Using the ITK PCA estimator, this same operation takes 15+ minutes on=20
>>my personal machine (867 mhz g4). It's not a RAM or VM issue since the=20
>>process never seems to grab more than 100 megs of RAM, and doesn't hit=20
>>the disk at all.
>
>>This seems especially strange given the effort in the PCA class's=20
>>implementation toward efficiency. (Though I do realize that a dataset=20
>>such as mine with more images than pixels per image does defeat some of =
>
>>the optimizations rolled in...)
>
>>What could I possibly be doing wrong? I profiled the itk PCA code, and=20
>>nothing looks overtly wrong -- it just seems to take way too long!
>
>>Zach Pincus
>
>
>
> --__--__--
>
> _______________________________________________
> Insight-users mailing list
> Insight-users@itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>
>
> End of Insight-users Digest
>
More information about the Insight-users
mailing list