[Insight-developers] Why are the PadImageFilters so complicated?

Cory Quammen cquammen at cs.unc.edu
Thu May 26 11:13:02 EDT 2011


I can see that computing the appropriate requested region for a given
output region involves some subtleties, but I'm surprised that the
ThreadedGenerateData implementations are so complex. Currently, the
output region for a thread is divided into different subregions and
appropriate copying or filling in padding values is performed on a
per-sub-region basis. This just seems much more complex than it needs
to be.

Wouldn't it be clearer for each thread to:

Iterate over its output region
  Check whether the iterator index of the output region is within the
input region
  If so, copy the input pixel value to the output
  Otherwise, compute the index appropriate for the padding type and
copy the input pixel value at that index to the output

I suppose one argument could be that iterators must always be used
whenever copying values in ITK. In that case, the only way to do it is
the current sub-region approach. However, MirrorPadImageFilter is
ultimately doing random-access reads from the input, so why not do
random-access reads for the whole process? Doing so would simplify the
code tremendously.

Thanks,
Cory

On Thu, May 26, 2011 at 9:48 AM, Jim Miller <millerjv at ge.com> wrote:
> I expect the complexity is warranted.  But there is probably room to
> improve. I expect mirroring is the most complicated. While the operations of
> pad and mirror sound simple, to properly support streaming in these filters
> is pretty complicated. At is simpliest, for any request for a region on the
> output, the algorithm needs to map that region to the appropriate region on
> the input.
> These filters were also written very early on in ITK history. There are
> probably a few concepts that were introduced afterwards that would have made
> those filters easier to write (things like line iterators and reverse
> iterators).
>
> Jim
> On May 25, 2011, at 6:00 PM, Cory Quammen wrote:
>
> Looking at the PadImageFilter subclasses today, I couldn't help but
> wonder why they are so complicated. There is a note in
> itkMirrorPadImageFilter.txx that says, "The algorithmic complications
> are necessary to support the streaming interface and multithreading."
> Is that still the case?
>
> Thanks,
> Cory
>
> --
> Cory Quammen
> Computer Integrated Systems for Microscopy and Manipulation (CISMM)
> Department of Computer Science
> University of North Carolina at Chapel Hill
> http://www.cs.unc.edu/~cquammen
> _______________________________________________
> 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
>
> Jim Miller
> Senior Scientist
> GE Research
> Interventional and Therapy
> GE imagination at work
>



-- 
Cory Quammen
Computer Integrated Systems for Microscopy and Manipulation (CISMM)
Department of Computer Science
University of North Carolina at Chapel Hill
http://www.cs.unc.edu/~cquammen


More information about the Insight-developers mailing list