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.

@semagnum Sorry, so what is the new format? Can I just do color="#FF0011" now?

This is currently the format: tests/baselines/empty_color.json

I did include utility converters to/from hex code within the Color class, so implementing that would just be a matter of adding it as an option to the deserializer, if that's what you're hoping for :)

No, I'm seeking clarification on how one is supposed to be able to specify custom colors for tracks/clips/etc that are outside of the preset list of named colors in an OTIO json file. So if I understand what you linked to, one is supposed to create their own color names separately, and then creating your own schema for how to link tracks/clips to the color names? That is exceptionally unwieldy for use cases where you have a large number of tracks/clips each with their separate colours. You have to in essence create your own indexing scheme if that is the case.

You don't need to add colors to a list. Each Clip can have its own color like this:

{
    "OTIO_SCHEMA": "Clip.2",
    "metadata": {},
    "name": "Clip-001",
    "source_range": {
        "OTIO_SCHEMA": "TimeRange.1",
        "duration": {
            "OTIO_SCHEMA": "RationalTime.1",
            "rate": 24.0,
            "value": 3.0
        },
        "start_time": {
            "OTIO_SCHEMA": "RationalTime.1",
            "rate": 24.0,
            "value": 3.0
        }
    },
    "effects": [],
    "markers": [],
    "enabled": true,
    "color": {
        "OTIO_SCHEMA": "Color.1",
        "r": 1.0,
        "g": 0.9,
        "b": 0.8,
        "a": 1.0,
        "name": "something"
    },
    ...

@semagnum in preparing the example above I noticed a bug though... This isn't working as expected:

Python 3.9.12 (main, Apr  5 2022, 01:52:34)
[Clang 12.0.0 ] :: Anaconda, Inc. on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import opentimelineio as otio
>>> c = otio.core.Color()
>>> repr(c)
"otio.core.Color(name='', r=1.0, g=1.0, b=1.0, a=1.0)"
>>> s = otio.adapters.write_to_string(c)
>>> print(s)
{
    "OTIO_SCHEMA": "Color.1",
    "r": 1.0,
    "g": 1.0,
    "b": 1.0,
    "a": 1.0,
    "name": ""
}
>>> c2 = otio.adapters.read_from_string(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/joshm/.cache/uv/archive-v0/v5vlyU-P9Mp6bsSlMYRsI/lib/python3.9/site-packages/opentimelineio/adapters/__init__.py", line 171, in read_from_string
    return adapter.read_from_string(
  File "/Users/joshm/.cache/uv/archive-v0/v5vlyU-P9Mp6bsSlMYRsI/lib/python3.9/site-packages/opentimelineio/adapters/adapter.py", line 240, in read_from_string
    result = self._execute_function(
  File "/Users/joshm/.cache/uv/archive-v0/v5vlyU-P9Mp6bsSlMYRsI/lib/python3.9/site-packages/opentimelineio/plugins/python_plugin.py", line 144, in _execute_function
    return (getattr(self.module(), func_name)(**kwargs))
  File "/Users/joshm/.cache/uv/archive-v0/v5vlyU-P9Mp6bsSlMYRsI/lib/python3.9/site-packages/opentimelineio/adapters/otio_json.py", line 40, in read_from_string
    return core.deserialize_json_from_string(input_str)
ValueError: type mismatch while decoding: near line 8
>>>

in preparing the example above I noticed a bug though... This isn't working as expected

Gotcha, I'll try to take a look at the deserializer. I'll have more time later this week. Any help troubleshooting would be appreciated.

You don't need to add colors to a list. Each Clip can have its own color like this:

Ah ok, that sounds a lot better! What is the intention of have the name in that case?

Some applications and formats that OTIO interoperates with only support named colors. Having a name field lets those use cases key off of the name instead of the RGB values. You can see a bit more discussion about that choice here: #1887

I'll try to take a look at the deserializer. I'll have more time later this week. Any help troubleshooting would be appreciated.

Found the root cause, the deserializer was incorrectly looking for a float when the constructor needs a double. Will make a PR.

@jminor if you or someone else could review that PR, I'd appreciate it. I'd hate for a hotfix to linger any longer than it needs to

@semagnum looks great. I verified it locally in a fresh build of Raven. Thanks for the quick fix - merged.