[Standards] XEP-0392 angle generation
jonas at wielicki.name
Thu Nov 23 16:02:36 UTC 2017
Thank you very much for your feedback. There’s some valuable stuff in there.
On Mittwoch, 22. November 2017 09:36:48 CET Marcel Waldvogel wrote:
> 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?
Sure! This XEP is a bit more tricky because we don’t have anything on the
protocol level to base the versioning on. This should not stop us from
developing it while it is still Experimental though.
> 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?
I see your point. Hash functions will always be a moving target, but I think
that due to the wide-spread use SHA-1 has seen in e.g. git and hg, it won’t go
away *that* easily (even if it is phased out for those and other security-
If we would be choosing a modern hash function, something from the SHA3 family
or blake would be more sensible.
> > 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.
I agree with your recommendation. This has been pointed out by multiple people
and is fully correct.
> * 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.)
Interesting idea. I will have to take a look how this behaves in some color-
> > 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.)
Same as above.
> * 5.5 Adapting the Color for specific Background Colors
> I presume this "inverse alpha" calculation should be applied always,
> even on white backgrounds?
Maybe™. We need deployment experience with that (I only played around with it
on some uniformly colored backgrounds for testing, and there the effect was
quite useful). Another way I am thinking of is to fully saturize the
background color for the "inverse alpha" calculation and separate the color
(hue) from a to-be-specified brightness adaption.
> Otherwise, there is a discontinuity. It
> would be good to explain the rationale behind this part.
Can you specify what is unclear here?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards