Hashim

There are lots of repeats in the outputs, not really a problem, I've just been tasked with creating a database for all 1M inputs along with their outputs but actually I've already done that and this is optimising for speed for other versions of the tool that have 7, 8 and 9 digit inputs. You're probably right that I'm focusing on the wrong things and should be using a compiled language that will be even faster than the current AutoIT solution, although I'm not sure how much faster since Werty's <1ms is pretty fast and I suppose both would be calling the underlying Windows APIs and DLLs anyways?

This particular tool has 4 digits but it seems the width and height for the capture (88, 32) have only ever included the first 3 digits, I'm not exactly sure how it works but it successfully recognised 1 million outputs so something is obviously working and I don't think that could be the problem either.

This is how I got my current set of coords as well as minusing the coords from the previous version of the script from the program's window area, both result in basically the same range of numbers, those are obviously more or less correct since the screenshot is not miles away, but I've tried almost all combinations of those numbers, so I'm guessing the issue is probably elsewhere. Just in case though, I'm going to manually try every single one of those numbers in combination with each other. Seems like taking this script to the next level will have to involve brute-forcing the coordinates themselves. If none of these still return values other than 1111 then I can't see how the positioning could be the problem.

No need for that, I trust you have everything right, and I agree it's really weird that not even a single output is returning anything other than 1111s. I now have GetHandle working but that doesn't seem to make a difference, so I'll just have to think it through. Feel free to enjoy your dinner in peace, there's no rush, this is all theoretical at this point anyway

This looks really promising but unfortunately I can't seem to reproduce it, are you sure your version is returning good values? When I run it all outputs return 1111 again, although I've experimented with every single posx and posy that's even close. I added screenshot functionality to debug the capture and it looks like it should definitely be close to there. Any idea what might be going on here?

I had already removed the Do loop when I ran the first benchmarks but this is a great catch for the older version. Ultimately shouldn't be an issue though since I also sort, deduplicate and run various integrity checks on the output files using Bash/GNU tools. Interestingly, the latest benchmarks seem to be virtually the same as the previous ones: 000000,20.2162 000001,3.6562 000002,4.666 000003,4.9287 000004,4.9238 000005,5.4529 000006,4.839 000007,4.9723 000008,5.1397 000009,5.2648 000010,4.913 000011,5.4363 000012,3.8289 000013,4.7454 000014,5.255 000015,5.0618 000016,5.3634 000017,4.4406 000018,4.7828 000019,5.1919 000020,4.8406 000021,5.0635 000022,4.9752 000023,5.0518 000024,5.8142 000025,3.8615 000026,5.4087 000027,5.0363 000028,4.255 000029,5.2425 000030,5.3523 000031,4.2784 000032,4.8176 000033,5.4404 000034,5.0938 000035,4.2843 000036,4.0313 000037,4.8468 000038,5.1112 000039,4.5882 000040,5.066 000041,4.6753 000042,5.3156 000043,4.8075 000044,4.4237 000045,5.063 000046,5.2948 000047,4.7343 000048,5.5518 000049,4.84 000050,4.9125 Maybe BitBLT/AutoIT/Windows were already optimising out the changes you made? I also run all my benchmarks with the timer init just before the BitBlit call (or for Nine's original script, the _GetScreen_GetScreen() function), so it's not a measurement of the full loop, in this version the full loop averages about 16 ms. Maybe we're at the point where speeding things up any further would require more advanced optimisations like chunking?

Wow, kicking myself for not thinking of this, so simple yet so genius. I'll test now.

It is a valid result, which is why I need to manually check, otherwise it would be as simple as just making sure it's never "0000" like you mentioned. Currently the incorrect results also return 0000 instead of just returning nothing, which is what I was referring to.

Unfortunately sharing the tool is out of the question, it's an internal tool and even though all the products involved are pretty old, the company is very litigious when it comes to protecting the copyrights - I've already been told off by legal for including too much information in my last thread. The false positives aren't much, a mere 37 in the full set of 1 million inputs, although when scaling it up to 7 or 8 digits, 370 or 3700 would be a lot harder to fix manually - not to mention that just knowing which outputs are wrong requires an extra run to diff against and doubles the time needed. I can confirm that on two different runs none of the false positives were the same, so this doesn't seem likely to be a recognition problem but a problem of the machine's resources being occasionally blocked and the script needing more time to process those particular serials, which is where argumentum's Do-Until loop idea comes in handy. However if it would be too much work to rewrite the script to return nothing instead of those few false positives I understand completely and you've helped enough already, thank you again.

