SRL Archive - Research & Development Lounge

This article explains how and why GetPixel is so slow
http://en.morzel.net/post/2011/04/05/Why-the-use-of-GetPixel-and-SetPixel-is-so-inefficient!.aspx

This article explains an implementation on how to substitute GetPixel
http://www.codeproject.com/Articles/617613/Fast-pixel-operations-in-NET-with-and-without-unsa

This image is pretty cool:
http://en.morzel.net/pics/PostImg/victorias_900x506.jpg

Now, I don't know much about graphics, so I was lead to believing that reading a screen took so much time, that in order to implement real time screenscraping, you needed to lose accuracy with that weird SPS implementation that compares the sum of all colours within an array of pixels, rather than comparing pixel by pixel.
Apparently it is not needed.
This guy made a program that read and created an image mask from a 7680x4320 HD image in 360ms.
If instead of using GetPixel we used the method described in the article, perhaps we could search for color from a screen scrape fast enough to avoid using SPS' 'Areas', which cause so much inaccuracy.
If you don't know what I'm talking about, try using simba's getcolor for every pixel on the screen to create a bitmap ( if you don't know how, just save The color value of each pixel in an array).
You'll see how long it takes, it shouldn't take so long.

Very interesting read. I'd like to hear Dgby714 and masterBB's input on this.

Edit:
…and Ben's input as well; he did some very nifty work on a canny core some time back.

Lol.. -__-

1. Simba doesn't use GDI's "GetPixel" function like that guy is doing in the article. No one in their right mind would try searching a bitmap doing so. You can even view the benchmarks from: http://www.rohitab.com/discuss/topic/36376-getpixel-is-slow/

The offset of a pixel in an image can be calculated by doing:

[(height - 1 - I) * width + J] <--- If Flipped.
[I * Width + J]                <--- if not flipped.

Simba uses the "Flipped" version because it avoids the overhead of having to flip the bitmap/image and then read the colours. It just reads them flipped using the above offsets instead. Personally, I flip the image because PNG's are not flipped and I flip the bitmaps to match the PNG's. At some point in time, Simba has to choose whether to flip the bitmap or flip the PNG. Either way, the overhead of flipping a massive image is around 0.003 ms on my machine. If you ask me, that's almost nothing.. Mind you my machine is pretty slow :l

Simba stores all the pixels of the image into an array of RGBA structs and whenever you call a finder function, all it does is search the array using the above.

2. Simba already uses that Pythagorean formula for calculating pixel matching with a tolerance. We call it CTS 1, 2 and 3. Also uses different colour spaces. CIE-LAB, RGB, XYZ, etc..

3. That guy's algorithm is slow -__- who in the world reads a bitmap/image like that.. I hate when someone who knows little about optimization writes an article.. Gets me in a frenzy. That one has some truth to it but it's misleading as well.

4. Marpis uses Colour boxes for SPS because he's not calculating pixel accuracy to the nearest pixel. He's calculating pixel accuracy in percentage. This allows SPS to "ignore" Minimap Icons, Minimap Dots, etc.. It goes by the amount of boxes matched and if the percentage is >= 66 which was the default last I checked, then it is match. It'll then find your position within the matching areas. You can already set the accuracy for SPS within the file itself. It allows you to change the percentage and other parts of how SPS operates.

5. Read Simba's source :S The only program that looks at a pixel one by one is Smart's Debug graphics. It processes each pixel one by one. If the pixel is black (aka the transparent colour by default), then it does not draw it on the overlay. Otherwise, the pixel is drawn. However, since it is an overlay, the overhead isn't too much considering that Smart is at iunno.. 765x553 in dimensions? Still, it's not much of an overhead because it isn't doing any calculations and it's probably optimized by the JVM. Only way to get rid of it is to allow Simba/Smart to simply use the alpha channel instead of plain old bitmaps.

From: Brandon
Lol.. -__-

1. Simba doesn't use GDI's "GetPixel" function like that guy is doing in the article. No one in their right mind would try searching a bitmap doing so. You can even view the benchmarks from: http://www.rohitab.com/discuss/topic/36376-getpixel-is-slow/

The offset of a pixel in an image can be calculated by doing:

[(height - 1 - I) * width + J] <--- If Flipped.
[I * Width + J]                <--- if not flipped.

Simba uses the "Flipped" version because it avoids the overhead of having to flip the bitmap/image and then read the colours. It just reads them flipped using the above offsets instead. Personally, I flip the image because PNG's are not flipped and I flip the bitmaps to match the PNG's. At some point in time, Simba has to choose whether to flip the bitmap or flip the PNG. Either way, the overhead of flipping a massive image is around 0.003 ms on my machine. If you ask me, that's almost nothing..

Simba stores all the pixels of the image into an array of RGBA structs and whenever you call a finder function, all it does is search the array using the above.

2. Simba already uses that Pythagorean formula for calculating pixel matching with a tolerance. We call it CTS 1, 2 and 3. Also uses different colour spaces. CIE-LAB, RGB, XYZ, etc..

3. That guy's algorithm is slow -__- who in the world reads a bitmap/image like that.. I hate when someone who knows little about optimization writes an article.. Gets me in a frenzy. That one has some truth to it but it's misleading as well.

4. Marpis uses Colour boxes for SPS because he's not calculating pixel accuracy to the nearest pixel. He's calculating pixel accuracy in percentage. This allows SPS to "ignore" Minimap Icons, Minimap Dots, etc.. It goes by the amount of boxes matched and if the percentage is >= 66 which was the default last I checked, then it is match. It'll then find your position within the matching areas. You can already set the accuracy for SPS within the file itself. It allows you to change the percentage and other parts of how SPS operates.

5. Read Simba's source :S The only program that looks at a pixel one by one is Smart's Debug graphics. It processes each pixel one by one. If the pixel is black (aka the transparent colour by default), then it does not draw it on the overlay. Otherwise, the pixel is drawn. However, since it is an overlay, the overhead isn't too much considering that Smart is at iunno.. 765x553 in dimensions? Still, it's not much of an overhead because it isn't doing any calculations and it's probably optimized by the JVM. Only way to get rid of it is to allow Simba/Smart to simply use the alpha channel instead of plain old bitmaps.

Just to add onto this^, O god… .Net, why would you think Simba has anything to do with any of that?

From: Dgby714
O god… .Net, why would you think Simba has anything to do with any of that?

And your point with that statement is…???

From: Daniel
And your point with that statement is…???

How does one hear .Net and jump to Simba? I mean we have Get and SetPixel (kinda), and maybe that caught his eye, but all the code examples are nowhere close to Pascal.