[Insight-developers] SimpleITK ARB Examples

Tue Sep 7 11:21:55 EDT 2010

hi gabe.

I think making an ARB to get feedback for the community we code for is
the right thing to do. Only feedback on which types are needed is a
much precious information we are also longing for.

Going from templated to templateless C++ boils down to an
instantiation problem. Choosing which type to support, for which
filter, is a technical problem you have in common with wrapITK. The
types for images are most certainly not the same as for the meshes,
and for the level sets / registration to cite a few. I think gaetan
has been through and through those problems over the past 10 years or
so. It does not depends on what you do with the instantiated filters
then, wether you "wrap" them into C++, or in other languages (python,
java, C#).

Then, wether you have  simple layer or a template-less layer (wether
it is simple or not), you still have to wrap it. The language targets
we spoke about in washington where python (2.x and 3), java and C# as
"first citizens" we would actively support. Again, to avoid
maintenance burden, if the solution used by wrapITK and working today
is enough for what we want, why adding another technology? Namely,
automatic generation of .i and automatic compilation.

Lots of complains heard about wrapITK were based on currently included
wrapITK 2.0. Specifically, the one I heard most often were: it was
slow, it generated too big binaries, and each modification triggered a
full recompilation. Most of those are addressed, *today* in wrapITK
0.3 which use newer, native swig, and a modular approach to not only
recompile only part of the code (only at the module level, not the
full library), but use/load the module on-demand in python/java making
it faster to load. AFAIK, not one single tehcnology available today
support wells those 3 langages. Mummy is great for C# (it is said to
be better to swig in that specific case), some other technologies are
better at wrapping in the specific langage, but on the long run, I
would much rather go for an unified approach, giving us only one
technology to support. Also, With the help of the community, swig
supporting so many langage, our hopes are high that many more
languages could be passively (read: by effort of the community)
supported.
   On a side note, using PIMPL design in ITK could also (whatever the
wrapping technology used) improve compilation time dramatically,
sometimes even removing the need for recompilation of the wrappers.

all this to say. let's not waste effort and let's work together. I
would suggest you include Gaetan, and maybe myself in the technical
discussion. Note that brad K. also spend sometime going through the
0.3 version of wrapITK to double check the points I listed above and
could also act as a technical expert to the ARB, with gaetan.

regards.

alex.