Great catch again, I've now implemented both solutions. Minor nitpick is that WriteFileFromArray doesn't currently support LF line endings so I have to use dos2unix on the output, which I reported as a bug here, but apart from that it works perfectly. Just out of interest, if in the future I wanted to use this to brute-force a larger range of serial numbers (7, 8 or 9 digits instead of 6) the amount of failed cases might get a little too much to handle manually like I am now, and this also requires that I run the script with two different methods and diff both files. Is there an easy way of making it so that the script does fallback to returning nothing instead of 0000 when nothing is recognised, so that I can then bring back the Do Until loop to take a little more time on those particular numbers? If this would require too much work don't worry about it, but if it's an easy change it would be a huge improvement to the robustness of the script. Also as requested I have now donated to AutoIt, thanks once again everyone.

Yes, I ended up removing the Do loop when I realised the same, it was useful to increase accuracy for previous versions of the script that would return nothing when nothing was recognised, but since these latest versions seem to fallback to returning 0000 or 1111 for unrecognised numbers it's no longer necessary. Thanks for the optimisation tips, I knew writing to the file each time was slow but didn't know of a better way to do it, I'll convert it to use an array instead.

Yeah, the tough part was trying to find the right pixel in such a small space but knowing that I only needed to find the right Y axis helped massively and I managed to get this working shortly after. I can confirm it works perfectly, is much faster than expected and even slightly more accurate than Werty's solution: 000000,34.7907 elapsed 000001,33.5822 elapsed 000002,21.6923 elapsed 000003,22.1064 elapsed 000004,22.1113 elapsed 000005,36.8183 elapsed 000006,23.241 elapsed 000007,40.3301 elapsed 000008,35.89 elapsed 000009,37.0641 elapsed 000010,21.9951 elapsed 000011,21.4196 elapsed 000012,38.3739 elapsed 000013,37.8921 elapsed 000014,38.5466 elapsed 000015,36.1872 elapsed 000016,21.8126 elapsed 000017,36.5059 elapsed 000018,21.8542 elapsed 000019,21.7613 elapsed 000020,37.61 elapsed 000021,22.2271 elapsed 000022,36.4784 elapsed 000023,24.7719 elapsed 000024,35.9157 elapsed 000025,36.2146 elapsed 000026,37.1957 elapsed 000027,20.4105 elapsed 000028,20.3534 elapsed 000029,22.0913 elapsed 000030,22.3388 elapsed Thanks so much! Once again the absolute genius of this solution - how fast it is and how concise, with only marginally less accuracy than other solutions - never fails to blow my mind. Just the startup times are double the speed of the screen-scraping method's average run, and after that it gets ridiculously fast: 000000,17.3893 elapsed 000001,19.3955 elapsed 000002,4.952 elapsed 000003,5.7421 elapsed 000004,4.4015 elapsed 000005,4.6038 elapsed 000006,4.3785 elapsed 000007,4.8244 elapsed 000008,4.9788 elapsed 000009,5.0533 elapsed 000010,4.2012 elapsed 000011,4.3916 elapsed 000012,5.0254 elapsed 000013,5.2419 elapsed 000014,4.2951 elapsed 000015,4.4227 elapsed 000016,4.804 elapsed 000017,4.9286 elapsed 000018,3.9473 elapsed 000019,4.7 elapsed 000020,5.8118 elapsed 000021,19.3781 elapsed 000022,4.6165 elapsed 000023,4.7874 elapsed 000024,5.0672 elapsed 000025,4.9123 elapsed 000026,4.8596 elapsed 000027,5.0079 elapsed 000028,4.6646 elapsed 000029,5.0613 elapsed 000030,4.5557 elapsed I did have to fix a similar memory/performance bug as the one I came across in ioa747's script, but once I cleaned up all remaining resources it works perfectly on the entire input range. Thank you, I appreciate yours and Argumentum's explanations and comments a lot. I don't have the time to read through and absorb them right now but if and when I ever do I'm sure I'll find them very useful. @Werty @Nine @junkew@argumentum Thanks to all of you, please send me your PayPal/BMAC links so I can send you those drinks you deserve.

