ImageIO - uses and information regarding...

Java 2D
#1

I feel like a dummy today.

I am unable to locate references regarding the usages of javax.ImageIO.* and more importantly, why I should be using it.

Sun’s information on their site doesn’t give me what I need.

Any pointers?

(happy that I finally migrate fully to JDK 1.4.1 today! YAY!)

#2

ImageIO is really for image manipulation/transport, not general graphics loading. If you make use of the ImageIO APIs, your graphics will not be hardware accelerated (i.e. Automatic Images) unless you copy them to a VolatileImage. At the same time tho, Toolkit.getImage() won’t load anything bigger than 512x512 (at least on my machine).

Some game based uses for ImageIO:

  • Loading backgrounds that are larger than 512x512 (remember to copy it to a VolatileImage or it’ll be SLLLLOOOWWWW!!!)
  • Instances where you need to extract/manipluate image data (e.g. LWJGL textures).
#3

Okay. You just saved me from making stupid mistakes.

I’m already loading my images into BufferedImages and they load happily. Based on this there is no need to refactor my code to use ImageIO, at least, not the loader code.

In the future I need to write a tool that loads individual images and combines them into image strips so my Ant build script can do this (as opposed to horrible hacked JavaScript scripts I wrote for Macromedia Fireworks). Sounds like this is where ImageIO is useful.

#4

Hey JBanes im not sure you are correct about not being hardware accelerated.

From what ive read, i understood that its only when you call getData() or raster, that the image loses its hardware acceleration.
Also ImageIO will become the standard way to load images soon.

I might be way off the mark here, its just what ive seen. Its always confusing when you want to know excactly what the vm is doing. We need some clarification.

If it matters i always use ImageIO these days. Really like the ability to skip pixels when loading, makes it possible to load thumbnails that actually take up less memory. Life saving feature for my image viewer :slight_smile:

#5

I just checked with 1.4.1_02, and BufferedImages obtained through ImageIO still arn’t elligable for HW acceleration.

I still prefer them over toolkit.createImage though,
afterall, its not much work to copy them to an acceleratable BufferedImage.

Also, images obtained from toolkit.createImage have dodgy ImageProducers, that misbehave with some methods.
The most notable is image.createScaledInstance, which can generate partially corrupt images if called on images obtained from toolkit.createImage.
(I wonder if that bug has been reported…)

On the otherhand, the ImageIO.read() followed by copying it to an acceleratable Image may be slower.
I havn’t timed it.

Another issue that might be worth considering, is that ImageIO in 1.4.0 had a bug that prevented it from reading small image files :o
(I ran into that 1 with my 4k applet racing game :P)

#6

Yeah, we know about createScaledInstance(). It’s not being looked at because this api is pretty old, you shouldn’t be using it anyway for creating scaled copies of the image. Use ‘on the fly’ scaling with drawImage, or cache the scaled version (created with drawImage) if you need to render it a lot.

#7

[quote]Yeah, we know about createScaledInstance(). It’s not being looked at because this api is pretty old, you shouldn’t be using it anyway for creating scaled copies of the image. Use ‘on the fly’ scaling with drawImage, or cache the scaled version (created with drawImage) if you need to render it a lot.
[/quote]
if its known to be faulty and is not recommended for use, perhaps it should be deprecated?

edit

Do you also know that some of the java.awt.image.ImageFilter subclasses demonstrate the same improper behaviour?
(I guess also because they rely on directly manipulating the ImageProducer of the image)