[Insight-developers] const inputs in Image Filters

[Lorensen, William E (CRD)]

I suggest we hold off on these low priority items.

First, let's get everything working that is still broken after recent changes.

Next, we badly need IO to support reading multiple files. My preference would be to follow the vtk
image readers/writers which we have been using for years.

Performance of filters is a big problem. For instance, the Daniellson distance filter is still very
slow.
The registration classes are still apparently slow.

That's just the beginning...

Bill


-----Original Message-----
From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
Sent: Tuesday, March 26, 2002 9:15 AM
To: Miller, James V (CRD)
Cc: Insight Developers
Subject: Re: [Insight-developers] const inputs in Image Filters


Jim,

That's a good point !

I totally agree with you in that GetOutput()
should also return a ConstPointer.

As you suggest: a protected GetOutputFoo()
method returning a non-const pointer can be
added for the internal use of the Filter while
letting   GetOutput()   return a ConstPointer.

I'll add that to the filters !


The code duplication in Iterators is an accepted
problem with a very simple solution:    Factorize !

We just need to create a   "IteratorBase" class that
contains the code defining walking algorithm and
derive this class into "Iterator" and "ConstIterator".

The only decision to make there is if we prefer normal
derivation or we go through Functors.  With the Functor
approach we got the maximum code reuse because the
front end Iterators will be templated over the walking
mechanism and we will have only two iterators:

          Iterator     and      ConstIterator

on the toolkit, with a set of Walking mechanisms:

All the walking combinations are obtained by selecting
the appropiated walking functor (or Walker ?).

This will look like:

template < typename TWalkingFunctor >
class Iterator {
};

template < typename TWalkingFunctor >
class ConstIterator {
};

And the Functors (or Walkers ?) will be:

- ImageRegionWalker
- ImageLineWalker
- ImageSliceWalker
- ImageReflectiveWalker
- FloodFillWalker
- ConditionalWalker
- PeanoWalker
- RandomWalker


What option do you prefer:  Derivation or Functors ?


Thanks


Luis


================================================

Miller, James V (CRD) wrote:

>Well, then if you really feel the const inputs are an important
>way the toolkit will be used, then here is another issue:
>
>GetOutput() should also return a const smart pointer. Using your argument for 
>GetInput(), we shouldn't allow anyone to modify the output of a filter. Only a 
>filter should be able to modify its output.  No-one should be allowed to grab the
>output to a filter and modify it without the filter's knowledge. This is the 
>only way to ensure the integrity of the data in the pipeline.
>
>'Course, doing this means that the filter itself will not be able to modify
>its output so either every GenerateData() or ThreadedGenerateData() will 
>have to const_cast the pointer or a separate API (in the protected section 
>of ProcessObject) will have to be created so a filter can get its own output.
>
>In my experience, const gets in the way more that it helps. I would definately
>say that it is harder to properly manage than using traits. Especially when
>you consider the amount of code duplication that just went into the system
>to create Const versions of the various Image iterators.
>
>
>
>-----Original Message-----
>From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
>Sent: Monday, March 25, 2002 6:00 PM
>To: Miller, James V (CRD)
>Cc: Insight Developers
>Subject: Re: [Insight-developers] const inputs in Image Filters
>
>
>Jim,
>
>
>Miller, James V (CRD) wrote:
>
>>Well, I guess the big question is: when are people going to have
>>const images?
>>
>Every time they write a function/method that receives
>an image and does not expect to modify the image !!!
>
>>I haven't had a need for them in any of the code I have written with 
>>ITK. So my opinion is biased away from supporting const images.
>>
>It seems that all this time writing small test programs for
>our collection of 280 test files have make us believe that
>the normal use of ITK will be to write applications of 100
>lines that open a file, read an image, run one filter and
>write the output image to a file.  
>
>I certainly hope that this will not be the normal use of ITK !
>
>We should keep in mind the real use of the toolkit for applications
>that do something useful. Any serious application will be made of
>more than just the main() {}.
>
>If it is done correctly, any real application will have a large amount
>of non-ITK classes with their respective methods and it is to expect
>that parameters passed to these functions will use "const" correctly.
>
>ITK filters will be a minor component of a full fledged application
>and it will be a bit embarrassing to have to tell to these programmers
>that they have to down cast their const-correct applications because
>ITK is lax in const typing.
>
>Keeping const-correctness is not harder than respecting any other type.
>It is not harder than using Traits correctly.
> 
>
>   Luis
>
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers@public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers
>



_______________________________________________
Insight-developers mailing list
Insight-developers@public.kitware.com
http://public.kitware.com/mailman/listinfo/insight-developers