Yes, that's the original thread Thank you for your in-depth explanations, I sort of understand how this particular method of creating each bitmap and comparing them works, which how Werty's earlier script worked, but the part that's way over my head is the latest iteration of his script in my OP, which seems to use a different method entirely and do everything using `DllStructGetData()` and constants like 680 and 16 and 32. I think you might be misunderstanding, the images are just examples, I'm trying to do this using a tool that generates its result in a bitmap font. Apologies for the late reply, but now done and uploaded, thank you! Thanks for the new solution, I had a go at implementing it but can't seem to get it recognising anything, possibly because I don't really understand `$line` and `$column` and how to get them. I'm using the Finder Tool to get mouse position of the topmost line of green pixels, but this gives an X and Y. If I use Y for `$line` (assuming it's a horizontal line), do I use x for `$column`? You said `$column` should be before `$line` but your `$column` value seems to be higher than your `$line` value. No matter what value I experiment with I always seem to get zeroes back: 000000,0000,50.0049 elapsed 000001,0000,54.0431 elapsed 000002,0000,54.8198 elapsed 000003,0000,53.7282 elapsed 000004,0000,56.0365 elapsed 000005,0000,61.0202 elapsed 000006,0000,47.72 elapsed 000007,0000,55.0063 elapsed 000008,0000,53.913 elapsed 000009,0000,54.7191 elapsed 000010,0000,54.0476 elapsed 000011,0000,55.3895 elapsed 000012,0000,55.3364 elapsed 000013,0000,53.8888 elapsed 000014,0000,54.61 elapsed 000015,0000,57.5293 elapsed 000016,0000,52.4981 elapsed 000017,0000,54.5434 elapsed 000018,0000,54.3221 elapsed 000019,0000,55.6746 elapsed 000020,0000,55.1158 elapsed 000021,0000,52.4392 elapsed 000022,0000,73.5602 elapsed 000023,0000,56.2109 elapsed 000024,0000,49.5609 elapsed 000025,0000,56.3362 elapsed 000026,0000,53.4462 elapsed 000027,0000,55.8478 elapsed 000028,0000,53.6302 elapsed 000029,0000,63.1837 elapsed 000030,0000,53.3006 elapsed 000031,0000,59.3485 elapsed 000032,0000,48.4816 elapsed 000033,0000,53.8227 elapsed 000034,0000,54.4319 elapsed 000035,0000,50.9141 elapsed 000036,0000,55.2572 elapsed 000037,0000,53.6521 elapsed 000038,0000,53.3899 elapsed 000039,0000,63.4227 elapsed 000040,0000,48.0815 elapsed 000041,0000,52.6406 elapsed 000042,0000,56.4394 elapsed 000043,0000,54.0514 elapsed 000044,0000,53.8471 elapsed 000045,0000,64.8552 elapsed 000046,0000,63.9074 elapsed 000047,0000,52.5829 elapsed 000048,0000,54.945 elapsed 000049,0000,54.3817 elapsed 000050,0000,55.7925 elapsed examples.zip

