TW is way faster, probably use that. https://turbowarp.org/643721525 The Pokemon Company for the PSMD art and Mudkip image @Kouzerumatsu for basically every other non-gradient-or-solid-color test image A conversation I had with @Chrome_Cat reminded me of this idea's existence. I shared the idea with some friends, and notably @52525rr and @Aart1256 finished theirs first and shared it. ( https://scratch.mit.edu/projects/639793840/ and https://scratch.mit.edu/projects/639869706/, respectively) Please note that I basically stole the way you interact with the project from @52525rr's project lol, we have completely different scanners though. Anyways, while this may not seem any different, that's mainly just because I only scan the backdrop. This project can actually scan anything, unlike the others which require the brightness effect. Sprites, pen, video, they should all work just fine in this one, while others could likely be faster for simply scanning individual images. This also uses a color cache, and a refilling method that was originally (to my knowledge) thought of by @Mathman05 in the Lossy Colors scanner. That's... a lot of credits. Technically only @Mathman05 actually contributed to the code in some way, but still. Onto how this works: It applies a solid black clone as an overlay over everything else. This reduces the colors enough that, with at max* 8 "touching" tests per pixel, I can get another bit for the final output. Of course... the "*". Due to Scratch rounding colors, it's actually not possible for all possible colors to be gotten in 8 guesses with this -- You'll actually need a max of 64 (which is still smaller than other scanners, at least). This is because every single component, in very rare cases (as in... 4/256 possible values for any color channel is it? Maybe more?) rounding may cause things to be too high or too low at some point, causing this scanner to overshoot. The "edgeCase" block handles that, detecting any given edge case there is. Of course, this should be encountered ever rarer than normal because I have the cache I mentioned earlier. This stores offsets to colors rather than colors though. It also means that any edge cases that don't have to be checked likely won't be checked. This should have sped up the scanner a ton. Oh yeah, one more thing, thanks to for giving me a (sorta intentional but sorta not) lead on what transparency values to use... and also telling me that Scratch somehow wouldn't be stupid and not want to detect any color whatsoever if I tried something I had already tried before (they were right)
