[vtk-developers] Templated filters

Luis Ibanez luis.ibanez at kitware.com
Mon Feb 8 16:25:47 EST 2010


The success or failure of a system, along with its
virtues and defects must be evaluated on the context
of what the software is intended to do.


               ITK is not a visualization library.

   ITK is intended to manage MEDICAL IMAGES


These images do not have pictures of dogs in a backyard,
nor are videos of dancing cats posted in Youtube.

The images that ITK has been designed and built to manage,
have tumors that are in the liver of a real person, they are
mamograms showing calcifications that may indicate a
breast tumor. They are CT scans that have plaque in the
arteries of a person who may have a heart attack tomorrow.
They are images of small animals used for testing
experimental drugs.


Storing that mamogram in an image of 8-bits may be very
convenient and dandy for your lab purposes, and maybe for
publishing more useless papers in any of the Irreproducible
Journals and Conferences that some communities still tolerate,
but that but will prevent  a radiologist from seeing the calcifications,
and may result in sending a woman home with a diagnosis that
"everything is fine" while thousands of tumor cells are replicating.


      There IS a reason why CT scans
      are stored in 16-bits per pixel.

      There IS a reason why mamograms
      are stored in 16-bits.



      Types in ITK are not an inconvenience,
      they are a necessity.


It will be unwise to feed the laziness of developers and
allowed them to make stupid and irresponsible mistakes
with people's medical data by allowing them to cast images
from one type to another without even having to reflect on
why they are doing it.


   Wrapping in ITK is a convenience, not a necessity.

   Wrapping is desirable in ITK for doing:

         A)   Rapid prototyping, and
         B)   Teaching


  It is in that context that we can evaluate whether
  the system satisfy its purpose, and how it can
  be improved in the future.


       Luis


---------------------------------------------------------------------------------
On Mon, Feb 8, 2010 at 3:51 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> 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
>>>
>>>
>>
> _______________________________________________
> 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