[Insight-developers] ImageIO Streaming
Luis Ibanez
luis.ibanez at kitware.com
Mon Jul 2 11:05:43 EDT 2007
Hi Kent,
This sounds very interesting.
It will make possible to pipe multiple command line executables without
having to send image data to disk.
Were you planning on passing "any" image file format through the socket ?
If so, maybe an option is to write a "socket-stream" adapter class. that
will
make a socket look like an std::stream.
or....
if you were planning on a specific subset of file formats, we could dig into
the code to see how we could give them the double behavior of reading
from a socket or from a std::stream.
Thanks
Luis
-------------------------
On 7/2/07, kent williams <norman-k-williams at uiowa.edu> wrote:
>
> Interesting -- I just wrote an image viewer that accepts image data
> through
> a socket for debugging purposes. I was thinking about using ImageIO to
> stream through the socket. Not only would this provide metadata along
> with
> the image pixels, it would give you the image pixel type conversions
> transparently.
>
> The real problem I saw with the existing ImageIO classes is that they
> generally read the header information in one pass, and the image data in a
> second. The ImageIO classes are also public, so it's possible to get a
> handle on them and call their methods directly.
>
> Some ImageIO classes also use lseek or seekg to jump around the file,
> which
> won't work so well with a stream. Of course, any file format that is
> spread
> across multiple files wouldn't make any sense.
>
>
> On 7/2/07 9:26 AM, "Luis Ibanez" <luis.ibanez at kitware.com> wrote:
>
> > Hi Hans, Doug,
> >
> > After looking closely at the API required for Streaming the
> > readers, it seems redundant to have the CanStreamRead() method
> > along with the DetermingStreamableRegionFromRequestedRegion()
> > method.
> >
> > I suggest we get rid of the first one, and simply call the
> > second one. When a reader cannot stream, it will simply return
> > the LargestPossibleRegion as the Streamable region.
> >
> > This is an unused API, so we shouldn't have any backward
> > compatibility issues by removing the unused method.
> >
> > Please let me know if you see any reason for keeping the
> > CanStreamRead() method.
> >
> >
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.itk.org/mailman/private/insight-developers/attachments/20070702/6ee36318/attachment.htm
More information about the Insight-developers
mailing list