Update default (crayola-classic) color set with more "expected" colors

[oskay]

The current paint set looks good, and like the crayola set, but has some odd definitions for some of the colors, which give funny results when snapping to the color palette-- in particular for the violet range.

To improve the situation, I would suggest using the named HTML color values: Black, Red, Orange, Yellow, Green, Blue, Purple, Saddle Brown. These look good enough on the page, and behave much better when starting with an existing SVG document.

{
  "name": "Crayola Classic",
  "styles" : {
    "src" : "crayola_classic.css",
    "baseClass": "crayola-classic"
  },
  "colors": [
    {"Black": "#000000"},
    {"Red": "#FF0000"},
    {"Orange": "#FFA500"},
    {"Yellow": "#FFFF00"},
    {"Green": "#008000"},
    {"Blue": "#0000FF"},
    {"Purple": "#800080"},
    {"Brown": "#8B4513"}
  ]
}

And, if you extend the set with white/water wash, please add Azure (#F0FFFF) as the water color. It's nearly white, but is visible against a white background.

[techninja]

As is mentioned in the colorset readme, the colors in a Robopaint sets are meant to represent a best case of the painted and dried color on nice white paper. This leaves them a bit muted, but far more true to how they may look on paper. This was more an artistic decision I chose, as if they were a closer color to how they look in the pots, or to their strict full gamut RGB analogs, would leave the paintings looking starkly brighter and more vibrant in preview than to what's actually painted.

If the Auto-color mappings are more "accurate" when using the RGB Analogs, I guess it's shouldn't be much of a surprise. Very few things come close to using the muted colors currently in the palette, my hope was they would be _close enough_ to snap into incoming drawings a bit, ah well.

As a compromise, I suppose we could store two values for color, one bright set for better auto-color selection and monitor view, and one for more accurate preview (which could be switched over to during print... or not). Might also could simply make this easy and provide a preview accurate Crayola classic colorset, and a simpler default RGB analog crayola classic. ? :rainbow:

[oskay]

I've implemented your color-distance algorithm in a new Inkscape extension (with credit!), and was frustrated by the difficulty of getting something that looked (for example) purple on the screen to snap to the right color. The new color set works well in RoboPaint, with the exception of the purple in a couple of the examples. But, I would like to make this change, and I'd like to do it now before we have a rush of new users.

I don't think that we need to work too hard at matching screen colors to paint colors; there are bigger differences in terms of behavior, especially with different amounts of water, and as the brush has varying amounts of ink. And in any case, I would say that the new color set matches much better the appearance of the paints on paper (especially the purple). Since you don't, that suggests some of the difference we are seeing is due to monitor calibration-- another reason that I'd prefer to move to "named" standards, at least for the primary palette.

[oskay]

One other way to represent colors more accurately for watercolor is to show something that looks more like a paint swatch, with fading or texture-- showing the hue, but at a range of saturation values.

http://janettakahashi.com/?p=600

It might be more helpful to show something like that in the palette image, rather than a solid color.

[techninja]

Hmmm... Something like those paint swatches can certainly be faked a bit with a gradient, or perhaps more accurately with a grayscale gradient map, though with an RGB primitive as its base, the swatch will still look fluorescent.

Would we actually be willing to replace the color selection paint pots with swatches like these? Right now the only visible paint palette is in edit mode, and it's _tiny_. There is one large one still remaining in the advanced/custom paint mode, though that's not directly available, it would allow for color selection.

One option I hadn't mentioned was to mathematically dumb-down the color a bit for any view of it, but use the bright RGB color to aid in more accurate color selection. I can't say we're going to be describing exactly what the watercolors do at various levels of dilution on various media (this stuff performs completely differently on copy paper than on real watercolor paper).

I think I'm just a bit muddy on the direction here.. let me sum-up:

• Easy: flop out the colors on the crayola classic palette to be the RGB color primitive/HTML named colors and be done with it. Certainly more "kid friendly", though it does make my eyes bug out a bit ;)
• More painterly accurate: Use the RGB primitives to aid in automatic color association, but display the RGB approximations of paint on paper.
• Maybe a little nutty: Screw the inaccurate paint palette regime and replace with gradient mapped color swatches on simulated paper! Wait, what does this have to do with auto color selection? :fallen_leaf:

[oskay]

I guess that there are a lot of interesting things to consider.

The issues that I want to solve are (1) consistency between our programs of what constitutes a given color and (2) that those colors are reasonable (for the purpose of snapping to color).

I would advocate the "easy" plan for now. If we come up with a better method of calibrating colors at some point in the future, I'll be happy to swap it out or add it to the set.

[techninja]

Okay.. going to trust your color selections there and just plop em in.

[techninja]

You're right about Purple. HTML/RGB purple is quite a bit darker and more varied in range than what we see for the lighter values. There may need to be a bit of tweaking to the weighting for certain color ranges to make up for us humans and our weird non-linear color perception :eyes: