Re: [Standards] XEP-0392 angle generation
Hi Marcel and others, First of all, thank you for your valuable feedback. I have incorporated it into an update of XEP-0392 which I’ll publish soon. On 23.11.2017 18:22, Marcel Waldvogel wrote: >>> * 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? >> > > With discontinuity, I meant that there will be a different color chosen > for those that use the color before 5.5 and after 5.5. So it would be > good to state to always apply 5.5 (or to never apply it or …). Yes, 5.5 MAY be applied to grayscale backgrounds, but does not have to be applied. It doesn’t change the hue and it is up to the client (developer) to decide whether adaption is necessary. It does not harm either way. For coloured backgrounds, applying 5.5 is RECOMMENDED because it provides contrast even in extreme situations. Alternatively, a border or similar mechanism can be used. I’ll add wording with respect to that to the next update. kind regards, Jonas signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0392 angle generation
On Thu, 2017-11-23 at 17:02 +0100, Jonas Wielicki wrote: > > * 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- > blindness simulators. It will use colors from the same spectrum, just mapping different JIDs to different colors. But yes, testing it with a simulator (or real color-blind people, maybe just ask Marc Zuckerberg ☺) would be an excellent idea. > > * 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? > With discontinuity, I meant that there will be a different color chosen for those that use the color before 5.5 and after 5.5. So it would be good to state to always apply 5.5 (or to never apply it or …). > kind regards, > Jonas___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ -- Beste Grüße, -Marcel Waldvogel University of Konstanz Distributed Systems Laboratory Efficient Secure and Private Collaboration smime.p7s Description: S/MIME cryptographic signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0392 angle generation
> If we would be choosing a modern hash function, something from the SHA3 family > or blake would be more sensible. Please consider using either SHA-1 or SHA-256, not blake. The reason: It at least makes Java implementations easier, because those are available on every implementation of the Java platform, as per their doc: https://docs.oracle.com/javase/9/docs/api/java/security/MessageDigest.html And probably more available for other technologies as well. Thanks, -- Christian ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0392 angle generation
Hi Marcel, 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. > 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? 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- relevant applications). 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- blindness simulators. > > 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? kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0392 angle generation
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 smime.p7s Description: S/MIME cryptographic signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0392 angle generation
On Dienstag, 21. November 2017 11:11:15 CET Klaus Herberth wrote:
> Hi everyone,
>
> I implemented XEP-0392 "Consistent Color Generation" [1] as a node
> module [2] and found a vagueness right in the first section of the
> algorithm. In 5.1 we use the "first 16 bits" of our hash value. But what
> are the first 16 bits? MSB, LSB? If I calculate the first example
> ('Romeo','526f6d656f',5.711769) backwards, I see that the MSB bits are
> used with little-endian, which is quite confusing. Can we change this to
> something like: "The 16 most significant bits"?
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.
> There is also a small typo: Blindess should be blindness.
Noted.
> Otherwise a nice XEP :+1:
Thank you :-)
kind regards,
Jonas
signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
[Standards] XEP-0392 angle generation
Hi everyone,
I implemented XEP-0392 "Consistent Color Generation" [1] as a node
module [2] and found a vagueness right in the first section of the
algorithm. In 5.1 we use the "first 16 bits" of our hash value. But what
are the first 16 bits? MSB, LSB? If I calculate the first example
('Romeo','526f6d656f',5.711769) backwards, I see that the MSB bits are
used with little-endian, which is quite confusing. Can we change this to
something like: "The 16 most significant bits"?
There is also a small typo: Blindess should be blindness.
Otherwise a nice XEP :+1:
Best regards,
Klaus
[1] https://xmpp.org/extensions/xep-0392.html
[2] https://github.com/jsxc/consistent-color-generation
signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
