My student today noticed that if you have something with the color 000001 on the screen and your script asks isTouchingColor(000008) that it returns true.

Is this by design or a bug? If by design how is the approximation done, does anyone know?

Yes, by design. The approximation is per RGB channel, and iirc the acceptable range is different between the channels for some reason. I forget exactly how much it is though

Edit: here's the relevant code https://github.com/LLK/scratch-flash/blob/5cff62b909856b7d7b3d116a5dcc2b4f03de8482/src/scratch/ScratchStage.as#L643
What I don't understand is why the mask is 0x00F8F8F0 instead of 0x00F8F8F8 - that seems to be matching the top 5 bits of red and green, but only the top 4 of blue

@MegaApuTurkUltra Seems like a bug/typo to me. A comment below that states “match only top five bits of each component”. I wonder how many projects would break if it were “fixed”.

EDIT: After some digging I found this: https://github.com/LLK/scratch-flash/commit/41eca4a22d14bde0c90df2ff9723163af3b9c02e#commitcomment-8563558

EDIT2: Also found this: https://github.com/LLK/scratch-flash/issues/544

Looks like it was originally a typo, was fixed, then reverted because some projects broke after the fix.

It's well known and means that colour detector projects don't have quite as much work to do. https://scratch.mit.edu/projects/10941245/

The blue component looks darker (by itself) than either red or green by itself. That means it takes ‘more of it’ to make a perceptible difference (to the eye) between two colours. Since Scratch is more concerned with how things ‘appear’ to beginners (rather than technical accuracy), I suspect it was likely considered better to make the range ‘appear’ to be closer for all the components.

Since red also appears to be somewhat darker than green, it should probably be more like 5 bits for green, 4.5ish for red, and 4(ish) for blue. But it ain't so easy to make a 4.5 bit mask…
(Mind you, I recall that the eye is less sensitive to red than blue & green, so maybe having the red range MORE similar to BLUE, i.e. checking only first four bits, wouldn't have been so bad…? – and it would've halved the number of colours needed to check through to find a match for colour at a pixel…)


TBH, though, I think it might've been better to make it look at the difference between the components of the actual chosen colour vs the touching colour, and have those differences be within certain ranges (rather than having ‘fixed’ boundaries within which both the chosen & touching colours must lie for it to be considered touching that colour).

It's possible such an algorithm could significantly slow down colour-touch testing, though…?

DadOfMrLog wrote:

It's possible such an algorithm could significantly slow down colour-touch testing, though…?

Yes, it certainly would.