• Post Reply Bookmark Topic Watch Topic
  • New Topic

Loading JPG with JAI  RSS feed

 
Alejandro Barrero
Ranch Hand
Posts: 371
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there a way to create a BufferedImage from a file with JAI without using ImageIO.read? With ImageIO.read I am getting java heap exception the third time the code runs.
I would also like to create a BufferedImage from a ByteArrayInputStream (byte[] from a database). here i have the same problem with ImageIO.read.
I am also trying with JIMI but I am having a lot of problems.

Your help will be greatly appreciated.

Alejandro Barrero
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd focus on getting ImageIO to work. It's the standard API for loading/saving images these days; if it consistently throws exceptions that's a bug in the class libraries. Both JAI and JIMI (even more so) are obsolete. Can you post a minimal code example (and the corresponding image) that demonstrates the problem?
[ September 17, 2008: Message edited by: Ulf Dittmer ]
 
Joe Ess
Bartender
Posts: 9429
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's been a long time since I've worked with images, so I whipped up an application to display an image and print memory usage stats to the console:


here's a sample run using JDK 1.6.0_07:


There doesn't seem to be any change in free memory, even after 180 images. Try storing your images in a directory rather than a database and run this app on them. See if it behaves like it does for me.
What JVM are you using?
 
Alejandro Barrero
Ranch Hand
Posts: 371
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ulf:

Yes, I would prefer to use ImageIO.read, but I have problems.

The code that fails is:


The byte[] comes from a database blob, it corresponds to a JPG from a paper sheet that I scanned.
I display the image in a JPanel to draw strings.
With the same byte[] the program runs correctly two times, but fails the third time with a "Java heap" error. The program however continues running for other tasks, so it has memory. I have also tried nextImageReader.dispose() and when i am finished with the BufferedImage I use flush().
TPTP profiler in Eclipse doesn't show memory leaks in my code.
Currently, I am trying to run ImageIO.read(inputStream) in a process with
Runtime.getRuntime().exec(command); I am passing byte[] to the proces with serialization and getting a wrapper for BufferedImage with serialization. Now I am getting a "Java heap" error in the constructor of BufferedImage even though I am using the constructor after the process terminates.

I am at the end of my wits.
but inside the process I am getting
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is the imageReaders/nextImageReader code block supposed to do? I'd leave that out, just like the System.gc calls, which accomplish nothing.

How large are the individual images?
 
Alejandro Barrero
Ranch Hand
Posts: 371
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I am trying to do with nextImageReader.reset() or nextImageReader.dispose() is to clear anything that was created in the reader the previous time. The sise of the image is 1 MB.
 
Joe Ess
Bartender
Posts: 9429
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Look at the code I posted. I don't clear any resources or invoke gc() and don't have a memory leak with JDK 1.6.0_07. Try running your images through that app and see what happens.
Again, what VM does your app use? I tried JDK 1.5.0_06 and saw a very small memory leak, perhaps 1k every couple images. Not enough to crash the app after 180+ images.
 
Alejandro Barrero
Ranch Hand
Posts: 371
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Joe. Your code runs flawlessly in Java 1.6. The difference with my code is that I draw the image in the paintcomponent method of a Jpanel to display the image and after I enter text, which I draw in the glassPane for speed, I draw the text on the image. I have events to re size, move, edit and delete the text, but that's all I do. I just don't know what is the problem.
 
Joe Ess
Bartender
Posts: 9429
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You ran my code on the same images that give you trouble in your app?
Ulf asked earlier how large the images are. The images in my test were 2kx2k JPG's with a compressed file size of around 1.5mb each. What about yours?
Are you using JDK 1.6?
[ September 18, 2008: Message edited by: Joe Ess ]
 
Alejandro Barrero
Ranch Hand
Posts: 371
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wait. I just noticed something. If I don't draw anything on the image, I can reopen it any number of times! The problem occurs when I draw on the BufferedImage. Since I also had the "Java heap" exception with the constructor of BufferedImage, it appears the problem is with BufferedImage after I draw on the image (ImageIO.read uses the constructor).

The following code throws "Java heap" exception on the BufferedImage constructor:


I am going to post this problem in Java in General Advanced.

Thanks to all for your help.
[ September 18, 2008: Message edited by: Alejandro Barrero ]
 
Joe Ess
Bartender
Posts: 9429
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I ran your code against a couple of images. It works with a 1024x768 compressed JPG. It fails against a 2848x2136 image (the only two sizes I have handy), so this is simply a resource management issue.
For example, comment out the int array creation and the b.getRGB() call since you are doing the same thing with BufferedImage n = new BufferedImage() and it works with the 2848x2136 image.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!