Fast image loading

[Middy]

Struggling with java IO and it seems a bit slow in reading large images.

Is there a fast image loading lib? awt,javax,java2d,java.jai

[Spasi]

javax.imageio.ImageIO.read(), but the speed depends on the image type. If you ever implement a custom image loader (tga and tiff are really simple) then go for NIO/Buffers.

[princec]

DevIL, in LWJGL...

Cas

Games published by our own members! Check 'em out!

[Middy]

Yeah, I considered that one too...

The problem is that java IO is too slow. Its a virtual file system and have to display these images pretty fast (while browsing)

[MasterOfDisaster]

just stumbled across this thread while i was searching for a fast way to load images. i'm currently working on a little photo viewer program and i would like to find a really fast way to load big images (digicam photos). currently loading such an image takes about half a second. i even implemented preloading threads but the performance of the tool is way behind a standard photo viewer tool like the "windows image and fax viewer" app in WinXP. additionally the app uses about 100 megs of ram. seems like i'm soing something terribly wrong 

maybe someone could point me in the right direction. LWJGL was mentioned above but is there really no way to do it with plain java 2d?

[darkprophet]

im sure you can extract the data loaded by DevIL and create a BufferedImage through it somehow...

DP

[MasterOfDisaster]

can you give me a rough estimation of the speed increase i can expect when using DevIL?

[darkprophet]

what you must understand is that DevIL doesnt' do anything special, all it does is load the image. ImageIO does alot of transformations and conversions so that the image is compatible with J2D.

However, those conversions and transformations are infact very time consuming, and with DevIL, I saw a 10x to 20x speed increase if not more. And that is definetly a rough estimation.

DP

[MasterOfDisaster]

cool, i'll give it a try. thanks for the info ...

[swpalmer]

ImageIO does alot of transformations and conversions so that the image is compatible with J2D.

What sort of transformations and conversions?

I have never heard of ImageIO doing any sort of transformations.  Though when I was testing Java 1.4 I did find that the JPEG image loaders (Toolkit and ImageIO) were dog slow.

I assume that the JPEG codec is simply not optimized using assembler and SIMD instructions like a proper image loader.  I've whined about it to Sun, but it doesn't seem to be a priority for them.

Games published by our own members! Check 'em out!

[MasterOfDisaster]

im sure you can extract the data loaded by DevIL and create a BufferedImage through it somehow...

DP

i'm currently struggling with this particular problem but cannot find a solution (ByteBuffer -> BufferedImage) ... 

[Jeff]

I had speed problems at first with JNWN, profiled, and found out it was the imageio TGA loader I was using, which was really really slow.

I wrote my own image loading code instead and got massive performance improvements.

The morla here is not "don't use imageio".  The moral is that any performance work begins and ends with a profile.

[MasterOfDisaster]

but darkprophet was right, DevIL loaded a particular image in 140ms on my machine, ImageIO needed about 500ms for the same image.
the only thing i need now is either
+ a way to converter the ByteBuffer to a BufferedImage or Image in order to draw it with J2D or
+ a way to directly draw the image loaded with DevIL

[swpalmer]

The morla here is not "don't use imageio". 

Um.. Am I the only one that finds it a bit odd that a Sun engineer is specifically stating "don't use imageIO" for loading images because it isn't fast enough, when the soul purpose of that API is to load images?

The moral is that any performance work begins and ends with a profile.

Shouldn't Sun take this advice and *fix* imageIO?  I realize that it has to be a general purpose image loader.. but I don't believe that means it has to be nearly as slow as it is.  The imageIO API should be the the preferred way to load images in most cases.. why have it if everyone ends up rolling their own?

It seems like the same sort of strategy that effectively killed JMF.  Sun comes up with a good thing, drops the ball, and it ends up no good for anyone.

[kevglass]

Um.. Am I the only one that finds it a bit odd that a Sun engineer is specifically stating "don't use imageIO" for loading images because it isn't fast enough, when the soul purpose of that API is to load images?

No no, he said the opposite (after you decode the Jeffese)

The morla here is not "don't use imageio".

The moral here is *not*   -   "don't use imageio" - i.e. don't take as him saying "don't use imageio".

In my experience ImageIO is pretty good until you reach larger images.

To create a BufferedImage from a byte array (or ByteBuffer) use the setRGB() method on BufferedImage. Theres a discussion about it here: http://forum.java.sun.com/thread.jspa?threadID=500995&messageID=2368658

Kev

[swpalmer]

Ah..  I missed the double negative...

Though his conclusion still seems to be at least that TGA loading in imageIO is slow.
My own tests show that JPEG image loading is very slow. (that was with Java 1.4, haven't tested since)
Then there is the thread discussing how PNG loading is broken...

The moral of MY story... "ImageIO needs some attention" 

[Jeff]

Ah..  I missed the double negative...

Though his conclusion still seems to be at least that TGA loading in imageIO is slow.

Yup, though to be fair it wasnt a Sun loader, the imageio we ship doesn t have a TGA loader so iw as using a third party one.

But it was indeed a dog.

My own tests show that JPEG image loading is very slow. (that was with Java 1.4, haven't tested since)
Then there is the thread discussing how PNG loading is broken...

The moral of MY story... "ImageIO needs some attention" 

Probably, though since the loader interface is open and you cna plug them in on the fly, the community could always write its own package of acceleerated loaders.
(I warn you though, they laoder inetrface is huge and pretty complex 'cause they decided they wante to support every weird use case they could come up with.)