Hi Ziv,<br><br>I have removed the SetValidityTime method and made changes to the relevant<br>classes and tests. <br><br>Here is the bug entry.<br><br><a href="http://www.vtk.org/Bug/view.php?id=6982">http://www.vtk.org/Bug/view.php?id=6982</a><br>
<br>Will do the same with the RequestUpdateStatus soon.<br><br>-Andinet<br><br><div class="gmail_quote">On Wed, May 7, 2008 at 10:26 AM, Ziv Yaniv <<a href="mailto:zivy@isis.imac.georgetown.edu">zivy@isis.imac.georgetown.edu</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Andinet,<br>
<br>
I agree with both your suggestions, remove RequestUpdateStatus from the public API, and remove SetValidityTime altogether. Hopefully these changes won't break too much code (I will need to modify pivot calibration to work in this manner).<br>
<br>
thanks<br><font color="#888888">
Ziv</font><div><div></div><div class="Wj3C7c"><br>
<br>
Andinet Enquobahrie wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Ziv,<br>
<br>
Good points you brought up and thanks for the detailed description. My comments<br>
are below.<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
1. How to perform transformation data acquisition.<br>
<br>
a. No loop in my code. The tracker is acquiring data at a specified frequency and we are supposed to observe the tracker. When we get TrackerUpdateStatusEvent we need to invoke m_TrackerTool->RequestGetTransformToParent() and listen to the events generated from the tool to get the transform as payload. To acquire many transforms, lets say for averaging I have to maintain an ivar to do the accumulation.<br>
<br>
b. Have a loop in my code while(...) tracker->RequestUpdateStatus() and then ask for m_TrackerTool->RequestGetTransformToParent() and listen to the events generated from the tool. To acquire many transforms, I use a local variable.<br>
<br>
The pivot calibration code currently does 'b'. This is not good as there is a concurrent loop that is being run by the tracker. On the other hand the API should not have a RequestUpdateStatus() for the tracker, it should only be updated internally.<br>
<br>
If option 'a' is the IGSTK way of data gathering then we need to remove the RequestUpdateStatus() from the tracker and update all the relevant code to work "correctly".<br>
<br>
</blockquote>
Option 'a' is the correct one. RequestUpdateStatus is a callback method for the<br>
Pulse event observer. It is defined in the Tracker constructor as follows<br>
<br>
m_PulseObserver = ObserverType::New();<br>
m_PulseObserver->SetCallbackFunction( this, & Tracker::RequestUpdateStatus );<br>
m_PulseGenerator->AddObserver( PulseEvent(), m_PulseObserver );<br>
<br>
This method gets invoked internally when a pulse event is observed by the tracker.<br>
I don't think we will need RequestUpdateStatus() method be part of the<br>
public API. Users should not need to manually invoke this method.<br>
I will do some investigation and testing and move this method from public to<br>
private interface and remove the "Request" prefix.<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2. How to set the validity time of the transformation.<br>
<br>
Right now there are two options to set the validity time of the transformation.<br>
<br>
a. SetValidityTime() - does what the user expects.<br>
b. RequestSetFrequency() - surprises the user as it shouldn't have anything to do with the validity time.<br>
When the user invokes the RequestSetFrequency method the state machine invokes Tracker::SetFrequencyProcessing this in turn has the side effect of changing the validity time:<br>
<br>
/** The "SetFrequencyProcessing" passes the frequency value to the Pulse<br>
* Generator. Note that it is still possible for the PulseGenerator to reject<br>
* the value and stay at its current frequency. */<br>
void Tracker::SetFrequencyProcessing( void )<br>
{<br>
igstkLogMacro( DEBUG,<br>
"igstk::Tracker::SetFrequencyProcessing called ...\n");<br>
<br>
this->m_PulseGenerator->RequestSetFrequency( this->m_FrequencyToBeSet );<br>
<br>
//Set the validity time of the transforms based on the tracker frequency<br>
//Add a constant to avoid any flickering effect<br>
<br>
const double nonFlickeringConstant = 10;<br>
this->m_ValidityTime = (1000/m_FrequencyToBeSet) + nonFlickeringConstant;<br>
}<br>
I believe that the last two lines should be removed from the method.<br>
<br>
<br>
</blockquote>
The computation of validity time based on the tracking frequency is actually correct.<br>
Validity time of a transform depends on the tracking frequency. The relationship is<br>
described with the equation shown above with an additional constant factor to take<br>
into account the flickering effect.<br>
<br>
The problem is with the SetValidityTime public method. This method lets users set<br>
a bogus validity time without consideration of the tracking frequency. For example,<br>
if the frequency of a tracking device is 20Hz, but a user specifies a validity time<br>
of 1000ms, then the pipeline timing coordination will get out of sync and the tools<br>
will not be properly rendered. Therefore, I suggest removing the SetValidityTime<br>
public method.<br>
<br>
-Andinet<br>
<br>
<br>
</blockquote>
<br>
<br>
-- <br></div></div><div><div></div><div class="Wj3C7c">
Ziv Yaniv, PhD., Research Assistant Professor<br>
Imaging Science and Information Systems (ISIS) Center<br>
Department of Radiology<br>
Georgetown University Medical Center<br>
2115 Wisconsin Avenue, Suite 603<br>
Washington, DC, 20007,<br>
<br>
Phone: +1-202-687-7286<br>
Fax: +1-202-784-3479<br>
email: <a href="mailto:zivy@isis.georgetown.edu" target="_blank">zivy@isis.georgetown.edu</a><br>
web: <a href="http://isiswiki.georgetown.edu/zivy/" target="_blank">http://isiswiki.georgetown.edu/zivy/</a><br>
</div></div></blockquote></div><br>