I've added this feature into the controller just now Kong, and it does work, but with the caveat you point out:

Only pixels which are specifically masked or below the upper/lower threshold will be skipped. So exactly as you say, if there is a non-white pixel that the machine can't render as waves, it'll slip past and get drawn anyway. If there are small numbers of these pixels, then it might not even be a problem, but I prefer to have control, which is why I haven't ever implemented this.

But I'm going to do it anyway, and make it switch-off-able for those TSP fetishists like myself who like to maintain a continuous line from top to bottom.

If you use a mask, in conjunction with tweaking the "brightest pixel" threshold value, then you should be able to squeeze out the false positives that get passed to the machine, but don't actually result in squiggles.

There is a caveat attached to this new release though (be careful what you wish for), and it's that you need new firmware too. I've changed the protocol that it uses for the serial comms - instead of repeating the submitted command back to ask for verification, each command has a checksum appended to it, and that's used instead. It even seems to work, but'll it'll misbehave if your versions are not synchronised.

It makes comms twice as fast as before and is a more sensible approach.

Happy bank holiday monday!