[Standards] XEP-0392 angle generation

Marcel Waldvogel marcel.waldvogel at uni-konstanz.de
Wed Nov 22 08:36:48 UTC 2017


Jonas Wielicki wrote:
> Yes, I plan to clarify this soon. Will take a few days though, for
> reasons beyond my control.
> FTR: the test vectors for palette mapping are incorrect too. I’ll fix
> those soon, too.

This means there is still time to improve on the XEP? Great!
Here are some comments:
* 5.1 Angle generation
> 1. Run the input through SHA-1

I know this is not a security-relevant protocol, so the security
weaknesses of SHA-1 are not a problem here. But I expect SHA-1 to be
uncommon/deprecated "soon" (in standards time spans, i.e., in the next
decade) and there will be security checkers that will flag any use of
SHA-1 as a potential security problem.
If we create a standard now, why not use an up-to-date hash function,
such as SHA-256?
> 3. Divide the value by 65535 (use float division) and multiply it by
> 2π (two Pi).

Dividing by 65535 will result in values from 0 to 1, inclusive. That
means there will be both 0 and 2π values, which are the same, making 0
twice as common as the other values.
Recommendation: Divide by 65536 instead.
* 5.2 Corrections for Color Vision Deficiencies
> 5.2.1 Red/Green-blindness
> Divide the angle by two.

This will change *all* angles, with the exception of 0, when toggling
between traditional and color-blind values, which breaks consistency
more than necessary.
Recommendation: An alternative would be to use the angle modulo π (pi).
This would cause half of the colors to remain the same.
(For those afraid to calculate modulo an irrational number: The same
effect can be achieved by clearing the most significant bit of the 16-
bit input value after step 2 of 5.1 instead of doing it on the angle.)
> 5.2.2 Blue-blindness
> Divide the angle by two and add π/2 (half Pi).

The same applies here: We can keep 50% of the colors the same and thus
increase recognition value when toggling as follows:
Recommendation: angle = ((angle - π/2) mod π) + π/2
(For those trying to avoid floating-point arithmetic, the same can be
achieved by setting bit 15 (MSB) of the 16-bit input value to the
inverse of bit 14.)
* 5.5 Adapting the Color for specific Background Colors
I presume this "inverse alpha" calculation should be applied always,
even on white backgrounds? Otherwise, there is a discontinuity. It
would be good to explain the rationale behind this part.
-Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171122/47800067/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6431 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171122/47800067/attachment.bin>


More information about the Standards mailing list