[Insight-users] Handling large datasets

[John Biddiscombe]

> 1) The option of having a reader with multiple
>     outputs seems to be hard to implement.

Ah yes. I was forgetting that in previous multiple filters I've created, all
outputs are generated from a single execute. If separate outputs were
working from different regions each GenerateInputRequestedRegion() would
need to know on which output it was operating and would complicate things
unnecessarily. I'll go with the Battery idea. I didn't want multiple
instantiations of the same reader if I could help it because it'd make file
handles clash, but that seems less trouble than multiple executeinformation
clashes.


> 2) It is likely (quite likely) that a filter in
>     the pipeline will say that for computing a
>     requested region it needs the total largest
>     possible region of its input image. As you

Of course, but what I really meant was that for filters that don't require
the whole region, there's no reason for them to request it. What I was
wondering was whether all filters obey this (when true) and I guess the
answer is no.

> 3) Note that FFT is one of the classical examples
>     of filters that cannot be streamed, because a
>     pixel on the output image depends on *all* the
>     pixels of the input image   :-/

Which is why I picked it as an example. If I request a small region - and
then only want the FTT of that small region, the pipeline shouldn't need to
ask for the whole lot. But I gues I'll need a ExtractRegionFilter to force
the extents of the largest region to be clipped to the requested region.

Thanks for the feedback. I think I have a clearer idea of how to handle
things.

JB