On Tue, Sep 7, 2010 at 11:01 PM, Gabe Hart <gabe.hart at kitware.com> wrote:
> (sorry if this is a duplicate... got an error when sending)
>
> This is definitely a good question and I think it's one of the main points
> of design discussion at this point.  The two main options at the moment are
> a functional "Matlab-like" style and a template-less "VTK-like" style.  The
> later would be much closer to what is currently being done with wrapITK, but
> would provide a c++ layer.  You make a good point that if this is the model
> we go with, wrapping it may be mostly redundant.  I think the primary
> concern with going for a fully functional approach is that it will not be
> useful for writing real applications.  This, I believe, is the goal of the
> ARB in that we want to figure out which of these options the potential new
> users prefer (or perhaps to find some middle ground).
>
> -Gabe
>
> On 09/07/2010 10:30 AM, Alexandre GOUAILLARD wrote:
>>
>> hi gabe,
>>
>> I understand, I just meant the global granularity of simpleITK was
>> supposed to be much less than itk itself. If you wrap each class (or a
>> subset of classes, but still at the class level, and not the
>> functional level) then, it is not worth having 2 API (simpleITK,
>> wrapITK) at the same level of granularity, with two instantiation
>> mechanisms and two wrapping solutions. Not only would we duplicate the
>> effort, but the maintenance would be a nightmare.
>>
>> I am a fan of the functional level, not only for teaching but also for
>> building applications, and the example given by hans at Washington, on
>> reading images, and the need for the slicer community, was IMHO spot
>> on. If there is not going to be any functional layer, I'm concerned
>> it's not going to be "simple" ITK anymore.
>>
>> alex.
>>
>> On Tue, Sep 7, 2010 at 10:25 PM, Gabe Hart<gabe.hart at kitware.com>  wrote:
>>
>>>
>>> I think there are two major points that are somewhat independent in this
>>> last example (Enum approach).  The first is the use of enums for
>>> parameter
>>> setting so that rather than having a gaussian.SetSigma(2.0) function, you
>>> have a gaussian.SetParameterFloat("Sigma", 2.0).  The second is
>>> maintaining
>>> the granularity of the optimizer, metric, transform, and interpolator.
>>>  I'll
>>> add a note to this effect to the wiki.
>>>
>>> -Gabe
>>>
>>> On 09/07/2010 10:20 AM, Alexandre GOUAILLARD wrote:
>>>
>>>>
>>>> hi guys,
>>>>
>>>> I also think that pointed out examples help grasp the concept more
>>>> precisly and is a very good idea.
>>>>
>>>> Now, it looks to me that 3 possible implementations are illustrated,
>>>> and I fail to see the difference between the latest one (with the
>>>> finest granularity) and the current implementation using wrapITK. If
>>>> you don't provide a simple (fonctionnal, matlab-like) layer, and
>>>> provide a class granularity, with manual instanciation for a given set
>>>> a types, then, a solution exists, right?
>>>>
>>>> What am I missing?
>>>>
>>>> alex.
>>>>
>>>>
>>>> On Tue, Sep 7, 2010 at 9:22 PM, Gabe Hart<gabe.hart at kitware.com>
>>>>  wrote:
>>>>
>>>>
>>>>>
>>>>> This looks great.  I think it makes a lot of sense at this phase to
>>>>> focus
>>>>> on
>>>>> end user examples rather than putting too much time into complex sample
>>>>> implementations since there are numerous different design possibilities
>>>>> that
>>>>> could take a lot of time to code up and ultimately end up being
>>>>> discarded.
>>>>>
>>>>> One further thought I have for the collection of examples on the wiki
>>>>> is
>>>>> to
>>>>> include a few notes about each one that highlight the pros and cons of
>>>>> the
>>>>> given approach.  For example, maintaining the pipeline structure will
>>>>> allow
>>>>> for a much easier implementation of streaming which may not be
>>>>> immediately
>>>>> obvious to a potential user scanning the example.
>>>>>
>>>>> Also, it looks like there has been a stand alone page made for the
>>>>> examples
>>>>> at:
>>>>>
>>>>>
>>>>> http://www.itk.org/Wiki/ITK_Release_4/SimpleITK/Advisory_Review_Board/Prototype_Code_Discussions
>>>>>
>>>>> -Gabe
>>>>>
>>>>> On 09/03/2010 04:07 AM, Dan Mueller wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I have some other ideas regarding registration. Unfortunately it is
>>>>>>           »
>>>>>> difficult for me to attend t-cons to share these ideas. I have not yet
>>>>>> finished the example implementation, so I have added the expected
>>>>>> end-user example to the wiki page.
>>>>>>
>>>>>>
>>>>>>
>>>>>>  http://www.itk.org/Wiki/ITK_Release_4/SimpleITK/Advisory_Review_Board#Enum_approach
>>>>>>
>>>>>> Regards, Dan (Mueller)
>>>>>>
>>>>>> On 2 September 2010 22:55, Gabe Hart<gabe.hart at kitware.com>
>>>>>>  wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> First off, sorry to have missed the tcon on Tuesday.  It sounds like
>>>>>>> some
>>>>>>> important decisions were made, particularly the formation of an
>>>>>>> advisory
>>>>>>> review board for SimpleITK.  I talked to Luis today who suggested
>>>>>>> that
>>>>>>> in
>>>>>>> order to move forward with the ARB, we needed some concrete examples
>>>>>>> to
>>>>>>> show
>>>>>>> the reviewers for the different possible designs of SimpleITK.  In
>>>>>>> that
>>>>>>> vein, I set up a section of the Wiki to collect these examples.
>>>>>>>
>>>>>>> http://www.itk.org/Wiki/ITK_Release_4/SimpleITK/Advisory_Review_Board
>>>>>>>
>>>>>>> I've added a few examples for the gaussian filter and registration
>>>>>>> use
>>>>>>> cases.  I think the registration case needs some more examples that
>>>>>>> demonstrate the possible range of flexibility for SimpleITK's
>>>>>>> registration
>>>>>>> framework (adjust the transform type, adjust the optimizer, etc...).
>>>>>>>
>>>>>>> Feel free to add new examples or edit the existing ones.  Hopefully
>>>>>>> we
>>>>>>> can
>>>>>>> get this to cover the full range of possible user interface
>>>>>>> paradigms.
>>>>>>>
>>>>>>> -Gabe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Kitware offers ITK Training Courses, for more information visit:
>>>>> http://kitware.com/products/protraining.html
>>>>>
>>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>