Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1228800 at java.awt.image.SinglePixelPackedSampleModel.setPixels(Unknown Source) at java.awt.image.WritableRaster.setPixels(Unknown Source) at sun.awt.image.SunWritableRaster.setPixels(Unknown Source) at DitherMain.<init>(DitherMain.java:34) at DitherMain.main(DitherMain.java:17)

Line 34 is

1

raster.setPixels(0,0,width,height,endPixels);

But I don't see what's wrong with this... does it have to do with storing an ARGB as an int, because I have no idea.It says some array is going out of bounds. 1228800 is the height*width of the test image I'm using, but I don't see what should be out of bounds

I really don't understand what the problem with this code is, but seeing as I've never written something like this before I assume there are probably a lot.In any case, can any of you guys shed some light on this?

setPixels() doesn't do what you think it does. It expects the data to be unpacked, with ARGB in 4 separate ints, not 1. Therefore it's expecting your array to be 4 times the size it is, and throwing the exception.

You're assuming that's what the OP wants, though! @davedes had already mentioned that method. I was simply answering the OP's question / confusion about why he was getting an ArrayIndexOutOfBoundsException.

I usually use the direct data buffer method you mention, but to do so you have to understand the trade-offs between using get/setDataElements() and directly manipulating the data buffer. Namely that get/setDataElements() will perform an extra copy of the data, while direct data buffer access will stop the image from being accelerated by the graphics card. If all the OP wants to do (in the long term) is save the image to a file, then direct access is fine - if the code will eventually be used for repeated drawing to the screen it may not be.

while direct data buffer access will stop the image from being accelerated by the graphics card.

Is there any way to "re-flag" it for acceleration after making some changes to the array?

There used to be. No idea if it still works (maybe someone else knows for sure). Use -Dsun.java2d.allowrastersteal=true or otherwise set that property as early as possible (before Java2d gets initialized by anything). You'll then need to mark the image as dirty every time you modify the array - used to be recommended to draw a 1x1 transparent rectangle on it.

From what I know, every bufferedimage will try and be accelerated after it is drawn some number of times. So if you de-accelerate it, it should eventually be re accelerated as long as you don't change anything on it. Problem is most people want to change things every frame or so which kills performance.

Yay! I got it to work!It takes about 1 or 2 seconds for an image of 960 * 1280, but I don't care about performance. This project is just a hobby project I'm making to filter images.I'm sure there's a much faster way than this, but here's the final codeIt splits every color into RGB components (3 separate arrays) then it codes it into the image in 3 separate "bands"At the moment, it just exports the same image that's imported, but now that I have the RGB arrays at my disposal, I can now edit the arrays to get some cool effects

From what I know, every bufferedimage will try and be accelerated after it is drawn some number of times. So if you de-accelerate it, it should eventually be re accelerated as long as you don't change anything on it. Problem is most people want to change things every frame or so which kills performance.

No, no, no, no and no! If you grab the data array, the BufferedImage is permanently de-accelerated (unless you try the semi-official hack mentioned above).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org