[IGSTK-Developers] Agenda for Thursday 1pm tcon

[David Gobbi]

Hi James,

1) A freehand ultrasound calibration class would be a useful thing to 
have in IGSTK,
but we would have to make sure that it is properly maintained in the 
long term.
I suggest that you commit the class to the sandbox, and then in April we 
can make a
decision about whether to move it to the main repository.

2) I usually prefer the use of "real" image coordinates instead of 
"index" image
coordinates, but for ultrasound you often don't know the pixel scale 
until after
you have done the calibration...

We want a calibration routing that will take the raw "index coordinate" 
ultrasound
images, do the calibration, and produce two things: a rigid body 
transform, and the
(x,y) pixel spacing.  It is okay if the calibration routine uses an 
affine or similarity
transform internally, but then it should return the scale information 
separate from the
rest of the tranform.

The ultrasound machine knows the pixel spacing, but that information 
isn't carried in
the video stream.   With my vtkVideoSource class, I have a 
SetDataSpacing() method
that can be used to set the spacing after it has been determined through 
calibration,
and after it is set, all the images that come from the VideoSource will 
have that spacing.
Something similar could be done in IGSTK.

 - David


Hui Zhang wrote:
> Hi,
>
> A question is, whether we need an ultrasound calibration class for the 
> ultrasound RF application.
> I have implemented an ultrasound calibration class and put the 
> description in the wiki,
> http://public.kitware.com/IGSTKWIKI/index.php/Calibration_classes
> but there has some questions:
>
> 1. Whether we need this class?
> Ultrasound calibration should be done before the application, just 
> like tracker calibration. But in the application, those preset 
> calibration matrix can be written directly inside the code without 
> using this class.
>
> 2. This class will introduce affine registration or similarity 
> registration into IGSTK, so do we need make risk to bring similarity 
> transform and affine transform inside IGSTK which means more work?
> In my current code, I temporally use vtk classes to get affine and 
> similarity transform. Those extended factors (scale) are caused by 
> that the input information in the class from ultrasound image is the 
> landmark point's index, not the real coordinate. If we switch the 
> input from index to real coordinate, we only need rigid-body 
> transform. But can we get spacing information from ultrasound video 
> input?
>
> Although I have finished this class, IGSTK should be a tight and 
> elegant toolkit. So I am not sure whether we need this utility class 
> or not. Please feel free to comment on this.
>
> Regards,
> James
>
> ----- Original Message ----- From: "David Gobbi" <dgobbi at atamai.com>
> To: "IGSTK-developers" <igstk-developers at public.kitware.com>
> Sent: Wednesday, February 22, 2006 5:41 PM
> Subject: [IGSTK-Developers] Agenda for Thursday 1pm tcon
>
>
>> The preliminary agenda for the T-con is up:
>> http://public.kitware.com/IGSTKWIKI/index.php/Agenda%26Status_022306
>>
>> We will revisit last weeks discussion on applications following
>> the suggestions from our fearless leader in the non-contiguous
>> state (Hawaii).
>>
>> The other main areas of discussion will be the status and deadlines
>> for upcoming proposals, and identification of any additional
>> components we will need in order to be able to write the needle
>> driver, guidewire, and ultrasound RF applications.
>>
>> _______________________________________________
>> IGSTK-Developers mailing list
>> IGSTK-Developers at public.kitware.com
>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>
>>
>
>
>