[Insight-developers] SimpleITK ARB Examples

Gabe Hart gabe.hart at kitware.com
Tue Sep 7 12:45:22 EDT 2010 

Great... the Github repos are:

http://github.com/dblezek/SimpleITK
http://github.com/blowekamp/SimpleITK
http://github.com/gabehart/SimpleITK

Dan's has an example framework for registration, Brad's has the meta 
programming work (in the meta_instantiation branch), and mine hasn't 
been updated that recently so it's not very interesting at the moment.

-Gabe


On 09/07/2010 12:37 PM, Alexandre GOUAILLARD wrote:
> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>
>>>>>>              
>>>>
>>>>          
>>
>>

More information about the Insight-developers mailing list