Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #15440

ImageIO/BufferedImage behaving inconsistently from one day to the next.

Show all headers | View raw

I have code that used to work perfectly, which processes images in 
certain ways, and today it suddenly was not working. I hadn't changed the 
code at all. I tracked the problem down to spurious 
IllegalArgumentExceptions being thrown by this code:

public class ImageUtils {

    private static float[] BLUR = {0.1111111, 0.1111111, 0.1111111,
                                   0.1111111, 0.1111111, 0.1111111,
                                   0.1111111, 0.1111111, 0.1111111}
...
    public static BufferedImage blur (BufferedImage img) {
        Kernel k = new Kernel(3, 3, BLUR);
        ConvolveOp co = new ConvolveOp(k, ConvolveOp.EDGE_NO_OP, null);
        BufferedImage dest = new BufferedImage(img.getWidth(),
            img.getHeight(),img.getType());
        co.filter(img,dest);
        return dest;
    }
...
}

This code worked yesterday and fails today with

java.lang.IllegalArgumentException: Unknown image type 0

and a stack trace pointing to the line creating dest.

I did some fiddling, and when loading any PNG image with ImageIO.read, 
the result (after being fed through something that uses reflection to try 
to identify bean-like properties in order to "inspect" an object; one of 
my debugging tools) is this:

java.awt.image.BufferedImage: type = 0 ColorModel: #pixelBits = 32 
numComponents = 4 color space = java.awt.color.ICC_ColorSpace@1bffd0d 
transparency = 3 has alpha = true isAlphaPre = false 
ByteInterleavedRaster: width = 2560 height = 1440 #numDataElements 4 
dataOff[0] = 0

According to the Javadocs, a type of 0 represents "Custom".

There are only two conclusions to draw from this:

1. Overnight, BufferedImage suddenly stopped accepting a type of 0, or
2. Overnight, ImageIO.read suddenly started setting the image type to 0
   instead of something more specific like TYPE_INT_ARGB when loading and
   decoding PNGs.

Neither of these makes much sense, because standard library code is not 
supposed to magically change its behavior like that, and it's certainly 
not supposed to make something that used to work no longer work by 
magically changing its behavior overnight.

Now, when I first wrote the blur method it had had

BufferedImage dest = co.createCompatibleDestImage(img,
    img.getColorModel());

instead. The result had been a blank black image output from 
ImageUtils.blur(foo) no matter what the input looked like. I've now tried 
that again, and suddenly it works.

So, literally overnight and without apparent provocation,

new BufferedImage(img.getWidth(),img.getHeight(),img.getType())

magically started throwing exceptions when it used to work with the exact 
same disk file loaded into img in the exact same way, and at the same 
time,

co.createCompatibleDestImage(img,img.getColorModel());

magically started *working* when it had previously created destination 
images that didn't actually work with the ConvolveOp in question, despite 
the obvious contract of the method named "createCompatibleDestImage".

Can anyone explain these occurrences?

Furthermore, can anyone suggest an implementation of blur that is 
guaranteed not only to work, but to stay working in perpetuity and not 
magically stop working some day? What if the version of blur using 
createCompatibleDestImage suddenly goes back to producing blank images? I 
can restore the other version of the code. Or I can even write

try {
    ; Blur implementation using constructor and .getType goes here
} catch (IllegalArgumentException x) {
    ; Blur implementation using createCompatibleDestImage goes here
}

and this will presumably work even if it randomly toggles between the two 
observed patterns of behavior every Tuesday and alternate Thursday, 
though it'll be an evil, ugly hack. But what if it suddenly jumps to some 
*third* state where *neither* implementation of blur works and I have to 
try something completely new? And what if it changes to something 
unprecedented again after that, and again, and every week forever?

Logically, that shouldn't be possible. But by the same logic *what I've 
already observed* shouldn't be possible, so obviously that logic is 
suspect and I can no longer assume that blur needing a completely novel 
implementation every week, or every day, or even every hour cannot 
happen. Doctors needing completently novel antibiotics to treat staph 
infections not only can but has happened, and happened repeatedly, after 
all, so if something in the JVM has started "evolving resistance" to 
blurring images successfully, for some reason, then the same thing could 
happen there.

So, is there something that is evolving or changing under the hood in how 
ImageIO/AWT operates? And if so, are there any rock-stable guarantees 
regarding the API behavior that I can rely on to implement a blur method 
that will never fail for any valid input image? I'd have thought, from 
reading the javadocs for it, that createCompatibleDestImage was it, but 
that's already been disproved...

Back to comp.lang.java.programmer | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

ImageIO/BufferedImage behaving inconsistently from one day to the next. Fred Greer <fggreer@nospam.invalid> - 2012-06-20 02:31 +0000
  Re: ImageIO/BufferedImage behaving inconsistently from one day to the next. markspace <-@.> - 2012-06-19 19:38 -0700
    Re: ImageIO/BufferedImage behaving inconsistently from one day to the next. Fred Greer <fggreer@nospam.invalid> - 2012-06-20 03:07 +0000
  Re: ImageIO/BufferedImage behaving inconsistently from one day to the next. markspace <-@.> - 2012-06-19 20:22 -0700
    Re: ImageIO/BufferedImage behaving inconsistently from one day to the next. "John B. Matthews" <nospam@nospam.invalid> - 2012-06-20 14:26 -0400
  Re: ImageIO/BufferedImage behaving inconsistently from one day to the next. Patricia Shanahan <pats@acm.org> - 2012-06-19 20:38 -0700
    Re: ImageIO/BufferedImage behaving inconsistently from one day to the next. Fred Greer <fggreer@nospam.invalid> - 2012-06-20 04:08 +0000
  Re: ImageIO/BufferedImage behaving inconsistently from one day to the next. Roedy Green <see_website@mindprod.com.invalid> - 2012-06-20 01:16 -0700
    Re: ImageIO/BufferedImage behaving inconsistently from one day to the next. Joerg Meier <joergmmeier@arcor.de> - 2012-06-20 11:44 +0200
    Re: ImageIO/BufferedImage behaving inconsistently from one day to the next. Fred Greer <fggreer@nospam.invalid> - 2012-06-21 00:22 +0000
  Re: ImageIO/BufferedImage behaving inconsistently from one day to the next. Knute Johnson <nospam@knutejohnson.com> - 2012-06-20 08:39 -0700
    Re: ImageIO/BufferedImage behaving inconsistently from one day to the next. Fred Greer <fggreer@nospam.invalid> - 2012-06-21 00:23 +0000
      Re: ImageIO/BufferedImage behaving inconsistently from one day to the next. Knute Johnson <nospam@knutejohnson.com> - 2012-06-20 21:23 -0700
        Re: ImageIO/BufferedImage behaving inconsistently from one day to the next. Fred Greer <fggreer@nospam.invalid> - 2012-06-21 04:58 +0000
          Re: ImageIO/BufferedImage behaving inconsistently from one day to the next. Knute Johnson <nospam@knutejohnson.com> - 2012-06-21 05:58 -0700

csiph-web