This looks like a good way to do it. I agree, having a pref is the way to go instead of lots of key mappings. I guess the bigger design might need to be re-thought a bit eventually. Right now the brush holds the HSV values no matter what, because HSV is what the brush engine expects. I extended that to include (almost) the full CIECAM spec, regardless if you actually used a CIECAM adjuster. All of this ends up in the stroke map, which I thought was pretty cool in that you can recover the full ciecam spec from the canvas and have parts of the painting using different illuminants, etc.
So, it sounds like it would would make more sense for the stroke map to contain HCY if you used HCY to select or modify the color, and so on. And if you didn’t use CIECAM maybe it shouldn’t actually be in there at all. I guess the basic idea is that the only color model that has useful information is the model you used to make the selection/adjustment.
So, ultimately, the brush should have just two color things, the RGB color and the full UIColor object that you used to select/modify the color. The libmypaint engine should really be modified to just take RGB (I’ve done this on another branch (OCIO) and it works fine). This would free up a few cycles since currently the brush engine is constantly converting HSV->RGB for every dab.
. . . .I was just reviewing all the stuff I had to do to persist CIECAM color dimensions. . . ugh, I did a lot of hacky stuff to try to avoid losing the color data. I think we need to redesign the color manager a bit so that the main managed color does not have to be HSV and/or isn’t reset to HSV all the time. By stuffing the CIECAM stuff into the brush settings I’m basically side-stepping the bigger issue-- the managed color should just be the color in the model that you picked it from. This problem extends to colors stored in the palette, color history, etc. All these are losing information about the color you are using.
I’ll have to try to reproduce this better. Does it do this if you set the pref color.average_use_dominant to False? Using the kmeans clustering might slow it down even more.
Good call, that looks a lot better at all sizes. Did you try the slider bar size preference?
So many prefs… … so little gui space :-). I wonder if we could do something like the way browsers do configuration: about:config w/ a list. At least for the obscure prefs. It’s too bad there isn’t anywhere to add a description of each preference that could be listed next to each.