Allow alternate colors for the pens

[asciipip]

This adds render() and command line parameters to specify the colors that should be used for the "black" and "white" pen colors. These can be used to, for example, have annotations in red or blue lines to distinguish from the content being annotated.

The default colors are, of course, actual black and white. The gray pen is always a 50/50 mix of the black and white pens in the RGB color space.

[asciipip]

You're probably right about being able to specify all of the pen colors (black, white, grey, and highlight). Do you think it makes more sense to have separate command line options for each (--highlight #FFCCCC, --grey #0000AA, etc.) or a more generic (but more complicated to parse) --color option (e.g. --color highlight=#FFCCCC --color grey=#0000AA)?

I'll look around to see if there's a useful library for parsing colors that includes names.

Colors from named layers might be interesting, but I'd view that as a separate thing from what I'm doing here. Maybe that'll be something I try to tackle at a later point. (Personally, I'm hoping the reMarkable developers add some sort of support for setting pen colors at some point, either per-layer or per-notebook.)

For the color averaging, I've used the colormath library for such things in the past, but it seemed like overkill here. (I think that averaging the channels in RGB space is good enough for most cases, and people will be able to override that default if they want after I flesh out the color setting options.)

[asciipip]

Okay, it looks like there are a few options for color parsing:

• matplotlib - Crazy number of input formats, including XKCD colors. Drawback: matplotlib is kind of a heavy pull for just this use.
• colour - A few different input formats, plus it parses into an object that seems useful to work with. Drawback: hasn't been updated in nearly four years.
• webcolors - Aims to parse anything that would be a valid CSS color. Seems to be actively updated. Drawback: No single point of entry for the parsing; needs glue code to determine the color representation so you can call the right parsing function.

I'm leaning toward the last one, webcolors, unless you have a strong preference otherwise.

[rschroll]

I think we should have four different flags, rather than a generic color option. It's not like this is going to expand to dozens of colors. Also, for integration with rmfuse, I'm going to suggest that the render function takes four options, one per color, and then does the parsing and unification into a single data structure to be passed down the stack. The render function can through a parse error for invalid colors, and the command line version can catch this and display an error message.

If we allow a grey input, then the user can do averaging in whatever colorspace they want, so RGB averaging sounds good to me!

matplotlib is definitely overkill for this. Of the two others, my initial reaction is that the colours API looks nicer than that of webcolors. I'm not that worried about the lack of updates for this sort of library, since color parsing can be solved completely and doesn't change (much) over time. But I'd be happy with either one.

[asciipip]

I went with the colour library for this and put in the other changes. The CLI now has four different flags for the pen colors (plus a couple variant spellings). The color strings (or None, which is an option for the gray pen) are passed to render(), which does the parsing. That gives an API that works more or less just like the CLI.

The colour library has a color averaging function of sorts that appears to work in HSL space. I set thing up so rmrl will use that (HSL) averaging if the "black" and "white" pens are both colored and RGB averaging if one or both pens is grayscale. That seems to give good results for me.