[Insight-developers] A few considerations on SimpleITK

[Gabe Hart]

Hi Luca,

Thanks so much for your comments.  This is exactly the type of input 
we're looking for.  All three of your points are great ones and we'll 
take them all into account as we move forward.  I'm particularly glad 
you identified error messages as the primary roadblock as I don't think 
this is something we've discussed much.  We'll make sure to do so moving 
forward from here.

Thanks again!
-Gabe

On 09/13/2010 05:04 AM, Luca Antiga wrote:
> Hi all,
>  I'm following the activity on SimpleITK, and with reference to the 
> Prototype Code Discussions I've seen on the wiki, I'd like to share a 
> few thoughts on how I see SimpleITK. I understood that the developers 
> are seeking input from potential users, so here are my 2 cents.
>
>
> I'm sure many I'm not saying anything new, but probably making things 
> explicit has some value.
>
>
> 1. I've been training people in using ITK in the past, some of them 
> coming from Matlab, others with a basic knowledge of C++ (no 
> object-orientation). With practically all of them, teaching them what 
> an object was and how they could use it was not a big deal (at a user 
> level, I'm not talking about writing new classes). Same thing with 
> pipelines (again, I'm talking about simple, linear pipelines). Even 
> defining templates, they could take it, although they complained about 
> how much they had to write. The one thing that *really* threw them off 
> was the error messages they got from the compiler (related to templates).
> With a superficial knowledge of C++ (at least at the beginning), there 
> was just too much they didn't know and they were learning (C++, image 
> processing, ITK) to make their way in the error messages and they hit 
> a roadblock. And very often there were too little time to teach them 
> everything.
> If SimpleITK could be just ITK but hiding templates away (the Pipeline 
> option in 
> http://www.itk.org/Wiki/ITK_Release_4/SimpleITK/Advisory_Review_Board/Prototype_Code_Discussions) it 
> would be great, mainly thanks to compiler error messages starting to 
> be meaningful for users without C++ skills. And at the same time it 
> would allow them to move towards the "real ITK" in steps.
>
>
> 3. The second consideration is related to another "roadblock" I've 
> seen in users, especially the ones coming from Matlab. Users like the 
> "image as a matrix" perspective, they like to manipulate an image 
> using indexes, extract slices or sub-matrices, extend images, perform 
> arithmetic operations, all simply acting on indexes. Creating a layer 
> close to Numpy's ndarray, for instance (or simpler and less powerful), 
> would help them hacking their algorithms without diving to deep into 
> pipelines (this time seen from the inside) or iterators. Granted, this 
> would lead them creating dimension-dependent code, and I see the 
> dangers behind it, but I think we have to trade cleanness for adoption 
> to some extent. After all, I've see several experienced researchers 
> even at Namic meetings creating their algorithms in Matlab and then 
> moving to ITK, just because it was more comfortable to them. SimpleITK 
> is also about comfort after all.
>
>
> 3. As a last point on the Prototype Code Discussion, I also see that 
> the procedural way (functional, no filter blocks) could be valuable 
> for the occasional user or for the user in a hurry. For this reason, I 
> see functions having a coarser granularity than the Pipelined 
> SimpleITK. The procedures would essentially be pipelines of filters 
> that perform a complete task, rather than procedural versions of 
> individual filters. With this respect, it would be great if they'd 
> coexist with the Pipeline SimpleITK as just another higher level layer 
> (side note: couldn't they be also of use for the Testing 
> infrastructure?).
> As for the issue of having a long parameter list, one possible 
> solution would be to identify a restricted set of important parameters 
> and expose them as arguments to the functions, and to flag the others 
> as "advanced". The advanced parameters would be contained in an 
> object, to be passed as last argument to the functions, that would 
> allow to access and modify all parameters using the enums approach 
> (unlike the exposed ones).
>
>
> Ok, I'll stop, thanks for reading so far, and thanks for your work on 
> SimpleITK
>
> Best regards
>
>
> Luca
>
> _______________________________________________
> 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