top speed expected for loading many images

Java 2D
#1

I have a very stripped down app that just loads jpg images from disc and displays them using page flipping. If the images are pre-loaded into an array and then page flipped, I get 60 fps, the refresh rate.

The bottle neck is loading the images. Without pre-loading them, I only get about 6 fps.

The images are a series of 30 - 1024x768 jpegs. I’ve saved them at 100k/image and 400k/image and they display very close to the same speed, so I don’t think it’s related to IO.

I’m using a simple loading scheme:
Image currentImage = new ImageIcon(currentFilename).getImage();
I’ve read several posts suggesting this is bad, but no examples (that I could understand) showing a substantially faster way (at least 50% faster is needed).

I’m using an 1800 Athlon with a 768 meg of ram and an nVidia 64 meg card. Is around 6 fps about the best I should expect without pre-loading images?

thanks,

morris

#2

I don’t know if its quicker, but have you tried:

javax.image.ImageIO;

ImageIO.read();

Kev

#3

I am in fact using that now, but it only seemed to increase the speed by 10% or so - it currently takes 4.8 seconds to load & display the 30 images.

thanks,

morris

#4

It seems that the JPEG code in the JRE is not done “properly”. I suspect it is written in standard ‘C’, when to do it “right” you must use assembler and take advantage of the vector instruction of MMX,SSE, etc. That is exactly what the MMX instructions were designed for.

I had a video application that sends Motion JPEG frames over the network for remote viewing… I noticed that the JPEG decoding was a huge bottleneck, when I look at any native image viewers they only take a tiny fraction of the CPU time that Java needs to decode a JPEG image.

Intel had a free library that had optimized JPEG codecs. They no longer offer it for free as far as I know, but if you search for Intel JPEG library you might find it. Combined with a little JNI you might be able to decode an image into the WriteableRaster of a BufferedImage… I hate suggesting JNI for stuff that should work in “pure” Java… but until Sun does the JPEG codec properly I don’t know what else to suggest.

You could probably go faster with uncompressed images!

#5

FYI

JMF is the Java standard APi for streaming media, which it sounds like is what you are trying to do.

#6

I tried JMF but it was/is far too unfinished. I was trying to stream audio and video over a 100Mbps LAN - synchronized. I could not. I managed to get it streaming, but the video would play at half speed until the audio was lagged by about 1 minute!! Then the video could suddenly keep up and stay 1 minuted behind the audio. I played with all sorts of buffering settings, tweaked everything I knew to tweak, asked on the JMF mailing list… and got nowhere.
In less time than I spent trying to get JMF to work and coming to the conclusion that it simply doesn’t, I managed to code my own streaming of MJPEG and audio from scratch. It needs a bit higher bandwidth, but it did the trick at the time.
I plan to revisit it at some point to see what sort of latency I would get if I compressed the audio with OGG or something. Because my application is interactive (e.g. adjusting brightness and contrast, audio filter settings of the capture device hich is on a remote machine and viewing the result via the network), I needed minimal delay and preferrably lossless audio so the filters and EQ could be adjusted accurately.

I wanted to use JMF, going in to the project I thought JMF was going to make my life easier… it had the opposite effect.
It seems Sun did not take JMF seriously… I guessed it was probably because it is hard to do video/audio codecs well without native code. Anyway JMF is left as no where near production quality, and last I heard ther was only a single person at Sun even remotely associated with it. He answers about 1 message a month on the JMF mailing list.

It’s too bad, because it could have been a very nice API.

Anyway… after all that critisism… If you just need to play a low resolution animation locally JMF could probably do it. 1024x768 at 60fps is HUGE in terms of full motion video. Normal Standard def TV is 720x486 at 30fps. I’m not sure that JMF coudl handle it very well.

Note that ImageIO happens to have a rather severe memory leak if you reuse the reader. You can work around it by resetting some things between frames, but that has a side effect of totally killing the performance. I think that bug was in 1.4.1, I don’t know if it was fixed in 1.4.2.

#7

Could saving the files as GIFs or PNGs help? Posts I’ve read suggest that they have their own problems in decoding, but I don’t know if they’re as problematical as jpeg…

I’ve also seen posts suggesting saving images as ‘raw’. I’m guessing that that would do away with the decoding, but the image files, I assume, would be in the 2-4 meg size range, bringing IO back into the picture.

Any thoughts on the above?

thanks,

morris

#8

Well… gif has only 256colors and png takes a bit longer to decode (afaik - go and test it :))

And raw… hmm… let’s see…

1024x768 at 60fps

~140mb per second

640x480 at 60fps would be “only” ~55mb per second

#9

[quote]I tried JMF but it was/is far too unfinished. I was trying to stream audio and video over a 100Mbps LAN - synchronized. I could not. I managed to get it streaming, but the video would play at half speed until the audio was lagged by about 1 minute!! Then the video could suddenly keep up and stay 1 minuted behind the audio. I played with all sorts of buffering settings, tweaked everything I knew to tweak, asked on the JMF mailing list… and got nowhere.
In less time than I spent trying to get JMF to work and coming to the conclusion that it simply doesn’t, I managed to code my own streaming of MJPEG and audio from scratch…
[/quote]
A bit off topic, but I’d recommend QuickTime Java for this stuff (unless you’re running on a platform other than Mac/Windows.) It includes the QuickTime streaming stuff.

  • eli
#10

Thanks for all the info & suggestions. I’ll probably look into quicktime as soon as I get a chance.

I think for now I’ll have to do a combination of live rendering and loading pre-rendered images. This whole thing started because I couldn’t render some things (small images composited into full screen images and moved around on the screen at varios levels of composit) fast enough to get a decent frame rate. I’ll try rendering out the images and saving the difficult parts to disk and just blt those in live.

thanks again,

morris