[IGSTK-Developers] Follow up: an igstkReferenceCalibration class?

[Hui Zhang]

Hi, David,

5D or 6D 'point' means 5D or 6D position/orientation transform returned by 
the tracker, just as you mentioned.

Regards,
James
----- Original Message ----- 
From: "David Gobbi" <dgobbi at atamai.com>
To: "Hui Zhang" <zhang at isis.imac.georgetown.edu>
Cc: "Patrick Cheng" <cheng at isis.georgetown.edu>; "'IGSTK-developers'" 
<igstk-developers at public.kitware.com>
Sent: Wednesday, November 30, 2005 5:23 PM
Subject: Re: [IGSTK-Developers] Follow up: an igstkReferenceCalibration 
class?


> Hui Zhang wrote:
>
>> Hi, all,
>>
>> As we find that the igstkPivotCalibration can only give 3D translation in 
>> the output transform, which is limited by the pivot routine, so should we 
>> have a general igstkReferenceCalibration to get the 3D/5D/6D transform?
>
> It looks like we should adopt a naming convention that includes "Tool" as 
> part of the name, to make it clear that the transform is to be used as a 
> ToolCalibrationTransform:
>
> igstkPivotToolCalibration, igstkReferenceToolCalibration
>
>> The idea of igstkReferenceCalibration class is to compute the reference 
>> calibration transform from one or more object points (can be 3D/5D/6D) to 
>> another refrence point ( can also be 3D/5D/6D).
>
> I'm not sure what you mean by a 5D or 6D reference point, since a "point" 
> is always 3D.  Some of the scientific literature, especially in computer 
> graphics, uses the term "pose" to describe the position and orientation of 
> an object together.  When you say a 5D or 6D point, do you mean a 5D or 6D 
> position/orientation transform returned by the tracker?
>> The genreal diagram will be:
>> Input:                                Output:
>> object point->ref point
>> 3D->3D                            3D translation
>> 3D->5D                            3D translation
>> 3D->6D                            3D translation
>> 2x3D->3D                        3D translation
>> 2x3D->5D                        3D translation + 2D rotation
>> 2x3D->6D                        3D translation + 2D rotation
>> 5D->3D                            3D translation
>> 5D->5D                            3D translation + 2D rotation
>> 5D->6D                            3D translation + 2D rotation
>> 6D->3D                            3D translation
>> 6D->5D                            3D translation + 2D rotation
>> 6D->6D                            3D translation + 3D rotation
>>
>> Some further conditions is: 2x3D = 5D, 3x3D = 6D, 2x5D = 6D, ...
>>
>> So, in our tool calibration routine, we can get first 3D point from 
>> igstkPivotCalibration, and then set second hip point as the input 
>> together, 2x3D->5D to get the 3D translation + 2D rotation. For example, 
>> in the PivotCalibration, we get (x, y, z) from the tip, and then we can 
>> set (x, y, z + 100) as the hip's translation. Those two points (x, y, z) 
>> (x, y, z + 100) will input to igstkReferenceCalibration to get the final 
>> igstkTransform. In this case, the default reference point is (0, 0, 0). 
>> If we input the run-time positions as input, such as T * (x, y, z)', T * 
>> (x, y, z+100)', we also need input the reference point which build that T 
>> transform to get the final calibration result.
>
> This sounds good.
>
>> There is a small problem with:
>> 5D->5D                            3D translation + 2D rotation
>> 5D->6D                            3D translation + 2D rotation
>> in those two cases, we get the same 5D output, but only in 6D reference 
>> we can the correct referenced position, Needle is a specific shape, for 
>> we assume it has a translation like (0, 0, z) so that it can eliminate 
>> the 6th rotation error which will propogate along x and y axies.
>
> I think that I follow what you're talking about here.  Tools like needles 
> really are only 5D, so only a 5D calibration is necessary for these tools. 
> We don't need a 6D calibration: the third orientation angle is arbitrary. 
> This also implies that the spatial objects for these tools must be 
> radially symmetric, e.g. cylindrical.
>
> - David
>
>> Regards,
>> James
>>
>> ----- Original Message ----- From: "David Gobbi" <dgobbi at atamai.com>
>> To: "Patrick Cheng" <cheng at isis.georgetown.edu>
>> Cc: "'IGSTK-developers'" <igstk-developers at public.kitware.com>
>> Sent: Wednesday, November 30, 2005 2:38 PM
>> Subject: Re: [IGSTK-Developers] SpatialObject calibration transform
>>
>>
>>> Hi Patrick,
>>>
>>> Thanks for the summary.  The reason that I would prefer to add the 
>>> orientation as part of the tool calibration transform is that I think we 
>>> should keep the number of coordinate transformations in IGSTK to a 
>>> minimum.
>>>
>>> Each coordinate transformation is a possible source of error.  Even 
>>> worse, if two different transformations can be used to achieve the same 
>>> result (e.g. a tool calibration transform and a spatial object 
>>> calibration transform), then both transforms can have errors that cancel 
>>> each other out.  These sorts of errors can be very hard to debug.
>>>
>>> I think the best solution is if the ToolTipCalibration class has a 
>>> method that allows you to specify the orientation of the tool that is 
>>> being calibrated.
>>>
>>> - David
>>>
>>> Patrick Cheng wrote:
>>>
>>>> Hi everybody,
>>>>
>>>> What I was trying to say in the Tcon is:
>>>>
>>>> the cylinder object (longest axis) is align with Y axis in image space 
>>>> (inherited from ITK by default). while the probe is aligned with the 
>>>> tracker's X axis.
>>>>
>>>> So when we get the PatientTransform, which essentially align the image 
>>>> space and tracker space together, but still the cylinder spatialobject 
>>>> and the probe is not aligned correctly. We need first rotate our 
>>>> spatial object to align with the probe, and then use the pivot 
>>>> calibration transform to get the tip translation.
>>>>
>>>> This adjustment of the spatial object's coordinate system, can be done 
>>>> by adding the rotational information to tool calibration transform. or 
>>>> we can add it to a upper level transform when we construct a spatial 
>>>> object group to model the probe.
>>>>
>>>> Patrick
>>>
>>>
>>>
>>> _______________________________________________
>>> IGSTK-Developers mailing list
>>> IGSTK-Developers at public.kitware.com
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>>
>>
>>
>>
>
>