Per-clip and per-track color

[jminor]

Feature Request

New Feature

Description

Many NLE programs allow users to color code individual clips and/or tracks in the timeline user interface. This color information is encoded in AAF, and XML files. It would be great if OTIO had a schema property to carry this in a portable way.

Context

Since this PR OpenTimelineIO/raven#14 Raven has minimal support for this as app-specific metadata. That feature was added to help instigate discussion about this schema change.

OTIO already carries per-marker color coding, as an enumerated string value (e.g. "RED", "CYAN", etc.) which has been awkward at times. Perhaps we could revisit that decision and see if maybe storing an RGB triple, or hexadecimal value like "#FF0" might be better.

[jminor]

Notes about marker colors as names vs RGB values here: https://github.com/AcademySoftwareFoundation/OpenTimelineIO/wiki/Editorial-File-Format-Notes

[jminor]

Here's a note from @apetrynet (paraphrased from discussion elsewhere):
OTIO could serialize color values as normalized values between 0 and 1 including alpha (like OIIO). That way we're free from bit depth and can convert between known types like hex, string, int etc. This would need some mapping and convenience functions. Also suggest keeping the marker color strings (including lower case representation) as a mapping to normalized values.

[e4lam]

Do we really need to concern ourselves with bit depths? I'd imagine 99% of the use cases would be for user interfaces where HTML codes in the form of #RRGGBBAA (with the AA being optional) hexadecimal codes would cover it.

[reinecke]

I like the proposal @jminor puts forward (with 0-1 float values) because it lets us have one RGBA color schema with utility functions to convert in/out of most the other common representations and it has high reusability for effect parameters or other places where more accurate color may be needed.
The conversion model is in-line with the pattern RationalTime uses with from_frames, to_frames, from_timecode, to_timecode. In this case it might be something like:

• from_hex
• to_hex
• from_rgba_integer_list (Accepts a bit-depth)
• to_rgba_integer_list (accepts a bit-depth)

For the named colors, we could consider mapping them to specific color by adding a method to this struct. I think it's better to have that struct know about name to color mapping than make a ground truth color representation have some notion of named colors.