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

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.

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.

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.

Hi, just wanted to say I coded up a base class working in preparation for Dev Days, I'm hoping to add it as a new attribute for clips and tracks before making a PR.