ArrayOutOfBoundsException when image width not multiple of 8

[hpihkala]

Hi, looks like the utility crashes when the image width is not a multiple of 8 due to a bug in the nested for loops:

height: 1170 width: 1170 total byte length: 173222
pixel offset: 62
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 173160
at org.orphanware.App.convertBMP(App.java:132)
at org.orphanware.App.main(App.java:87)

Easiest workaround is to add or remove a couple of pixels to your image width so that it is exactly divisible by 8.

[hpihkala]

No, that's not it, something else is the problem. Try this image to reproduce the problem: https://dl.dropboxusercontent.com/u/4655232/LQ.bmp

Perhaps it has to do with non-square images?

[asharif]

Thanks for your input. I will test it out!

[hpihkala]

There also seems to be an issue with row/image lengths, could be due to an image not being in the exactly correct file format. I could attempt to fix the above overflows plus improve the program a little, if you don't mind:

1. use Java built-in libraries to read the image pixel-by-pixel instead of reading the bmp format byte-by-byte. This would allow converting images in various formats.

2. perform the conversion to 1-bit color space on the fly, if the original image has a larger color space.

[asharif]

You are more than welcome to clone it and give me pull request if you have time! Thanks!

[asharif]

I think I resolved your issues. I moved to using pixel data instead of raw bytes. You are right the raw bytes version required a bitonal image using only one bit per pixel. This way it's much more flexible. Also, now the program handles many different file types. I've tested png, bmp, gif, jpeg. All work. Just make sure jpeg quality is super high. I don't have a zebra printer with me so if you don't mind pull branch nativeImageAPI and let me know if the resulting GRF are printing ok.

Thanks again for your insight!

[asharif]

Hello again, I wanted to know if this solved your problem and if I could close this ticket? Let me know.

[hpihkala]

Sorry, I have been away for over a week. Back when I raised this issue I did my own quick fixes to resolve the immediate blocker and even implemented some improvements to your program, but I ran out of time before I could come up with a proper pull request. I can test the new branch on a couple of images and see if the output is identical to what I ended up with.

[asharif]

Thanks
On Sep 20, 2013 7:38 AM, "hpihkala" [email protected] wrote:

Sorry, I have been away for over a week. Back when I raised this issue I
did my own quick fixes to resolve the immediate blocker and even
implemented some improvements to your program, but I ran out of time before
I could come up with a proper pull request. I can test the new branch on a
couple of images and see if the output is identical to what I ended up with.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-24814887
.

[hpihkala]

I'm getting some really wild output! The code is a bit hard to read but looks like you're now writing 4 bytes per pixel to the file, while on the Zebra it should of course be just 1 bit per pixel. In my implementation I ignored the alpha channel, calculated a grayscale pixel value using (r+g+b)/3 and then set the pixel to 1 if the value was over 127, otherwise 0. Here's a test image and expected output that prints fine on the Zebra:

https://dl.dropboxusercontent.com/u/4655232/LQ.png
https://dl.dropboxusercontent.com/u/4655232/LQ.grf

I could offer a pull on my version, you can use whichever parts you like. Unfortunately I'm used to cvs so I first need to learn how to do this on GitHub! Please stand by.

[hpihkala]

Pull request created! Use it if you like it. It could definitely use some additional testing, but my image above and "test.bmp" included in the repository seem to convert fine.