[Insight-users] Insight-users Digest, Vol 69, Issue 11
Ricardo Ferrari
rjf.araraquara at gmail.com
Sat Jan 9 11:44:42 EST 2010
Hi itk-users,
My only fault !!! (or stupdity !!)
I would like to mention that the problem I was having with the
itk::Statistics::CovarianceSampleFilter was solved. The problem was being
caused by an type overflow - By changing the image pixel type from signed
short to double the problem was solved.
typedef itk::FixedArray< double, NumberOfContrasts >
ArrayPixelType;
typedef itk::Image< ArrayPixelType, Dimension >
ArrayImageType;
instead of
typedef itk::FixedArray< signed short, NumberOfContrasts >
ArrayPixelType;
Thank and sorry for bothering with this issue !!!
Ricardo
On Tue, Jan 5, 2010 at 2:44 PM, <insight-users-request at itk.org> wrote:
> Send Insight-users mailing list submissions to
> insight-users at 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 at itk.org
>
> You can reach the person managing the list at
> insight-users-owner at 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. [Fwd: Help save MySQL; Sign the petition]
> (jpr at creatis.insa-lyon.fr)
> 2. Re: fast marching behavior (siqi chen)
> 3. Re: Transformation of vtkPolyData with an itk::Transform
> (Lodron, Gerald)
> 4. Still having problems with Refactoring Statistic classes !!
> (Ricardo Ferrari)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 5 Jan 2010 01:27:09 +0100
> From: jpr at creatis.insa-lyon.fr
> Subject: [Insight-users] [Fwd: Help save MySQL; Sign the petition]
> To: vtkusers at vtk.org, insight-users at itk.org
> Message-ID:
> <f2c2e01ab2320db1c38900648b9f67e6.squirrel at www.creatis.insa-lyon.fr
> >
> Content-Type: text/plain;charset=iso-8859-1
>
> Hi!
>
> Yes, I know, the following is 100% out of topics, but, as users of free
> software, maybe you'll feel concerned.
>
> Sorry for the cross posting.
>
> --
> Jean-Pierre Roux
> Creatis CNRS UMR 5220, INSERM U630
>
>
> ---------------------------- Original Message ----------------------------
> Subject: Help save MySQL; Sign the petition
> From: monty at helpmysql.org
> Date: Thu, December 31, 2009 23:28
> To: undisclosed-recipients:;
> --------------------------------------------------------------------------
>
> Hi!
>
> I am contacting you because you have in the past shown interest in
> MySQL and from that I assume you are interested in the future
> well-being of MySQL.
>
> Now you have a unique opportunity to make a difference. By signing
> the petition at http://www.helpmysql.org you can help affect the
> future of MySQL as an Open Source database.
>
> You can find more information of this on my latest blog post at:
> http://monty-says.blogspot.com/2009/12/help-keep-internet-free.html
>
> Help us spread the world about this petition!
> http://www.helpmysql.org is available in 18 languages and every vote
> is important, independent of from where in the world it comes!
> If you know people that are using MySQL, please contact them and
> ensure they also sign the petition!
>
> Regards,
> Monty
> Creator of MySQL
>
> PS: If you already have signed the petition or know about it, sorry for
> reminding you about this! Because of the importance of this issue,
> I am trying to contact every person that I have ever communicated
> with regarding MySQL.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 4 Jan 2010 21:52:03 -0500
> From: siqi chen <siqichensc at gmail.com>
> Subject: Re: [Insight-users] fast marching behavior
> To: insight-users <Insight-users at itk.org>
> Message-ID:
> <5a74a9fd1001041852g51a663c0oa0df61145e1cabaa at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I read a few more papers and thought about the question number 2 again. I
> think there is misinterpretation on my part. The 4 neighbors of [49.7,49.8]
> along their exact distance value should be set as Alive Points instead of
> Trial Points. Then the neighbors of the 4 neighbors (another layer around
> the 4 neighbors) are set as trial points, their initial tentative values
> are
> calculated using upwind difference method. When I check the result distance
> map, a few things to notice:
> 1. The distance value of the 4 neighbors of [49.7, 49.8] are correct. This
> is obvious since I set them as Known instead of Trial.
> 2. The distance value of the neighbors of the 4 neighbors (the input trial
> points) still changed. I think this is due to the inherent FMM accuracy and
> update method.
>
> You can try this with the following code.
> http://www.rpi.edu/~chens/download/main3.cpp<http://www.rpi.edu/%7Echens/download/main3.cpp>
>
> Thanks
> Siqi
>
> On Mon, Jan 4, 2010 at 6:03 PM, siqi chen <siqichensc at gmail.com> wrote:
>
> >
> > To better illustrate my questions regarding fast marching, I put 2
> example
> > code in the attachment.
> >
> > In main1.cpp, I simply compute a distance map to point [50,50]. As you
> can
> > see from the output, the distances from the 4 neighbors of [50,50] to
> > [50,50] are correct, obviously the result is 1. However, the distance
> from
> > [51,51] to [50,50] is 1.707 instead of 1.414, which is obviously wrong. I
> > think this is due to the fast marching accuracy itself. If we switch to
> > higher order FMM, the result should be improved.
> >
> > In main2.cpp, I perturb the target point a little bit. Instead, I want to
> > compute the distance map to point [49.7,49.8]. From my point of
> > understanding, I need to initialize the 4 neighbors of [49.7, 49.8] and
> put
> > them into the TrialPoints. As you can see, I compute the exact distance
> from
> > these 4 neighbors to [49.7,49.8] and put them into TrialPoints. However,
> > when I go back and check the result distance map, some thing is
> different.
> > The distances from these 4 neighbors to [49.7,49.8] are changed. As you
> can
> > see, the distance from [50,50] to [49.7,49.8] remains correct. This is
> > because this value is the smallest in the TrialPoints, therefore it is
> > pushed in to the AlivePoints heap first and the value is frozen since
> then.
> > I think there is something wrong here about whether to update trial
> points
> > value or not. If this trial point is user specified, then the value
> should
> > not be updated. I noticed a related discussion a couple of months ago in
> the
> > mailing list,
> > http://www.itk.org/pipermail/insight-users/2009-May/030282.html
> >
> > http://www.rpi.edu/~chens/download/main1.cpp<http://www.rpi.edu/%7Echens/download/main1.cpp>
> <http://www.rpi.edu/%7Echens/download/main1.cpp>
> > http://www.rpi.edu/~chens/download/main2.cpp<http://www.rpi.edu/%7Echens/download/main2.cpp>
> <http://www.rpi.edu/%7Echens/download/main2.cpp>
> >
> > Any input is appreciated.
> > Siqi
> >
> >
> >
> > On Mon, Jan 4, 2010 at 3:32 PM, Dan Mueller <dan.muel at gmail.com> wrote:
> >
> >> Hi Siqi,
> >>
> >> Indeed I am familiar with Fast Marching. I saw your question to the
> >> mailing list, but did not respond because I have not experienced what
> >> you describe: when I set the trial point value, that is the value in
> >> the arrival function.
> >>
> >> Perhaps you could post to the mailing list a minimal example
> >> (code+cmake+data) demonstrating your issue. That would make it really
> >> easy for me to help you!
> >>
> >> Cheers, Dan
> >>
> >> 2010/1/4 siqi chen <siqichensc at gmail.com>:
> >> > Hi, Dan,
> >> >
> >> > Sorry to bother you. From the ITK mailing list, I noticed you reported
> a
> >> bug
> >> > about FastMarchingImageFilter couple of months ago. So I guess you are
> a
> >> > fast marching expert : )
> >> >
> >> > I am trying to use FastMarchingImageFilter to calculate a distance map
> >> to a
> >> > set of points which have non-integer coordinates and I want the result
> >> to be
> >> > as accurate as possible. Here is what I did, but the result is not
> very
> >> > accurate.
> >> >
> >> > First I find the integer points which are the neighbors of the target
> >> points
> >> > and set these integer points as trial points. Then I use some
> >> interpolation
> >> > method to initialize the distance from these trial points to the
> target
> >> > points, which are assumed to be "exactly correct". The TrialPoints in
> >> the
> >> > FastMarchingImageFilter is defined as this set of trial points and
> their
> >> > corresponding distances to the target points. The AlivePoints is
> empty.
> >> When
> >> > I check the result distance map, I find that the distance value of
> these
> >> > trial points are changed, they are no longer what their initial states
> >> are.
> >> > Therefore, the iso curve deviate the original input a little bit. I am
> >> quite
> >> > confusing about this result.
> >> >
> >> > I noticed you mentioned on the mailing list about neighbor update,
> that
> >> is
> >> > to distinguish between user-specified trial points and
> >> algorithm-generated
> >> > trial points. here is the discussion,
> >> > http://www.itk.org/pipermail/insight-users/2009-May/030282.html . I
> >> wonder
> >> > if you have any suggestions about my problem.
> >> >
> >> > Any input is appreciated.
> >> >
> >> > Thanks
> >> > Siqi Chen
> >> >
> >>
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.itk.org/pipermail/insight-users/attachments/20100104/fc7997e7/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 5 Jan 2010 07:50:08 +0100
> From: "Lodron, Gerald" <Gerald.Lodron at joanneum.at>
> Subject: Re: [Insight-users] Transformation of vtkPolyData with an
> itk::Transform
> To: Sajendra <sajendra at gmail.com>
> Cc: "insight-users at itk.org" <insight-users at itk.org>,
> "vtkusers at vtk.org" <vtkusers at vtk.org>
> Message-ID:
> <E70FE8EA6EBE9241BDB4CA6D8D12E1D86B7EF09841 at RZJC1EX.jr1.local>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> Unfortunatelly i am using the bspline transform. I know that the exact
> inverse is not given but is there a possibility to approximate the inverse
> of that transform?
>
> Best regards
>
> -----Urspr?ngliche Nachricht-----
> Von: Sajendra [mailto:sajendra at gmail.com]
> Gesendet: Donnerstag, 17. Dezember 2009 17:57
> An: Lodron, Gerald
> Cc: insight-users at itk.org; vtkusers at vtk.org
> Betreff: Re: [Insight-users] Transformation of vtkPolyData with an
> itk::Transform
>
> Hello Gerald,
>
> You will likely need to use the inverse of the transform computed from itk
> registration to transform your vtk polydata.
> The transform you have maps points from the fixed image space into the
> moving image space (so that it can be used to resample the moving image). If
> you want to transform points from the moving image space into the fixed
> image space, you need the inverse of that transform.
>
> Regards,
> Sajendra
>
>
>
> On Thu, Dec 17, 2009 at 5:27 AM, Lodron, Gerald <Gerald.Lodron at joanneum.at>
> wrote:
> > Hello
> >
> > I currently made a point selector which stores it's points into a
> vtkPolyData structure.
> >
> > Now I successfully made a image registration which converted the vtk
> image into itk, registered (transformed with itk::ResampleImageFilter) it
> and converted it back to vtk for visualization. Now the points of the
> vtkPolyData object are misaligned and I need to transform them. My point
> transformation implementation looks like this:
> >
> >
> >
> > The problem is that the points does not fit to their old position, so
> there must be something wrong with the transformPoint operation?
> >
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 5 Jan 2010 14:52:52 -0200
> From: Ricardo Ferrari <rjf.araraquara at gmail.com>
> Subject: [Insight-users] Still having problems with Refactoring
> Statistic classes !!
> To: insight-users at itk.org
> Message-ID:
> <dc387afe1001050852u2b254536p7fe38658345ebc9a at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi itk-users,
>
> Previously (Digest Vol 68, Issue 109), I reported a problem I was having
> with the itk::Statistics::CovarianceSampleFilter. Although, I have not got
> any feedback on that issue and I could not figure it out by myself, I have
> overcome the problem by writing my own function to compute the covariance
> matrix.
>
> Now, I have faced another issue when using the
> itk::Statistics::GaussianMixtureModelComponent and the
> itk::Statistics::ExpectationMaximizationMixtureModelEstimator
>
> Attached I am sending a minimal code to illustrate the problem. For testing
> the code, I have downloaded two minc images (t1 and a t2 contrasts) from
> the
> brainweb projects and converted them to dicom.
>
> The program call and the result are presented bellow
>
> ferrari at ferrari-workstation:~/Desktop/Test$ bin/test
> t1_icbm_normal_1mm_pn3_rf20.dcm t2_icbm_normal_1mm_pn3_rf20.dcm
> 1
> 1a
> 1b
> Segmentation fault
> ferrari at ferrari-workstation:~/Desktop/Test$
>
>
> Again, I really appreciate any help on clarifying these issues. Am I using
> the itk::Statistics::ImageToListSampleAdaptor class appropriately ?
>
>
> Thank you very much,
> Ricardo
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.itk.org/pipermail/insight-users/attachments/20100105/206f0d23/attachment.htm
> >
> -------------- next part --------------
> CMAKE_MINIMUM_REQUIRED(VERSION 2.7)
>
> SET( ProgramName "test" )
>
> PROJECT( ${ProgramName} )
>
> FIND_PACKAGE (ITK REQUIRED)
> IF (ITK_FOUND)
> INCLUDE( ${USE_ITK_FILE} )
> SET(ITK_LIBRARIES ITKCommon ITKBasicFilters ITKIO ITKMetaIO
> ITKNumerics ITKStatistics itkvnl)
> ENDIF(ITK_FOUND)
>
> FIND_PACKAGE (VTK REQUIRED)
> IF (VTK_FOUND)
> INCLUDE( ${USE_VTK_FILE} )
> SET(VTK_LIBRARIES vtkRendering vtkGraphics vtkWidgets vtkHybrid
> vtkImaging vtkIO vtkFiltering vtkCommon)
> ENDIF( VTK_FOUND)
>
> INCLUDE_DIRECTORIES(
> ${CMAKE_CURRENT_SOURCE_DIR}
> )
>
> SET( SRCS
> )
>
> ADD_EXECUTABLE( ${ProgramName}
> main.cpp
> ${SRCS}
> )
>
> TARGET_LINK_LIBRARIES( ${ProgramName}
> ${VTK_LIBRARIES}
> ${ITK_LIBRARIES}
> )
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: main.cpp
> Type: text/x-c++src
> Size: 3539 bytes
> Desc: not available
> URL: <
> http://www.itk.org/pipermail/insight-users/attachments/20100105/206f0d23/attachment.cpp
> >
>
> ------------------------------
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>
>
> End of Insight-users Digest, Vol 69, Issue 11
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100109/34c419cb/attachment-0001.htm>
More information about the Insight-users
mailing list