Michael Root <mi...@...>
May I suggest making parseColorSpaceFromString() optionally a little more strict?
The basic problem is that as we're transitioning to using OCIO, there are still many situations where a file might have an OCIO colorspace in the filename....but it may also not have one.
Even if strictparsing is true, the 'strictness' is still pretty lax. Any part of the filename that happens to line up with a colorspace suddenly becomes the colorspace.
For example, parseColorSpaceFromString() returns:
"dialogSync1020.0100.dpx" => "nc10"
"brickKilnFront.jpg" => "lnf"
"digiDoubleForeign1029.0100.dpx" => "gn10"
May I suggest a config option like:
Which would restrict the parser to only consider substrings delimited on both sides by one of those chars (or the beginning or end of the string). By default, delimiters is an empty string, which results in the current behavior.
Attached is a patch against 1.0.9 that implements this idea.