[Insight-users] Re: RE: Re: Importing image data from a byte array
Luis Ibanez
luis.ibanez at kitware.com
Mon Sep 12 08:43:01 EDT 2005
Hi Chris,
Thanks for posting the details about your application.
It is still puzzling to me what good thing you may get from
stroing images in PNG format in memory... but... let's be
pragmatic.. that's what your application does anyways.
Here are two suggestion:
A) Trick the PNG library
If you look at the itk::PNGImageIO class, it uses a helper
class for wrapping the File descriptor of the PNG file.
I would suggest you to modify this helper in order to
create something that looks like a FILE but that actually
points to your PNG buffer in memory.
You could do this by intercepting the buffer of the FILE *
structure, or by creating a variang of the StreamBuffer
C++ class.
Of course that will result in a variant itk::PNGMemoryImageIO
class (or a similar name) so you keep the original PNGImageIO
class.
B) Trick the GD library
On the assumption that this library is Open Source
If is not...
welll..
maybe you shouldn't be using such software :-)
I would guess that GD *at some point* have the image in
a raw format. You may want to explore a way to intercept
the image buffer when it is not compressed in the GD
library and then adapt it to an itk::Image using the
ImageImporter.
Option (A) is probably easier to implement than (B).
Regards,
Luis
--------------------
Chris Farmer wrote:
>
> Hi Luis,
> Here are some of the answers...
>
> 1. Why does the app have in-memory PNG images? Our application calculates several types of images using the GD library (http://www.boutell.com/gd/). The library (or at least the legacy use of the library in our app) stores these images as PNG or JPG in memory. Other aspects of our app are designed to handle in-memory images from external sources (in png, jpg, gif, or svg formats) primarily for the purpose of reporting. (Newer image analysis functionality that we add will probably be using file-based images almost exclusively, so maybe I'm making a big deal out of something that I shouldn't. I'm not certain about this yet, though!)
>
> 2. Do they contain the PNG header info? Yeah. If we dump the bytes to a file, it's a complete PNG file.
>
> 3. Am I trying to simulate a virtual disk? Not intentionally. The app historically deals with in-memory data, and I'd just like to use the data in the format I already have. Also, throughput speed is one of the most important design goals, so that's also a reason to avoid writing a file where it's not necessary.
>
> 4. Why am I expecting to have multiple image types in-memory? Legacy reasons. I will admit though that for most of the more sophisticated image processing that we're going to try to do, those images will almost certainly be on a filesystem somewhere.
>
> 5. How did the PNG data get there? Either from our app via the GD library or from a user's choice of supplying a PNG's bytes to us. I'd like to support this since with any new image analysis functionality, since our application currently is happy to see in-memory images (even though we don't currently do much with them).
>
>
> thanks,
> Chris
>
>
>
> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez at kitware.com]
> Sent: Thu 9/8/2005 5:15 PM
> To: Chris Farmer
> Cc: insight-users at itk.org
> Subject: Re: [Insight-users] Re: RE: Re: Importing image data from a byte array
>
>
>
>
> Hi Chris,
>
>
> Just out of spiritual curiosity...
>
>
> Why is that your application has images in-memory encoded
> in PNG format ?
>
> and...
>
> are they the fidel image of the binary content of a PNG file ?
>
>
> that is, do the in-memory buffer includes the PNG header data ?
>
>
> Are you trying to simulate a virtual disk in memory ?
>
>
> Why are you expecting to have multiple image formats in-memory ?
>
>
> How did the PNG data got to your application without being
> decodes as a raw data buffer ?
>
>
>
>
>
> It may be that you are trying to solve the wrong problem....
>
>
>
> Please share with us some more details of of your application
>
>
> Thanks
>
>
> Luis
>
>
>
> -------------------
> Chris Farmer wrote:
> > Thanks, Luis.
> >
> > I'd like to try to clarify something first here, though. (I feel like
> > I'm beating a dead horse with this topic!) Others have suggested these
> > tutorial topics, and I've looked at them already. I believe my issue
> > is that my data is encoded as PNG, and I somehow need to convert that
> > data into a raw format before I can effectively use the memory buffer in
> > itk. Is this correct?
> >
> > Assuming this is correct...
> > I currently have virtually no experience with itk, so I'm not sure of
> > the best route to make this work. It looks like the PNGImageIO class
> > passes a file pointer into the underlying png library, but the png
> > library also seems to have the capability to accept a function pointer
> > to allow for a custom data reading function. I thought it might be
> > possible to write a new ImageSource class to handle this with the memory
> > buffer. Or modify the PNGImageIO to handle both file sources and
> > in-memory sources. I'd like to be able to handle quite a few encoded
> > formats, so it looks like modifying PNGImageIO and other formats might
> > be the way to go. Do you have any opinions on this?
> >
> >
> > Thanks,
> > Chris
> >
> >
> >
> >
> > -----Original Message-----
> > From: Luis Ibanez [mailto:luis.ibanez at kitware.com]
> > Sent: Thursday, September 08, 2005 4:19 PM
> > To: Chris Farmer
> > Cc: Brian Eastwood; insight-users at itk.org
> > Subject: Re: [Insight-users] Re: RE: Re: Importing image data from a
> > byte array
> >
> >
> > Hi Chris,
> >
> > Please read the ITK Tutorials
> >
> > http://www.itk.org/HTML/Tutorials.htm
> >
> > in particular
> >
> > "Getting Started V: Integrating ITK in your Application"
> > http://www.itk.org/CourseWare/Training/GettingStarted-V.pdf
> >
> >
> > This tutorial describes multiple strategies for passing data
> > between an ITK image and a byte array to and from your
> > application.
> >
> > Some examples on this issue are also presented in the ITK
> > Software Guide
> >
> >
> > http://www.itk.org/ItkSoftwareGuide.pdf
> >
> >
> > in the "Data Representation" chapter.
> >
> >
> > They will show you how to use the existing buffers in memory
> > and use them to build ITK images without having to duplicate
> > the data.
> >
> >
> >
> > Regards,
> >
> >
> > Luis
> >
> >
> >
> > ------------------
> > Chris Farmer wrote:
> >
> >>Hi Brian,
> >>Thanks for the reply. I understand that the PNG (or whatever other)
> >>data that I read in will no longer be specifically PNG. I am happy
> >
> > with
> >
> >>that. My only issue is that my application already has *in-memory*
> >>buffers representing image data in the PNG format. I might be dealing
> >>with thousands of these. It's not clear exactly what I might have to
> >
> > do
> >
> >>with these images at the moment, but let's just assume for now that I
> >>have the simple task of changing the image's format from PNG into TIF.
> >>>From the examples in the itk source distribution, it appears that I
> >>should use the ImageFileReader and ImageFileWriter and set the
> >>appropriate filenames with extensions to read my PNG data and output
> >
> > TIF
> >
> >>data. In my current application, this would mean that I have to write
> >>out my buffer to a file solely to have it read back in by the
> >>ImageFileReader (ultimately the PNGImageIO::Read method). All I want
> >
> > to
> >
> >>do is avoid this step of writing a file. I basically want the logic
> >>that's within the Read method without the requirement that the data
> >>source be a file.
> >>
> >>
> >>
> >>Thanks,
> >>Chris
> >>
> >>
> >>
> >>
> >>
> >>
> >>-----Original Message-----
> >>From: Brian Eastwood [mailto:beastwoo at email.unc.edu]
> >>Sent: Wednesday, September 07, 2005 5:49 PM
> >>To: insight-users at itk.org
> >>Subject: [Insight-users] Re: RE: Re: Importing image data from a byte
> >>array
> >>
> >>Hi Chris,
> >>
> >>Once you have loaded image data through one of ITK's readers into an
> >>itk::Image object, it is no longer specifically PNG data--it's just
> >>image data. For example, you could do all sorts of processing of the
> >>data using an ITK pipeline; you could grab the image data at any point
> >
> >
> >>in the pipeline and display it (e.g. using Qt or VTK); you could
> >>transfer the data buffer to another image library format and do
> >>something there--for example, ImageMagick. For all of this, there is
> >
> > no
> >
> >>need to write intermediary image data to disk. Maybe you can mention
> >
> > a
> >
> >>bit more about what your application is supposed to do, and it's
> >
> > likely
> >
> >>someone on the list has done something similar, or would know the
> >>components to tie together.
> >>
> >>Cheers,
> >>Brian
> >>
> >>_______________________________________________
> >>Insight-users mailing list
> >>Insight-users at itk.org
> >>http://www.itk.org/mailman/listinfo/insight-users
> >>
> >>
> >
> >
> >
> >
>
>
>
> --
> Click on the link below to report this email as spam
> https://www.mailcontrol.com/sr/CcvfUNb6G6np+p0dC0tKvAiLb87MVaJesxbEjw5zlTS7PWHpnDMgTnOSg5NjmC4WaTo7ohvko7X8PIr28gDn7bRCglLKKZaGy3tgtDEiENn1epPDz2v6R5U8Ypc3H4BQxhIN22oeNWjUUNOdSQQU8sACfK6oQcLXhakQ2LBp00aRbGEgYRCHXuq!HOj7jLxhsMfixCLRHHrwTyG8JVnCNbtpSJwB50cG
>
>
More information about the Insight-users
mailing list