[Insight-developers] Trying to minimize the memory needed by itkImageFileReader

[Roger Bramon Feixas]

Hi Luis,

Really nice classification. As you said, the common case is A and I agree
with your proposal. However, I suppose it's not a straightforward issue when
the pixel data is compressed (e.g. JPEG) because it has to be decoded. In
any case, it would be nice to know GDCM opinion.

In case B & C, I'm not sure about your approach. I mean, buffer (c) is
already destroyed after ImageIO:Read() because it's allocated inside GDCM
and the object is created and destroyed in ImageIO:Read(). My proposal was
allocate buffer (a) after ImageIO::Read() just to convert/copy buffer (b)
into (a). In that way you've got allocated 2 buffers instead of 3 at the
same time.

Thanks!

Roger


On Fri, Apr 15, 2011 at 1:16 AM, Luis Ibanez <luis.ibanez at kitware.com>wrote:

> Hi Roger,
>
> Looking at the code, there are three cases:
>
> A) When not pixel buffer conversion is needed
>
> B) Conversion is needed due to mismatch of
>     number of components.
>
> C) Buffering is needed because the number of
>     pixels read doesn't match the number of
>     expected pixels.
>
> ============================
>
> In case A, the allocations are, in order:
>
> a) AllocateOutputs()
> b) Inside the GDCM reader.
>
> then (b) is copied into (a).
>
> This seems to be the common case for
> a DICOM reading, and it is only allocating
> two buffers.  Is this the case that gives you
> the most concern ?
>
>
> ============================
>
> In case B, the allocations are, in order:
>
> a) AllocateOutputs()
> b) loadBuffer
> c) Inside the GDCM reader.
>
> Then (c) is copied into (b), and
> then (b) is converted/copied into (a)
>
>
> ============================
>
> In case C, the allocations are, in order:
>
> a) AllocateOutputs()
> b) loadBuffer
> c) Inside the GDCM reader.
>
> Then (c) is copied into (b), and
> then (b) is converted/copied into (a)
>
>
> ===============================
> ===============================
>
> Potential options for saving memory are:
>
>
> Case A:
>
> Tell GDCM to use the ITK output buffer as
> the place to read the image in the first place.
>
> Case B & C:
>
> Destroy the ImageIO after the Read() call,
> or add an API to flush its internal memory.
>
> =================================
>
>
>    Luis
>
>
>
> ------------------------------------
> On Mon, Apr 11, 2011 at 2:24 AM, Roger Bramon Feixas
> <rogerbramon at gmail.com> wrote:
> > Hi Luis,
> > Yes, it's another issue. It's a problem of itkImageFileReader instead of
> > itkImageSeriesReader.
> > Let me know if it's not so well explained.
> > Thanks,
> > Roger
> >
> > On Mon, Apr 11, 2011 at 12:45 AM, Luis Ibanez <luis.ibanez at kitware.com>
> > wrote:
> >>
> >> Hi Roger,
> >>
> >> It this different from what this patch was fixing ?:
> >>
> >> http://review.source.kitware.com/#change,1248
> >>
> >> Please let us know,
> >>
> >>
> >>     Thanks
> >>
> >>
> >>           Luis
> >>
> >>
> >> ------------------------------------------
> >> On Tue, Apr 5, 2011 at 3:32 AM, Roger Bramon Feixas
> >> <rogerbramon at gmail.com> wrote:
> >> > Hi,
> >> > I'm trying to minimize the memory needed at the same time to read a
> >> > DICOM
> >> > file using itkImageFileReader. Basically, the problem is related with
> >> > the
> >> > pixel type chosen. I always use "signed short" because I actually work
> >> > with
> >> > CT and MR but sometimes GDCMImageIO chooses another pixel type and a
> >> > conversion has to be done. It means that when GDCMImageIO is reading,
> 3
> >> > buffers are allocated:
> >> > - Buffer allocated by this->AllocateOutputs(); in
> >> > ImageFileReader::GenerateData() (line 370 of itkImageFileReader.txx)
> >> > - Buffer allocated by loadBuffer = new char[ sizeOfActualIORegion ];
> in
> >> > ImageFileReader::GenerateData() (line 414 of itkImageFileReader.txx)
> >> > - Buffer allocated by reader.Read() in GDCMImageIO::Read of
> >> > itkGDCMImageIO.cxx
> >> > but not all of them are used at the same time. I mean, the memory
> needed
> >> > to
> >> > the outputs is allocated at the top of ImageFileReader::GenerateData()
> >> > when this->AllocateOutputs() is called. However, if a conversion has
> to
> >> > be
> >> > done, this buffer is used after reading since the buffer used
> >> > is loadBuffer.
> >> > Could be possible to allocate the output memory after the reading (if
> a
> >> > conversion is needed)? It would allow us to have 2 buffers instead of
> 3
> >> > at
> >> > the same time and it would be great to minimize memory problems
> reading
> >> > huge
> >> > multiframes DICOM files which are really common.
> >> > I hope you understand my problem.
> >> > Thanks,
> >> > Roger
> >> > _______________________________________________
> >> > 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
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110415/41f78181/attachment.htm>