[Insight-developers] SimpleITK ARB Examples
Gabe Hart
gabe.hart at kitware.com
Tue Sep 7 12:13:11 EDT 2010
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? 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.
-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