[Insight-developers] One possible framework for Image I/O...

[Will Schroeder]

Hi Parag-

I'm confused on several counts.

1. We agreed early on that we would do minimal file I/O in Insight. This 
was to be left to
     other toolkits. Based on this discussion, it belongs in the interfaces 
directory, not in
     the toolkit proper, unless of course something has changed.
2. Now we have another object factory? I suggest that we use what we have, 
or modify
     what we have, to make it work.
3. Did you solve the problem of streaming? The last we heard this design 
could not handle
     streaming pieces of image, a real issue.
4. The .jpg image was probably not checked in "cvs add -kb" to indicate 
that it is binary.
     I can't read it on my PC.

I'm not trying to be harsh here, I am gratified that good work is being 
checked in. But I would
suggest a several things based on my experience with vtk.

1. Major designs should be described and discussed prior to checking 
anything in. The
     talents of the community are very helpful in refining the design, 
making sure the
     existing code is compact, consistent, and uses what's already there, 
as well as keeping
     everyone up-to-date. Checking in major work without getting feedback 
from the
     community, or at least a portion of the community, is chaotic and bad 
for the software.

2. The CVS repository cannot be treated as a soup pot, the law of entropy 
will ensure that
     the whole thing ends up as mush. It's really important to be zealous 
about what goes in
     and what doesn't or you end up with a confusing mess. Again, 
communicate about the
     appropriateness of a contribution.

3. A serious effort must be made to document and teach others. I like to 
see a succinct description
    of software functionality in the header files as well as on the list 
somewhere. Please don't just point
    to a paper, try to keep in mind there are people with little or no 
background in what you are doing.
    This will help the software become more approachable to our future 
users. A few well chosen
    paragraphs do wonders for people's patience and desire to work with 
software. I realize this takes
    a lot of work, but that's precisely the point: the creator should do 
the work, not the user. Otherwise,
    you end up with impenetrable software.

I think that because we are not co-located, these points are particularly 
important. When we did vtk we
had the advantage that we could run down the hall and yell at someone, get 
yelled at, or ask a question.
I think we're going to have to go the extra yard to communicate if we want 
this to succeed.

I would suggest that in the future, major additions are added to CVS only 
after:
0) Some words motivating the addition and describing its relationship to 
segmentation/registration
     are provided to the community.
1) A thorough description is posted on the list, with sample code.
2) Succinct documentation goes along with the posting. This should include 
examples and/or tests.
3) The potential contribution is raised at the weekly telephone conference 
and discussed, or
     is presented at one of our meetings.
4) Somebody else (outside of your organization) in the consortium backs the 
work.
5) The code meets the style guidelines and compiles on all platforms.
6) Then, and only then, should be the code checked into CVS.

I am sure that I am hurting someone's feelings here for which I am sorry. 
But it's better now than
having a software disaster later.

I welcome comments.

Will