[vtk-developers] Templated filters

David Gobbi david.gobbi at gmail.com
Mon Feb 8 15:51:06 EST 2010


Hi Bill,

My opinion of of ITK's use of templates is that it is a bit overdone.
I prefer limiting templates to static methods and simple helper
classes.  In ITK, generic programming has been used as a sledgehammer.

All the programs that I write are visualization applications that have
to be ready to take any data type that the user throws at them, so any
use of ITK means instantiating the templates over all relevant types.
I like that in VTK, all of this is already done for me.

Back on topic, though, I think that an automatic method of wrapping
VTK around ITK classes would be wonderful.  I'm working with an MSc
student right now on a vaguely similar project... we are trying to use
a modified WrapITK to generate visual Simulink blocks for all the ITK
classes.  Right now we have manually generated Simulink blocks for a
large number of ITK classes, and all are type-specific.

   David


On Mon, Feb 8, 2010 at 1:21 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> David,
>
> I agree with both Will and you. ITK wrapping has been a failure.
> Successful use of ITK inside VTK is done by wrapping ITK into VTK
> classes. We call the vtkITK classes and have done this successfully
> over the years. However, the wrapping has been done manually.
>
> As for templates, I disagree with Will. I think it makes the algorithm
> code more readable and promotes generic programming. I wish VTK were
> more like ITK...
> I do like ITK's use of templating even though it inhibits wrapping. I
> wish VTK could make more use of templates, but as we know, wrapping
> inhibits this. I really don't miss writing tcl code. I prefer C++
> these days for both VTK and ITK.
>
> Bill
>
> On Mon, Feb 8, 2010 at 3:02 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> Hi Will,
>>
>> I'm sure this has come up before, but it seems like an ideal way to
>> provide a typeless layer for ITK is to wrap ITK into a collection of
>> VTK classes.
>>
>> One issue with any typeless layer for ITK is that it will be almost as
>> big as the ITK wrappers.  The weight comes from instantiating all
>> those templates.  VTK's image filters have the advantage that only the
>> Execute methods are templated.
>>
>> In any case, I hope that the ITK typeless layer will resolve types via
>> virtual method calls, rather than by the huge switch statements that
>> VTK uses.
>>
>>   David
>>
>>
>> On Mon, Feb 8, 2010 at 12:44 PM, Will Schroeder
>> <will.schroeder at kitware.com> wrote:
>>> ITK provides an interesting case study w.r.t wrapping.
>>> When the project began 11 years ago, the designers went extreme and jumped
>>> headlong into templating. While the system is very successful overall, the
>>> use of wrapping IMO has been a failure. There are a lot of reasons, but a
>>> few that stand out are
>>> 1) somebody somewhere has to decide which templates are to be instantiated,
>>> in ITK we generally choose many native types (e.g., char, short, long,
>>> float, double, etc.) and 2 and 3 dimensions. When wrapped this created
>>> massive libraries.
>>> 2) the wrapped classes end up having awful names reflecting their
>>> instantiation choices, e.g.  itkOtsuThresholdImageCalculatorUS3 (US3 meaning
>>> unsigned short, 3 dimensions).
>>> 3) the resulting "scripts" (e.g., in python) ended up being specific to an
>>> instantiation, e.g., a script would specifically handle a type and dimension
>>> (unless the script was manually unrolled to handle multiple permutations of
>>> template parameters).
>>> 4) Some users found templates hard to understand and use.
>>> I have heard a lot of criticisms of ITK (as well as many compliments of
>>> course) but the one that sticks with me was "I like ITK except I wish it was
>>> VTK".
>>> And very recently, the National Library of Medicine is in the middle of
>>> awarding a RFQ to create the next generation ITK v4. One of the major
>>> requests by the NLM is to create a "typeless" layer akin to VTK so that
>>> users can write applications where they don't have to worry about type and
>>> instantiations quite as much.
>>> Will
>>>
>>> On Mon, Feb 8, 2010 at 1:50 PM, Timothy M. Shead <tshead at sandia.gov> wrote:
>>>>
>>>> Berk Geveci wrote:
>>>>
>>>>> There are some other exceptions (for which we don't have a solution
>>>>> for wrapping). See the new array classes vtkTypedArray,
>>>>> vtkSparseArray, vtkDenseArray. My expectation that these classes will
>>>>> never be wrapped.
>>>>
>>>> This may be just be me, but my hope is that we can come-up with a
>>>> more-flexible wrapping mechanism to handle these sorts of special-cases.  As
>>>> a real-world example, I've used Boost.Python to wrap templated container
>>>> classes for other projects.
>>>>
>>>> Cheers,
>>>> Tim
>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>>
>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>
>>>
>>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>>
>



More information about the vtk-developers mailing list