OpenRndr might be overkill for what I’m trying to do, but its a neat library that I’d like to use.
I have one image (key.jpg), made up of different 16x16 tiles.
I want to examine another image, and compare 16x16 portions of it to see if the section matches one of the tiles from the Key image.
I don’t care about drawing the images.
So, the two basic ways I see to do this:
A) Look at the buffer data in the two rectangles, and do an equals comparison on the data.
What’s the best way to access the raw data of a portion of the image?
B) If I could use the AND operator on the two rectangular data, then if I get an entirely “1” result, there is match.
Is this an easy thing to do with openrndr?
I’m open to being told that I should just use a different library to just deal with bufferdata since I don’t care about drawing.
Thanks (in advance) for tips about openrdr or a better way to do this.
In OPENRNDR by default images are stored in the GPU. You can read about ColorBuffer in the guide.
A simple approach would be to download the images from the GPU to the CPU as a byteBuffer and then compare the bytes one by one.
Another approach which is commonly used to compare images is to subtract them. One can draw one image on top of the other with SUBTRACT mode and if the images are identical one should get only zero RGB values.
Does performance matter in your case? Is it a fixed number of images to compare? or an endless stream of them?
I think what you have in mind can be done either in the CPU or in the GPU. It’s probably easier in the CPU but may be faster on the GPU because it could do many more comparisons in parallel.
Of course, shortly after I posted my question, I solved the problem using javax.imageio.ImageIO for image loading, and java.awt.image.BufferedImage and just do a data comparison.
For me, I think this is the best as I believe (but haven’t tested yet), that this would also run on a headless system without a GPU. I’m just processing an image that is maybe 30x80 tiles (16px x 16px). and there are maybe 40 different tile types to compare against. I think I can also optimize the 40 source tiles by organizing them so that the byte by byte comparison would eliminate non-matches faster. But that might be over-optimizing too soon. With how fast processors are now, I probably don’t need to care at the beginning.
Thanks for mentioning the difference between where the work is done; CPU vs GPU. That isn’t something I’m used to having to think about. If I have time later, I may try the GPU based solution to see how it might compare.
