Failed to perform quickscan - only immediately after catch

[ghost]

I almost always get a "Failed to perform quickscan" immediately after I catch a pokemon, but if I open the favorite/appraise/transfer menu and then close it again, the quick scan works. It also works if I exit the pokemon screen after catching and then enter it again via my pokemon storage menu. Why does it consistently fail immediately after a catch but not at other times?

GoIV 3.5.0 on Android 5.1.1.

[nahojjjen]

I've observed that for some pokemon the "+1 candy" message that pops up in the top right covers part of the CP.

[AndrewMcQuerry]

Also, no need to open the PoGo menu and close it.. simply tapping on any part of the screen that is not an active button or input will tell GoIV to "check if I'm looking at a Pokemon".

In addition, I believe that nahojjjen was recently playing around with the timing/sequencing of that part of the code to both allow the IV button to appear as fast as possible, while also being forgiving enough for the animations/transitions that PoGo has in between screens.

[ghost]

I've observed that for some pokemon the "+1 candy" message that pops up in the top right covers part of the CP.

That makes sense, but it doesn't explain my case. As you can see, those messages are not covering anything that should be required for scanning.

Here's the same pokemon scanning successfully on my second attempt:

Maybe the catch reward messages are interfering because they happen to overlay part of the level arc, even though they don't touch any important part of it? If so, I expect GoIV could be made to handle this.

[AndrewMcQuerry]

Looking at the code, the simplified logic of how we detect the white dot is, "look for the first reduction in white pixels around a given X,Y coordinate".

In further detail:

• Start at the end of arc (far right).
• Count how many white pixels there are in the cardinal directions from the given X,Y coordinate that corresponds to the highest level a pokemon could be.
  • ie: is X,Y white? if yes, is X+1,Y white?, if yes, is X-1,Y white?, .... we then look at the next coordinate away (X+2,Y; X-2,Y; X,Y+2; X,Y-2). .. This continues until we find our first non-white pixel. A counter is incremented each time we progress to a new distance.
  • If no white pixels are found, simply decrement the possible Pokemon level (new X,Y) and check again.
• Finally, we go ahead and check the NEXT level coordinates to see if the white pixels around that X,Y is "less" than the number of pixels around the previously found level.

Thus, in your example, when GoIV sees the "D" covering the level arc, the white pixels in that area are greater than the number of white pixels for the next level down (just above and to the right of the "D").

For my tests on various pokemon, the white pixel counter was coming back with a value of 10 or 11 for the location of the white dot.

However, when using your screenshot above with the text over the arc, I saw GoIV count "4" white pixels in the area of the D, and then back to 0 afterwards. Thus, it thought that your Pokemon's Level was equal to where the D was at on the line.

Thoughts for fixes:

• Hardcode a "minimum" value of white pixels for GoIV to think that it found the "dot".
  • If whiteLineDistance is < ~8, ignore this and keep looking.
• Require that GoIV "at least" find 1-2 white pixels AFTER detecting a the level dot.
  • In the case above, the arc returns to it's non-white translucent color after the "D" which would result in GoIV realizing that it had not actually found the correct level indicator, and then continue from where it left off, eventually finding the true white dot and detecting the level correctly.

@nahojjjen any thoughts on either of these two approaches? and/or another possible solution not yet presented?

[ghost]

Is it possible that this kind of arc+text overlap can lead to an incorrect scan instead of a failed scan? I think I saw this happen recently, but I won't be able to verify until I notice it happen again.

[AndrewMcQuerry]

Yeah, it can definitely lead to a successful scan with possible incorrect scanned inputs. In the end, GoIV is simply reverse engineering the CP formula.. so anything that GoIV scans, that just happens to fit a combination that makes sense, could result in an estimated IV values that might be incorrect.

But in general, I think the chances are rare and shouldn't result in drastically different values.

[ghost]

Among my catches in the past hour or so, I noticed maybe half a dozen false readings, three of which had drastically different upper values between the automatic quick scan and one I triggered with a tap a few seconds later:

Automatic: 0% Manual: 82% (Venusaur) Automatic: 27% Manual: 73% (Pidgey) Automatic: 22% Manual: 69% (Weedle)

[nahojjjen]

@TripSixes The method for ignoring false-positives on level arc detection could not use hard-coded pixel values, as the amount of pixels the white ball would be will be different on different screen resolutions.

[AndrewMcQuerry]

@nahojjjen Seems we really need a catalog of screenshots from various phone models & resolutions so that we can better estimate these sorts of things.

But in lieu of that, I guess the second option of confirming white pixels after the detected level would be the better route.

[ghost]

Is the number of white pixels from overlapping text always less than the number from the arc dot? If so, would it not make sense to have the app automatically learn the difference over the course of several catches?

[nahojjjen]

@mewio no, any letter with a longer line than the dot would return a bigger number than the actual level dot. For example "D, L, E" etc.

[ghost]

Drat. In that case, what about doing an OCR pass on the top right area of the screen, and delaying the quickscan if any text is detected there?

[nahojjjen]

The ocr operation is resource heavy, Id rather actually decrease the amount of ocr reading we do. It'd also detect the level arc and the background noise of some pokemon types as text.

[ghost]

How about checking for white pixels in the top right area of the screen, and if enough of them are found near the arc, assume it is text that could be overlapping/interfering?

In that case, the quickscan could be delayed until the interfering text is gone. Or instead of delaying the scan, maybe scan the arc for multiple possible dots, perform the quickscan calculations for each one, and expand the IV range to include the results for all of them?

[nahojjjen]

Scanning the top right corner for white pixels would be resource intensive and not work for normal-type pokemon or water type pokemon when the white artifacts appear.

Scanning for multiple dots and combining the results gives very large possibilities, to the point that I think it wouldnt be worthwhile for most users.

[lramati]

What about using the fact that the arc is continuously white? like, find all the potential dots, and then if there's more than 1, use the highest level for which there's a contiguous white arc between it and the previous couple steps? If we're accidentally detecting a letter, and the pokemon's level is low, there should be a transparent break in the arc behind the letter that would disqualify it, and if the level is very high, then the letter will be discarded by the "highest level" clause

Alternatively, or additionally, as some people mentioned above, maybe we can try to learn the exact location for the white dot at each half level over a number of scans, and then if we find more than one dot, we use the one closest to where we'd expect the white dot to be

[nahojjjen]

Alternatively, or additionally, as some people mentioned above, maybe we can try to learn the exact location for the white dot at each half level over a number of scans, and then if we find more than one dot, we use the one closest to where we'd expect the white dot to be

We already have all of the "known" white dot locations, that's what we're searching for in the scan. We cant search for continuous white lines and get a reliable result because the result can be behind the text, or if its very high level, the text will have broken the level indicator anyway.