[vtk-developers] new method for vtkContourRepresentation

[Dean Inglis]

Hi Karthik,


>> I've been working on a variant of vtkDijkstraGraphGeodesicPath
>> that works on vtkImageData (uses vtkPixel as the cell for building the 
>> adjacency list):
>> not sure what to call it (vtkImageDijkstra ?).
>>
>I would recommend following the same class hierarchy/naming convention 
>as in:
>vtkGeodesicPath <- vtkImageGeodesicPath <- vtkDijkstraImageGeodesicPath
>vtkGeodesicPath <- vtkGraphGeodesicPath <- vtkDijkstraGraphGeodesicPath
>
>I derived vtkGeodesicPath from vtkPolyDataAlgorithm, (I realize now that 
>I should have subclassed vtkAlgorithm). I think that's ok, the 
>ImageGeodesicPath would just have to override a few methods to take 
>vtkImageData as input. It still generates a vtkPolyData as output right ?
>>
>> I have also subclassed a new vtkContourLineInterpolator for 
>> vtkContourRepresentation
>> that maintains the above filter as an ivar and uses it to track edges 
>> in an interactive
>> manner similar to what is done with a LiveWire algorithm:
>> not sure what to call it (vtkDijkstraContourLineInterpolator ?).
>>
>That name is I would prefer if there is a way to allow an arbitrary 
>image to be set as input to the vtkDijkstraImageGeodesicPath. This would 
>allow several variants (I can think of at least 3).
>
>(a) livewire edge-tracker by tracing shortest path on the inverse 
>gradient magnitude of the image
>(b) extract vasculature "interactively" by tracing shortest path on the 
>Frangi vesselness measure of the image. This was done in [1] although 
>they used wavefront propagation to solve the minimal cost problem, to 
>avoid discretization artifacts.
>(c) to extract centerlines of objects (such as vasculature) 
>interactively by tracing the shortest path on the distance-map of the 
>binary segmentation. This was done in [2] although they use fast 
>marching to solve the minimum path problem on the distance map, (again 
>to avoid discretization artefacts).
>
>It would be nice to expose that part, either allowing the user to set 
>this image or override by subclassing, allowing the user can easily 
>construct these variants.

What I have done is modify vtkDijkstraGraphGeodesicPath to only 
consider VTK_PIXEL cell types and to add/check for an additional port which
is a vtkImageData that represents an arbitrary cost map (e.g. item a) or c)
below).  The algorithm still takes vtkPolyData as input and generates it
as output.  So in terms of inheritance, should it inherit from 
vtkGraphGeodesicPath or vtkDijkstraGraphGeodesicPath with modifications
(i.e. override some as yet to be made virtual methods)?  We could also make
the CalculateEdgeCost dependent on a user supplied cost function.
Let me know if you would like me to send source as a prelude to further
discussion.

>BTW: Have you also checked out [3]. Its ITK code, and not a VTK widget, 
>but uses a gradient based cost function, rather than Dijkstra to find 
>the shortest path.
>
>[1] Wink, O., Niessen, W.J., Viergever, M.A., 2004. Multiscale vessel 
>tracking. IEEE Transactions on Medical Imaging 23 (1), 130-133.
>[2] Deschamps, T., Cohen, L.D., 2001. Fast extraction of minimal paths 
>in 3D images and applications to virtual endoscopy. Medical Image 
>Analysis 5 (4), 281-299.
>[3] http://insight-journal.org/midas/handle.php?handle=1926/1372

Dang! Just when you thought you were up to date with all that
is going on in Kitware, it's already done!

thanks for taking the time to writing your Insightful reply ;)

Dean