Hey, everyone. I'm stuck and need some help. Almost two years ago, my company was asked to code a viewer application to create thumbnails on the fly from image files stored in their document library solution. The application I developed worked fine with any format, using JAI. Recently, a problem involving huge JPG files came to my attention, as various managers at this location are suddenly discovering the higher resolution capabilities of their digital cameras. It seems to render random images (and the majority of the ones on a given page, but not always the same ones) as black boxes. I'm taking a wild guess that it's a problem due to the size of the files, but I don't quite know how to fix it. My renderJPEG method is below - I could really use some help if anyone has suggestions, as I'm at a dead end. (This was originally coded using JDK 1.3.1 - we have moved to 1.4.2 on our server (this is part of a servlet), so if you know any optimizations for that, it's safe for us to use it.) Thanks!
[ November 07, 2003: Message edited by: Theodore Casser ]
Theodore Jonathan Casser
SCJP/SCSNI/SCBCD/SCWCD/SCDJWS/SCMAD/SCEA/MCTS/MCPD... and so many more letters than you can shake a stick at!
Since you are now using 1.4 you may want to look at the new javax.imageio package. That may help to solve your problem. You could change your thumbnails to GIFs with a Transcoder or even change the metadata from the JPEGs to a lower resolution if you think that is the problem.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
This may be moot now, but: My guess is that the problem was with this line:
That "null" is supposed to be an ImageObserver which monitors how far along the transformation is. It's an asynchronious API - when this method returns, the transformation has begun, not necessarily completed. If the result were being displayed with a java.awt.Component of some sort, you could use that Component as the ImageObserver, and it would be notified as more data became available, and you might see the image getting updated asynchronously after it was initially displayed. However in this case there's no ready-made Component to use as ImageObserver, so I'd make my own:
I've found that using an observer just really slows the page massively down. (The application displays eighteen thumbnails at a time. :-\ Don't look at me, I just programmed to the requirements.) But it's working now 100% of the time, so I'm happy.
Joined: Jan 30, 2000
I've found that using an observer just really slows the page massively down Well yes, that's the point. You were using an API which requires time to process. If you ignore the ImageObserver, you're basically not waiting to see if that processing is completed. Naturally this makes things faster, but the disadvantage is that some of your images aren't complete. Now the ImageObserver I provided waits for exactly one image at a time. If you're trying to display 18 thumbnails, it might well have been more efficient to process the images in parallel, in which case you might want an ImageObserver that waits until all 18 transforms are completed (but allows the different transforms to process concurrently). The MediaTracker works something like this, but I'm not sure out how to plug it in to monitor the results of an AffineTransform. So I just gave the simplest fix I could see. Certainly since you can use imageio now, that's going to be preferable; I just wanted to clarify what was probably going on in your original code.
Originally posted by Jim Yingst: I've found that using an observer just really slows the page massively down Well yes, that's the point. You were using an API which requires time to process. If you ignore the ImageObserver, you're basically not waiting to see if that processing is completed. Naturally this makes things faster, but the disadvantage is that some of your images aren't complete.
No, no, I agree that ignoring the ImageObserver does somewhat put in the risk of it coming back before the application is done processing. Which is a problem. The larger problem is I have users who don't want to hear that answer and complain more (and louder) about the speed.
So I just gave the simplest fix I could see. Certainly since you can use imageio now, that's going to be preferable; I just wanted to clarify what was probably going on in your original code.
I appreciate that. It helps me understand for the next time I have to do this. Now off to figure out how to speed this up so my users stop complaining....
I'm back. We've encountered a new problem, using the code developed after the above conversation. The code is much quicker now and seems to be working nicely, except... Well, the server is occasionally now throwing an OutOfMemoryException. There isn't any way anyone can think of, perhaps, to better optimize how javax.imageio runs to avoid this, is there? Has anyone had a similar problem?