You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Another palette type we would like to add are palettes for tree-structured data. A long time ago @edwindj and me introduced these so-called treecolors:
The original implementation is embedded in treemap, which is definitely not the right place since treemaps are not the only tree-structured data visualization methods. Ideally, we would place them in a stand-alone package (and have them available in cols4all), but for lazy reasons, we can also implement them directly into cols4all.
However, there are two issues:
The main mission of cols4all is to make colors available for everyone (except blind people of course), that means also available and usable for people for color-vision-deficiency. Unfortunately, treecolors are not color-blind-friendly. Practically, this means that cols4all tolerates/includes palettes that are not color-blind friendly, but does not actively introduce them.
Palettes are hard coded into an internal palette data.frame (exportable with c4a_sysdata_export). More specifically, colors are vectors of hex-codes, optionally with an index attribute or a range attribute which determines how the palettes are rendered for less than the maximal available colors. It is done in this way to reduce the number of dependencies. For tree colors, this is more complex, since the palette not only depends on the required number of nodes, but also how they are arranged in a tree. Let alone the parameters related to H, C, and L.
So ideally, we would have a stand-alone package, and include a whole bunch of instances (e.g. trees with 1 to 4 layers, with 1 to 5 child nodes per node, which already makes 20 instances), and do this for a few parametrizations. (Just like hcl.colors or the palettes from Polychrome).
Another palette type we would like to add are palettes for tree-structured data. A long time ago @edwindj and me introduced these so-called treecolors:
See also: presentation and paper
The original implementation is embedded in treemap, which is definitely not the right place since treemaps are not the only tree-structured data visualization methods. Ideally, we would place them in a stand-alone package (and have them available in cols4all), but for lazy reasons, we can also implement them directly into
cols4all
.However, there are two issues:
cols4all
is to make colors available for everyone (except blind people of course), that means also available and usable for people for color-vision-deficiency. Unfortunately, treecolors are not color-blind-friendly. Practically, this means thatcols4all
tolerates/includes palettes that are not color-blind friendly, but does not actively introduce them.c4a_sysdata_export
). More specifically, colors are vectors of hex-codes, optionally with anindex
attribute or arange
attribute which determines how the palettes are rendered for less than the maximal available colors. It is done in this way to reduce the number of dependencies. For tree colors, this is more complex, since the palette not only depends on the required number of nodes, but also how they are arranged in a tree. Let alone the parameters related to H, C, and L.There also is a JS implementation https://github.com/e-/TreeColors.js/ thanks to @e-
So ideally, we would have a stand-alone package, and include a whole bunch of instances (e.g. trees with 1 to 4 layers, with 1 to 5 child nodes per node, which already makes 20 instances), and do this for a few parametrizations. (Just like
hcl.colors
or the palettes fromPolychrome
).@edwindj what are your thoughts about this?
The text was updated successfully, but these errors were encountered: