Colors are too close to background

[rodarima]

We assign the event values to the result of a hash function that returns a 32 bits positive integer, which causes large values but allows us to have stable colors across multiple traces.

The drawback is that colors are deterministically generated (but unsupervised) for those large values, and often we observe very dark colors that are too close to the background. In this test trace, the value 1133833770 gets mapped to the color #030304 which is almost black. Here is what we see with the default black background (using the last release 4.10.4):

This behavior is confusing, because it looks like there is no state for "VeryDark" (value 1133833770) unless you check the label. Other values are very dark too.

One option to avoid this problem would be to generate colors in a way that they are not close to the background, but that would cause colors to vary between different users if they have different backgrounds. There is the possibility to only provide safe colors if the user selects black or white backgrounds, and then generate the colors so that they are always different from black and white.

Another option may be to let the PCF control if new colors must be generated by Paraver or if they should be assigned by just repeating the defined colors. Then we could generate some large list of safe colors in the PCF file (we will ensure they are different from the background) and then tell paraver to only use the $N$ colors in the list, by computing the color for the value $x > 0$ as $1 + (x \mod N - 1)$ so the 0 is excluded.

As far as I know the config option NUM_OF_STATE_COLORS is currently ignored, but maybe it can be used to control the number of generated colors. If it matches the list of colors in the PCF, then no new colors will be generated, causing the desired behavior. From the old specification https://tools.bsc.es/doc/1370.pdf I assume this option was already used to control this.

Notice that we could emit the event values already clamped to the defined colors by using the modulo, but this puts us at risk of causing collisions between different values (as now we will have a much smaller range) which will become impossible to distinguish in the timeline. Whereas if they get assigned the same color with different state values, at least you could check the label in Paraver.

Trace files and config color-too-dark.zip.

[executre]

Could be an option for you to define manually the colors in the STATES_COLOR section of PCF? If you write there a semantic value with your desired color, Paraver will use it instead of the internally generated. Also, it's not mandatory to have consecutive semantic values there.

[rodarima]

Not really, because then the generated values will vary depending on how many colors I add in the PCF. I cannot get both deterministically generated colors and safe colors at the same time.

Technically, I could still get rid of generated colors and add one entry for each value, but then the PCF will become unnecesarily huge (potentially millions of lines), but I don't think is a good solution either.

I think using a variable to control how many colors are used in Paraver is the best solution.

[rodarima]

I opened the PR https://github.com/bsc-performance-tools/paraver-kernel/pull/11 which solves this problem by removing all generated colors after the last specified value in the PCF, if the DONT_EXPAND_COLORS option is given. This allows me to prevent the generated colors from accidentally expanding a color with a component close to 255, like rgb(5,5,255), into the next value which overflows into a dark color rgb(5,5,0). So I guarantee that no dark colors are possible (provided the palette is ok).

[executre]

v4.11.3 solves the problems with background similar colors.