[Insight-developers] A few considerations on SimpleITK

[Luca Antiga]

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