Closed stain closed 7 years ago
@snoopycrimecop and @mtbc - I see you applied this patch on your fork - but did it not cause similar problems at your end?
Is it possible to formulate a test for this supposed memory leak?
@melissalinkert: Any conclusions on https://github.com/openmicroscopy/bioformats/pull/1596 ?
(I'm not sure that we actually ever attempt to write J2K images.)
No, this doesn't affect the writing.. but my test writes and then reads,
and it fails during ImageIO.read
On 2 March 2015 at 12:22, Mark Carroll notifications@github.com wrote:
(I'm not sure that we actually ever attempt to write J2K images.)
— Reply to this email directly or view it on GitHub https://github.com/jai-imageio/jai-imageio-jpeg2000/pull/2#issuecomment-76702995 .
Stian Soiland-Reyes Apache Taverna (incubating) http://orcid.org/0000-0001-9842-9718
@stain/@mtbc - no, we didn't have this problem with https://github.com/openmicroscopy/bioformats/pull/1596. We do make extensive use of JPEG-2000 writing, but ImageIO.read
is never used for reading JPEG-2000 images back - J2KImageReader
is always used directly since our use case typically involves very large images for which tile-wise reading is imperative.
It looks like ImageIO.read
will try to close the underlying ImageInputStream
unless the ImageIO.read(ImageInputStream)
signature is used, but that close happens after the J2KImageReader.dispose()
call. Calling iis.flush()
instead of iis.close()
might help, though I'm not sure how well that would fix the memory leak.
Thanks for explaining.
Do you have some example (test) code of how you use J2KImageReader that I can use to verify the memory leak?
On 3 March 2015 at 02:28, Melissa Linkert notifications@github.com wrote:
@stain/@mtbc - no, we didn't have this problem with openmicroscopy/bioformats#1596. We do make extensive use of JPEG-2000 writing, but ImageIO.read is never used for reading JPEG-2000 images back - J2KImageReader is always used directly since our use case typically involves very large images for which tile-wise reading is imperative.
It looks like ImageIO.read will try to close the underlying ImageInputStream unless the ImageIO.read(ImageInputStream) signature is used, but that close happens after the J2KImageReader.dispose() call. Calling iis.flush() instead of iis.close() might help, though I'm not sure how well that would fix the memory leak.
— Reply to this email directly or view it on GitHub.
Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
I've not heard anything else, so I'll assume this PR is safe to close unmerged. Please let me know if that is not the case! :-)
An update of jai-imageio/jai-imageio-core#2 from @jmabrey
.. but this breaks the build in all tests:
Details: