It’s of course possible, but the spec is trying to avoid this. There are multiple “masking patterns”, and the algorithm should choose one that gives fewest “penalty points”. Large single color areas are a lot of penalty points, so QR algorithm is trying to avoid them.

Yes - I think it would be interesting to see them actually produced. Could we get to 60% white pixels? Or 75%?

There could maybe be two solutions:

* Darkest/Brightest allowed by the QR algorithm,

* Darkest/Brightest technically valid, which would would not be chosen by the algorithm (i.e. if one manually chooses the masking pattern.

Perhaps also more solutions - 'Darkest/Brightest recognized by software X/Y/Z'

An encoder should try to avoid them, but in theory it doesn't have to, right?

Yeah, it's not mandatory. The specification itself recommends a very concrete algorithm though, and one of its criteria is literally the average density [1].

[1] https://github.com/lifthrasiir/qr.js/blob/52f0409a22c5ece6a5...

I made an attempt on https://www.nayuki.io/page/creating-a-qr-code-step-by-step - use the examples "Force light area" and "Force dark area".

Like this HDR QR Code that works on Apple devices?

https://notes.dt.in.th/HDRQRCode