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"
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
> 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
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
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:
*
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
>
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
