Heatmap: hue gradient instead of saturation

[davidak]

• Gitea version (or commit ref): 1.7
• Git version:
• Operating system:
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

GitHub is perfect.

Screenshots

Gitea

GitHub

GitLab

[zeripath]

I'm not sure. I've never quite been able to understand GitHubs hue gradient - saturation seems intuitive to me.

[davidak]

@zeripath darker color means more activity. I think that's commonly used for visualization.

The current implementation seems too simple in that space.

It looks too dark and feels depressing to me. It should have the bright green of the logo included.

[0x5c]

Ah yes, that's the problem that I was having with it, without knowing what it was.

I might be able to make a palette today.

[0x5c]

Okay, so I took a look at the three palettes, and they all are gradient on hue, saturation, and value.
What seems to be different is the curves done on the colour-picker; GitHub and GitLab both do a curve towards the saturated/high-value corner, while Gitea does a curve in the opposite direction.

[0x5c]

I've done some work on colouring

Current palette

Proposed palette n°1

Partial, not really suitable as-is.

Proposed palette n°2

Those proposition only contain 5 colours; it is assumed that the first one is the current (#F4F4F4).
The Gitea colour (#609926) is included in both, at the before-last position.
Feel free to modify or expand on these.

[davidak]

@0x5c thank you!

The gradient in the first palette looks a bit hard. The color in the middle looks very unnatural. Maybe that is what you mean with "not suitable as-is".

The seconds palette looks great! Could you try it out with the actual heatmap in the browser?

Here are profiles i found with actual activity:

https://codeberg.org/hw?tab=activity
https://codeberg.org/wahn?tab=activity

[0x5c]

No problem!
I'll try it, and maybe tweak prop2 a slight bit.
As for prop1, this is exactly what I meant, but I included it as a possible starting point for someone else, as it's what I used as a base for prop2.

[0x5c]

Ewwwwww
So the boxes are not coloured by CSS styles, which means I'll have to manually replace the colours.

[davidak]

@0x5c maybe just take a screenshot and replace color with gimp or so...

[0x5c]

I have not yet been able to try recoloring, but I suspect that it will cause problems as the squares are somehow anti-aliased (why?).

I was able, however, to create this 3rd version, which now follows an entirely convex curve.

Proposed palette n°3

[davidak]

@0x5c 3. looks good!

I just used GIMPs replace color tool on a screenshot. Looks perfect!

When it's this small and i go back 1 meter from the display, the contrast is not that high. I can hardly tell a difference between the 2. and 3. color. I think it's a little better on GitHub since it's a different color tone.

[0x5c]

Oh nice!
I see what you mean for colour 2/3, but I don't think that it would be that much of a problem?
I could try a slight variation on colour 2 (one in the palettes).

[0x5c]

Palette proposition v4

Slightly tweaked the first one from #cde5b3 to #d8efbf.
(actual first is still #f4f4f4)

[davidak]

Yeah, it might not be a problem. Already a huge improvement to the current colors.

[0x5c]

Welp
The colours are auto-generated by cal-heatmap, which seems to have no concept of humans are supposed to see this.
It takes two colours, and then proceeds to create the most eye-stabbing gradient possible. It's also the reason why the heatmap squares have fudgy edges, even on the showcase site.

I do not see how, using this library, the colours of the heatmap could be fixed.

Edit:
Note that github uses absolute and defined values (the ones in the legend) for the colours.