[Insight-developers] wrapped filters types

[Gaetan Lehmann]

Hi Luis,

You're right about the number of classes a developer use. I'm using (in  
c++) small pipelines, with about 5-15 filters, and I do not use  
registration at all.
But for prototyping, adding filter when people need it is not a usable  
option. I'm developing pipelines to analyze images in a biologist lab.  
Most of the time, it's not difficult image analysis problems, but it force  
me to try different pipelines. How can I use ITK with python if I must  
rebuild wrappers each time I need a new filter ?
I can't (and don't want) spend time to develop an interface to tweak each  
parameter for a given pipeline, and tweaking is nearly impossible to do in  
c++. The result for me is that I switched (I hope for a short time) to  
matlab, which is however really far from ITK quality.
If ITK can't have a good access with easy to use language like python, I  
will have to use another tool kit :-(. It is not a severe problem for ITK,  
but it is a severe one for me !

Perhaps my problem is that I see wrappers as an efficient way for  
prototyping, and you "only" as an way to use itk in programs developed in  
other languages :-/

Gaetan





On Wed, 06 Apr 2005 17:47:29 +0200, Luis Ibanez <luis.ibanez at kitware.com>  
wrote:

>
> Hi Gaetan,
>
> We all agree with your request of having all the ITK filters
> available at the wrapped layer.
>
> Unfortunately this is a technical challenge where we face
> the trade-off of:
>
>
>        1) Time required for building wrapping
>        2) Size of the libraries
>        3) Convenience of having all filters available
>
>
> The option that you mention for wrapping all filters for the same
> InputImage and OutputImage type is interesting, however it doesn't
> go too far once you start considering details, for example, what
> would you do with filters that produce vector images, what would
> you do with the watershed filter that produces unsigned long labels,
> What would you do with filters that require float/double images, or
> those that produce signed images like the signed distance danielsson
> filter.
>
>
> The interesting question with wrapping is :
>
>
>        At any given time,
>        how many classes is a developer actually using ?
>
>
>   1)    10% of the toolkit ?
>   2)     1% of the toolkit ?
>
>
>
> There are about 700 classes in ITK. Few pipelines use more than
> 20 different types of filters. This situation is what lead us to
> a "user-driven" selection of the classes to wrap. In other words
> we only wrap the classes (and instantiations) that are of interest
> for the users.
>
> You simply need to post to the users list the names and types
> of the filters that you consider should be wrapped. You could also
> enter this as a request on the phpBugtracker.
>
> Asking for wrapping 'everything' is a well intentioned proposition
> but unfortunately is not a realistic one.
>
> Much more useful is your final statement when you specifically
> mention the filters that you are really missing right now. In
> particular some types for the Rescale (I assume you meant the
> RescaleIntensityImageFilter) and the labels filter.
>
> Could you please be more specific regarding the particular pixel
> types that you are needing to be wrapped ?
>
> With that list we will be able to add the corresponding wrapping
> files to the system.
>
>
> Please let us know,
>
>
>     Thanks
>
>
>        Luis
>
>
> ------------------------
> Gaetan Lehmann wrote:
>
>>  Hi,
>>  One of the biggest problem when I try to use itk wrappers, is that not  
>> all  filters are wrapped.
>> Itk wrapper user can rebuild the wrapper to add the filter he need,  
>> but  clearly, if someone use the wrapper, he don't want to have to  
>> rebuild the  wrappers.
>> ITK should have a script to be sure that all filters are wrapped.
>>  The other big problem is that it's sometime impossible to build a  
>> pipeline  with the same type, because all the types are not wrapped. I  
>> know that  wrapped all types for all filters would produce a too big  
>> library. A  possible solution would be to make all filters (except cast  
>> filter)  avaible only with the same input and output type. If user  
>> wants to change  type in is pipeline, he must use a cast filter. This  
>> would make possible  to wrap all filters with all types.
>> Some filters (like rescale or label filters) should also be avaible  
>> with  more types.
>>  Comments ?
>>  Gaetan.
>>
>
>
>
>



-- 
Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr>
Tel: +33 1 34 65 29 66
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)