feat(createLayersUIMachine): for 4 or more components colormap RGB+Gray

[PaulHax]

Set first 4 component colormaps to red, green, blue, gray instead of CT-AAA when more than 4 components

http://localhost:8082/?image=https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0101A/13457537.zarr

[thewtex]

Better default, but when enabling the non-default components, i.e., 4, 5, etc. they have CT-AAA, and the result is mush. :-$ :bowl_with_spoon:

->

Let's substitute 6 of the pastel color maps:

with the categorical color names / icons:

When a categorical color name is selected for one of the component color maps, we use a color map that is generated dynamically black -> ${color}, similar to the BkRd, BkGn, BkBu, i.e. something like:

import { CategoricalColors } from 'itk-viewer-color-maps'
// From selection
const colorMapName = "glasbey"
const indexedColors = CategoricalColors.get(colorMapName)
const currentComponent = getCurrentlySelectedImageActorComponent()
// We want an offset so there is contrast with label image colors
const colorOffset = 128 + currentComponent
const indexedColor = indexedColors.slice(3*colorOffset, 3*colorOffset + 3)
const cmap = {"ColorSpace":"RGB","Name":`Bk-${colorMapName}-${colorOffset}`,"NanColor":[1,1,0],"RGBPoints":[0,0,0,0,1,indexedColor[0],indexedColor[1],indexedColor[2]}

@PaulHax make sense?

[thewtex]

something like

This logic could go into a re-usable function(s) in itk-viewer-color-maps. A function that returns a color map for a color map name (internally it checks if the name is a categorical color and generates the cmap for the component), otherwise does the continuous color map Map lookup. And another function that generates the black -> indexedColor continuous colormap from the categorical color name and component.

[PaulHax]

Makes sense! Wonder if folks will make the leap that clicking "glasby/etc" will pick a color from it by component index. Perhaps another PR for this?

For quick fix for 5+ component case, loop over RGB+Gray for all higher components' default?

[thewtex]

Yes, we can make these improvements in the next iteration -- tracked in #607