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

[Parag Chandra]

Hi Will,

Sorry for the mess. Let me address your concerns in order:

1. I understand that file I/O in Insight is to be minimal. This is why there
is only one concrete implementation of the framework, in the form of a
MetaImage reader, which I placed in the Interfaces directory. I admit that
there are a lot of files that I checked into Common, but in and of
themselves they do little else but define an interface that others must
implement for their specific file types.

2. I felt that itkMaker was necessary because there does not seem to be a
way to use ObjectFactory to instantiate subclasses based on a user-supplied
key value. ObjectFactory seems to use RTTI to automatically determine which
class to instantiate and return.

3. You're correct; I have not addressed streaming at all. This framework is
a work in progress, and since I have no experience with the streaming issue,
I would certainly like to hear others' suggestions on how to handle this.
Bill, I believe you had offered some insight into the matter, so maybe we
should discuss this off the mailing list. In hindsight, checking in a slew
of files was probably not the best way to spark this sort of discussion ;-)

4. I will correct the binary .jpeg issue. The image is just a simple class
hierarchy presented in UML.

I agree, it is important to discuss major additions to the software before
checking them in, particularly when making additions to the base ITKCommon
library. I had checked in a document describing some of my ideas several
weeks ago, but I realize it is asking a lot for people to read through such
lengthy documents, particularly when I am guilty of not doing the same for
others ;-) I have strived to follow the style guidelines, but doubtless
there are some that I have neglected to adhere to. I am sure the question
has been raised before, but is dOxygen, or a similar documentation system,
post-processing source files at regular intervals to automatically generate
some documentation from comments? I found this system to be invaluable last
year in learning how others' code works, and since the documentation is
generated from comments inside the file, the additional work required on the
part of the developer is minimized.

In my defense, I would like to reiterate that I did not modify the
CMakeLists, so I don't anticipate the new files to impact the build process
and hinder anyone else's work. However, since these new files seem to be
causing more problems than they are solving, why don't I just 'cvs remove'
them from the repository for the time being? Let me know what you think.

-Parag

----- Original Message -----
From: "Will Schroeder" <will.schroeder@kitware.com>
To: "Parag Chandra" <chandra@cs.unc.edu>; "insight-Developers"
<insight-developers@public.kitware.com>
Sent: Monday, December 18, 2000 4:56 PM
Subject: Re: [Insight-developers] One possible framework for Image I/O...


> 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
>
>