[Insight-developers] ImageIO Streaming

[kent williams]

What I have now converts everything to an unsigned char image to send over
the socket.  It isn¹t very sophisticated ‹ I pass the dimensions, spacing,
and orientation down the socket in front of the image data. I use this
information to allocate an itk::Image<unsigned char,3> and then read from
the socket directly into the itk::Image buffer.

It isn¹t that much more work to handle any scalar pixel type ‹ on the server
side, I construct an ITK image and pass it into a vtkKWImage object, which
is then used to pass the image data to a vtkImageViewer2 object.  To handle
all the scalar pixel types, all I¹d have to do is pass an additional flag
through the socket to indicate the pixel type, and then use a switch
statement to select which templated image-builder function to invoke.  It
could also be extended to handle dimension > 3D and non-scalar pixel types,
but those are less immediately useful for debugging purposes.

As for a Œsocket stream adapter¹ -- this isn¹t strictly necessary, since
once you have  a socket open it just looks like a file.

The trickiest part of writing the display program is that in order to
integrate socket data handling into a KWWidgets application, I had to run
some Tcl code to set up the socket server, which then called back into C++
via VTK binding.

With Hans¹ permission I can share the code I wrote.  As much as possible I
leveraged Kitware code to get things done ‹ it uses your vtkKWImage class,
KWWidgets, and the vtkSocket classes.  The vtkSocket classes are just used
on the client side, since on the server side, the socket setup happens in
Tcl.



On 7/2/07 10:05 AM, "Luis Ibanez" <luis.ibanez at kitware.com> wrote:

> 
> 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
>> <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/74bd08e1/attachment.html