Anyone at all? Here's the full script I'm using along with my best-guess attempts to adapt the results and constants for a 4-digit result - like changing $value from 64 to 128 and adding loop+64. The program seems to run fine without errors, but the digits are all being recognised as either 1s or 0s (the first two digits always as 1s). I'm happy to buy a drink or five for anyone that can figure this out since management have realised I'm the only person in the department that can extract the data from these old tools. #include <WinAPI.au3> Run("tool.exe") Local $tool = WinWaitActive("tool", "", 3) $db = FileOpen(@ScriptDir & "\serials.csv", 1) ;Be sure $posx and $posy is pointing at the correct spot! Global $posx = 829, $posy = 456, $result = "", $code[4] ;Lookup table to avoid searching Global $digit[115] = [1,0,0,0,0,0,0,0,0,0,0,0,4,0,0,0,0,0,0,0, _ 0,0,0,0,0,0,0,0,0,0,6,0,0,0,3,2,0,0,0,0, _ 0,0,0,0,0,0,0,0,9,0,0,0,0,0,8,0,0,0,0,0, _ 0,0,0,0,7,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, _ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, _ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,5] For $loop = 0 To 999999 Do $serial = StringFormat('%06i', $loop) ControlClick($tool, "", "TTabSheet1", "primary", 1, 100, 100) $hDDC = _WinAPI_GetDC(0) $hCDC = _WinAPI_CreateCompatibleDC($hDDC) $hBmp = _WinAPI_CreateCompatibleBitmap($hDDC, 34, 20) _WinAPI_SelectObject($hCDC, $hBmp) _WinAPI_BitBlt($hCDC, 0, 0, 34, 20, $hDDC, $posx, $posy, 0x00CC0020) _WinAPI_DeleteDC($hCDC) $result = GetNumber($result) Until ((StringLen($result) = 4) and StringIsDigit($result)) FileWrite($db, $serial & "," & $result & @LF) Next FileClose($db) Exit Func GetNumber($result) Local $code[4] = [0,0,0,0], $value = 128, $pixels = DllStructCreate('dword[680]') DllCall('gdi32.dll', 'dword', 'GetBitmapBits', 'ptr', $hBmp, 'dword', DllStructGetSize($pixels), 'ptr', DllStructGetPtr($pixels)) For $loop = 1 To 680 Step 102 $code[0] += DllStructGetData($pixels, 1, $loop ) = 4278255360 ? $value:0 $code[1] += DllStructGetData($pixels, 1, $loop+16) = 4278255360 ? $value:0 $code[2] += DllStructGetData($pixels, 1, $loop+32) = 4278255360 ? $value:0 $code[3] += DllStructGetData($pixels, 1, $loop+64) = 4278255360 ? $value:0 $value /= 2 Next Return String($digit[$code[0]]) & String($digit[$code[1]]) & String($digit[$code[2]]) & String($digit[$code[3]]) EndFunc

Happy New Year everyone, this is a successor thread of sorts to one from a few months ago, I've now tested @Werty's latest solution from that thread: ;Be sure $posx and $posy is pointing at the correct spot! Global $posx = 1718, $posy = 699, $result = "", $code[3] ;Lookup table to avoid searching Global $digit[115] = [1,0,0,0,0,0,0,0,0,0,0,0,4,0,0,0,0,0,0,0, _ 0,0,0,0,0,0,0,0,0,0,6,0,0,0,3,2,0,0,0,0, _ 0,0,0,0,0,0,0,0,9,0,0,0,0,0,8,0,0,0,0,0, _ 0,0,0,0,7,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, _ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, _ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,5] ;Instead of screencapture_capture() $hDDC = _WinAPI_GetDC(0) $hCDC = _WinAPI_CreateCompatibleDC($hDDC) $hBmp = _WinAPI_CreateCompatibleBitmap($hDDC, 34, 20) _WinAPI_SelectObject($hCDC, $hBmp) _WinAPI_BitBlt($hCDC, 0, 0, 34, 20, $hDDC, $posx, $posy, 0x00CC0020) _WinAPI_DeleteDC($hCDC) $result = Getnumber($result) Func Getnumber($result) Local $code[3] = [0,0,0], $value = 64, $pixels = DllStructCreate('dword[680]') DllCall('gdi32.dll', 'dword', 'GetBitmapBits', 'ptr', $hBmp, 'dword', DllStructGetSize($pixels), 'ptr', DllStructGetPtr($pixels)) For $loop = 1 To 680 Step 102 $code[0] += DllStructGetData($pixels, 1, $loop ) = 4278255360 ? $value:0 $code[1] += DllStructGetData($pixels, 1, $loop+16) = 4278255360 ? $value:0 $code[2] += DllStructGetData($pixels, 1, $loop+32) = 4278255360 ? $value:0 $value /= 2 Next Return String($digit[$code[0]]) & String($digit[$code[1]]) & String($digit[$code[2]]) EndFunc I can confirm it works as well for that tool as his original lockbits solution, and is beautifully concise compared to it. I don't have the time to test on the whole dataset so can't confirm how much faster it is but on the few thousand results I did check it definitely doesn't seem slower or less accurate, so I'll take his word for it that this is now the best solution. The problem now is that I need to do the same thing for a similar but newer internal tool, which seems to have been built by the same dev but uses a completely different bitmap font for its results, and the results are also 4 digits instead of 3. It also seems to be in "italics" so I'm not sure whether this makes the solution impossible or if the bitmaps are still uniform enough for the maths to work. The only really good news is that the font is larger than in the original tool. Would it possible to adapt the maths of this solution to these new bitmaps? If I understood how it worked I'd do it myself, but it's way over my head and so was @AndyG's explanation of it, but I have provided all of the possible digits below and can provide more examples if needed.