Java image processing - accessing pixel data

[davidthefat]

It is possible to do it. The Image class has a pointer to the jpeg image in memory named "Image". It is a public field and did not catch that it was there the first 2 years. You just decode that data into raw bytes and then you can access as you want to as "pixels".

[JewishDan18]

Originally Posted by davidthefat

It is possible to do it. The Image class has a pointer to the jpeg image in memory named "Image". It is a public field and did not catch that it was there the first 2 years. You just decode that data into raw bytes and then you can access as you want to as "pixels".

This is far, far easier said than done. A jpeg image is by its nature compressed. To access the data, you would need to decompress it, which would take a very long time to do. Instead of only accessing the pixels you need, you would have to access all of them. You can read a little more about it here

https://en.wikipedia.org/wiki/JPEG

[davidthefat]

Originally Posted by JewishDan18

This is far, far easier said than done. A jpeg image is by its nature compressed. To access the data, you would need to decompress it, which would take a very long time to do. Instead of only accessing the pixels you need, you would have to access all of them. You can read a little more about it here

https://en.wikipedia.org/wiki/JPEG

And that is what I was going with. It is not as easy as it sounds.

[sjspry]

If all you can access is the compressed image, then no. You can not access the image data. I ported a JPEG decoder to the cRIO last year, and it did not go well (it worked, but very slowly). I used to think it might work better if done in C++, but now that I know the cRIO has an onboard FPGA, I would bet that it does the decoding.

[Patrickwhite]

It's worth mentioning that we've found that calling certain NI C/C++ functions from Java is very slow. I find it surprising that it hasn't yet been mentioned that the image classes, namely BinaryImage has a very useful set of methods beyond finding ellipses - the particle report methods. Each "blob" in a binary image is considered a particle, and the particle report allows you to access important properties of each particle, like its position, size, number of pixels in the particle, etc.

[Greg McKaskle]

The jpeg decoder on the cRIO is part of IMAQ. It is pretty standard consortium code and does not run on the FPGA, but runs on theFreescale processor.

Greg Mckaskle

[JewishDan18]

Originally Posted by Patrickwhite

It's worth mentioning that we've found that calling certain NI C/C++ functions from Java is very slow. I find it surprising that it hasn't yet been mentioned that the image classes, namely BinaryImage has a very useful set of methods beyond finding ellipses - the particle report methods. Each "blob" in a binary image is considered a particle, and the particle report allows you to access important properties of each particle, like its position, size, number of pixels in the particle, etc.

Which functions in particular are you having slow results from? I got slow results from the getOrderedParticleAnalysisReports, but the slowdown was on the java end.

[Patrickwhite]

I tossed together a quick sample that retrieved the image from the camera, did a threshold, a convex hull operation, and got the particles, and sorted them by area. The first three of those were done with the BlockingFunction protoyped methods. The whole operation was clocking in at around 400ms with nothing else running on the robot.

[Greg McKaskle]

What size image was this, and did it include decoding the image?

Greg McKaskle