[Insight-users] IsInside test TubeSpatialObject

[SCHMID, Jerome]

Hi Dan,

 

I've already seen your submitted spatial object, the only pb that is
that you didn't give the point that must be test for such a negative
lambda. Well yes every point on the left of a "sub tube" (tube composed
by two current points in the loop of the test) will have such a negative
lambda. The pb is that such point should not be tested in case because
by definition is out of the sub tube so we should skip the current sub
tube and take another 2 points.

 

As I pointed it to Julien, there is however another pb with the fact
that the current test is not accurate as it consider our sub tube as
right truncated cone whereas the are general oblique truncated
cones...but this is another story.

 

Anyway I am really interested in seeing your approach in the insight
journal. Thanks for your remarks.

 

Best Regards,

 

Jerome Schmid

 

---------------------------------------------

Jerome SCHMID

Project Manager / Engineer 

Augmented and Virtual Reality

Minimally Invasive Surgical Skills Center (MISS)

http://www.hkmisc.org.hk/

Prince of Wales Hospital

Chinese University Of Hong Kong

----------------------------------------------

 

________________________________

From: Dan Mueller [mailto:d.mueller at qut.edu.au] 
Sent: Wednesday, July 19, 2006 9:57 AM
To: Julien Jomier; SCHMID, Jerome
Cc: insight-users at itk.org
Subject: Re: [Insight-users] IsInside test TubeSpatialObject

 

Hi Julien and Jerome,

The test file attached to bug-3418
(http://www.itk.org/Bug/bug.php?op=show&bugid=3418&pos=0) is an example
of when lambda is negative for flat end-types. I have verified this by
putting a conditional std::cout statement in
itkTubeSpatialObject::IsInside(.) and ran the
itk::SpatialObjectToImageFilter with the attached file. FYI this
SpatialObject should have the following specifcations: size=[64, 64,
64], spacing=[1, 1, 1], and offset = [0, 0, 0].

Having a quick look at the code, if the point being tested (ie.
transformedPoint) is ever less than a (the first iterator) then A will
be negative, which in turn means lambda would be negative. Doesn't this
occur for all points on the "left" of the tube?

Honestly, I haven't looked too much into the guts of
itkTubeSpatialObject::IsInside(.) (except to report the original bug) -
but the code works fine for me now. Jerome: if your interest is in
speeding up SpatialObject to Image conversion, I hope to submit an
article to the InsightJournal within the next few weeks with one such
proposal (not requiring any changes to existing code)...

Hope this helps.

Cheers

Dan


Julien Jomier wrote: 

Hi Jerome, 

I think you are right. The test for negative Lambda is incorrect for a
flat end-type. 
I've CC Dan Mueller who reported the bug for negative lambda. He might
have some suggestions on this topic. Dan, if you agree that if lambda is
negative we should skip the pair of points, I will commit a fix. 

Thanks for looking into this, 

Julien 

SCHMID, Jerome wrote: 



Hi All, 

  

I have a pb to understand the lambda condition being negative in the
IsInside( point ) of TubeSpatialObject. 

  

To me if lambda is negative, the current 2 consecutive points used for
the test are not relevant, we should skip them and look for the next
pair. Lambda negative means that the point is not inside the space
within the two < normal disc > of the two points, so why do some test ? 

I really cannot understand the test done on negative lambda. A bug on
the bug tracker dealing with negative lambda was corrected suggesting
that this lambda <0 test was genuine.... 

  

Can somebody provide me a very simple figure where this test is
relevant? An mhd file with a point to test would be okay. 

  

Thanks ! 

  

/Best Regards,/ 

/ / 

/Jerome Schmid/ 


------------------------------------------------------------------------


_______________________________________________ 
Insight-users mailing list 
Insight-users at itk.org 
http://www.itk.org/mailman/listinfo/insight-users 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20060719/3457f2bf/attachment.html