[FEATURE]: Implement support for "slugified" colourspace names.

[MrLixm]

Description

Hello,

I'm looking to insert or retrieve colour.RGB_COLORSPACES names from file names.
For example, I would like to use the ALEXA Wide Gamut colorspace into a file name which could be slugified to something like alexaWideGamut. I could also run the invert where something like colour.RGB_COLORSPACES.get("alexaWideGamut") would return me the ALEXA Wide Gamut RGB_COLORSPACE instance.

This means colour could be an alternative method (to OCIO) to convert imagery files colorspaces, where file name / metadata would provide the source colorspace name of the file.
I'm trying to answer the question How one would encode colorspace metadata in a library of imagery files that would be easily translated to a code object for conversions.
OCIO is one way to go but I would like to see how colour would behave in that role.

Some technicalities to have a look at:

• what characters are allowed ? Do we keep dots, dashes ? Or only something like [a-zA-Z\d_]
• does we modify literature of colorspace names, like sRGB would become srgb ?

Cheers.
Liam.

[KelSolaar]

Here is a quick notebook to illustrate what we could do for example: https://colab.research.google.com/drive/1xlhqI0W71g7uX4HQ9pUiV13HqRsxWmny#scrollTo=2lbGErCPHmjM

The main question is whether we want to support that by default or provide a way for people to implement that easily.

Given that we use CaseInsensitiveMapping/LazyCaseInsensitiveMapping in a lot of places, we could maybe implement that across the board. We would have to choose a default style that is not ambiguous, e.g. separated with dashes:

ALEXA Wide Gamut --> alexa-wide-gamut

It would be trivial to write camelCase, PascalCase, snake_case mappings from there.

[MrLixm]

Thanks ! This looks great.
How should it treat dots like in Venice S-Gamut3.Cine that with your current function is turned into venice-s-gamut3cine. Would it be preferable to turn the dot into a dash ?

Having it implemented straight into CaseInsensitiveMapping/LazyCaseInsensitiveMapping seems to be a great idea, I hope it will not cause you collision issues or something in that regards.

[KelSolaar]

I think it would be preferable to stay close to Django here, they do encode URLs with that function which is actually one usage we could have.

I was thinking that instead of doing (which works in my feature branch):

>>> import colour
>>> colour.RGB_COLOURSPACES.lookup('alexa-wide-gamut')
RGB_Colourspace('ALEXA Wide Gamut',
                [[ 0.684 ,  0.313 ],
...

We could directly implement that on __getitem__, the first failure could be re-attempted against the slugified variant.

It might be a bit magic though:

>>> import colour
>>> colour.RGB_COLOURSPACES['ALEXA Wide Gamut'].name
'ALEXA Wide Gamut'
>>> colour.RGB_COLOURSPACES['alexa-wide-gamut'].name
'ALEXA Wide Gamut'
>>> list(colour.RGB_COLOURSPACES.keys())
['ACES2065-1', 'ACEScc', 'ACEScct', 'ACEScg', 'ACESproxy', 'ALEXA Wide Gamut', 'Adobe RGB (1998)', 'Adobe Wide Gamut RGB', 'Apple RGB', 'Best RGB', 'Beta RGB', 'Blackmagic Wide Gamut', 'CIE RGB', 'Cinema Gamut', 'ColorMatch RGB', 'DCDM XYZ', 'DCI-P3', 'DCI-P3+', 'DJI D-Gamut', 'DRAGONcolor', 'DRAGONcolor2', 'DaVinci Wide Gamut', 'Display P3', 'Don RGB 4', 'ECI RGB v2', 'ERIMM RGB', 'Ekta Space PS 5', 'F-Gamut', 'FilmLight E-Gamut', 'ITU-R BT.2020', 'ITU-R BT.470 - 525', 'ITU-R BT.470 - 625', 'ITU-R BT.709', 'Max RGB', 'N-Gamut', 'NTSC (1953)', 'NTSC (1987)', 'P3-D65', 'Pal/Secam', 'ProPhoto RGB', 'Protune Native', 'REDWideGamutRGB', 'REDcolor', 'REDcolor2', 'REDcolor3', 'REDcolor4', 'RIMM RGB', 'ROMM RGB', 'Russell RGB', 'S-Gamut', 'S-Gamut3', 'S-Gamut3.Cine', 'SMPTE 240M', 'SMPTE C', 'Sharp RGB', 'V-Gamut', 'Venice S-Gamut3', 'Venice S-Gamut3.Cine', 'Xtreme RGB', 'sRGB', 'aces', 'adobe1998', 'prophoto']

[fredsavoir]

Yes very cool

…

Sent from my iPhone

On 30 May 2022, at 11:59, Thomas Mansencal ***@***.***> wrote:  I think it would be preferable to stay close to Django here, they do encode URLs with that function which is actually one usage we could have. I was thinking that instead of doing (which works in my feature branch): >>> import colour >>> colour.RGB_COLOURSPACES.lookup('alexa-wide-gamut') RGB_Colourspace('ALEXA Wide Gamut', [[ 0.684 , 0.313 ], ... We could directly implement that on __getitem__, the first failure could be re-attempted against the slugified variant. It might be a bit magic though! — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[MrLixm]

>>> list(colour.RGB_COLOURSPACES.keys())
['ACES2065-1', 'ACEScc', 'ACEScct', 'ACEScg', ...

True that it not very explicit what happening behind the scene.
But at that point why not refactoring a bit more the system.
I mean some colorspace can now have 3 aliases pointing to the same colorspace like ACES2065-1, aces, aces2065-1
So it would be cool to have a way to display every colorspace and their aliases maybe ?

list(colour.RGB_COLOURSPACES.keys())
[("ACES2065-1", "aces", "aces2065-1"), ("ACEScc", "acescc"), ..., ("'Adobe RGB (1998)'", "adobe1998", "adobe-rgb-1998"), ...]

But here we are getting into something complex to not break compatibility

[KelSolaar]

We cannot change .keys like that, it would break everything down the line, it would be either we extend .keys with the slugified variants, or we have a .slugs method (probably cleaner) that returns them.

[MrLixm]

What about

• .keys : combinaison of all the three other method under. Compared to actual it's the same but with the slugs.
• .names : original colorspace names
• .slugs: return slugs only
• .aliases: return aliases only like aces, adobe1988, ...