[Insight-developers] SimpleITK ARB Examples

Tue Sep 7 12:37:23 EDT 2010

hi gabe,

On Wed, Sep 8, 2010 at 12:13 AM, Gabe Hart <gabe.hart at kitware.com> wrote:
> Hi Alex,
>
> It sounds like we have a lot in common here and we should definitely work
> together.  At this point Dan Blezek, Brad Lowekamp, and I have been
> experimenting with designs on Github.  The trend we were moving towards was
> using meta-programming to keep type lists for managing type instantiation.
>  I think the formation of the ARB was motivated by realizing that we aren't
> sure whether the direction we're going is at all the right one.  It seems to
> me that if we decide to go for a functional approach, SimpleITK will be
> quite different than wrapITK, but if we go for a more granular approach with
> the pipeline, we'll be overlapping quite a lot.  Does this sound about right
> to you?

Yes, that's what we think too.

he meta programming approach sounds interesting. Can you point us to
the github rep ?

> Either way, I definitely think we should work together to see what
> can be re-used.  I don't know if you saw it earlier, but Luis set up a
> SimpleITK tcon for tomorrow (Wed) at 9:00am EST to talk about the ARB.

I hadn't noticed. I will attend, and I will see if gaetan can make it
and let you know.

thanks.

alex.

>
> -Gabe
>
> On 09/07/2010 11:21 AM, Alexandre GOUAILLARD wrote:
>>
>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>