It was all && in
6951b1d62449e7419a23ffa8f7ccf389feaddb3c (2010-12)
3781d7bed9935efce250e551e36b4b893b2702f8 (2011-01)
5a0c4ad971f30beecfa722d8d471f60a8fd955ee (2011-02)
…
2cb04e82540f8c18be6552329535c1c57caffb83
And then It was changed here to be in conformance with the SSE codepath:
9cff7a3b7e270fe5516613c392cf33cffb10d919
That being said there is nothing said about the intentional part of all || vs &&. If there is a good reason, I don’t see it.
I think the commit message for the upper check using || instead of && mentions that we don’t only want to detect white clipping, but any clipping. The same logic could be applied to negatives (even an otherwise bright pixel may be skewed if it is out of gamut, if any component in negative).
It’s not a crucial issue, since we also have saturation checks and the gamut checks, but then if we want to detect ‘too dark’ (all channels below the lower threshold), we also have the luminance check.
I guess hardly anyone moves this from ‘whole gamut’, and then it’s probably very hard to find an RGB triplet that does not trigger the saturation and luminance check, and would only be caught by this, regardless of || or && for the lower / upper values.
