Expand the file rules to handle integer formats

[doug-walker]

The current file rules section of the configs is simply assigning ACES2065-1 to all files. While this is a decent default for OpenEXR files, it is obviously not for integer formats. This issue is to add additional file rules to handle that use-case. More discussion is needed as to what the default color space should be.

[remia]

As discussed in yersterday TSC meeting, I'm sharing here the simple rules we used for our xStudio open source build shipping with a very slightly modified ACES studio-config.

file_rules:
  - !<Rule> {name: Stills, regex: ".*\\.([tT][iI][fF][fF]?|[jJ][pP][eE]?[gG]|[pP][nN][gG])$", colorspace: sRGB - Display}
  - !<Rule> {name: Movies, regex: ".*\\.([mM][pP]4|[mM][oO][vV]|[mM][xX][fF])$", colorspace: Rec.1886 Rec.709 - Display}
  - !<Rule> {name: Default, colorspace: ACES2065-1}

This is then used alongside the ViewingRules to produce a "reasonable" out of the box viewing workflow. This is not used internally in our studio so we haven't got much feedback about this yet.

As an improvement I can already see, we might want to add the following rule first?

- !<Rule> {name: ColorSpaceNamePathSearch}

[brechtvl]

Trying to match integer formats seems difficult to make reliable. Why not remove the default rule and set "*.exr" to match ACES2065-1? Or are there other file formats commonly used to store ACES2065-1 (and if so do they have extensions that could be matched too)?

The file rules seem useful to identify e.g. when the colorspace name is part of the filename, or when there's a naming convention for e.g. normal or displacement maps. And when no such specific rule is found, the application can have smarter heuristics to guess the colorspace based on more than just extension.

But if every integer format file extension is already part of the file rules, then the application can't use both the rules for e.g. normal or displacement maps and its own heuristics, because the file rules will resolve to a colorspace every time. Or am I misunderstanding how this is typically used?

[doug-walker]

@brechtvl , the file rules must have a Default rule, in other words, they must always return a color space. However, there is a filepathOnlyMatchesDefaultRule function to test whether it only matched that rule.

Usually, if an application is looking in the file header to determine the color space (e.g., for the new colorInteropID), that takes precedence over the file rules. The file rules are sort of the last stop on the decision tree, typically.

I like Remi's rule to assign video formats to Rec.709, but I would not object to making an EXR rule for ACES2065-1 and then the default rule could be sRGB:

file_rules:
  - !<Rule> {name: EXR, colorspace: ACES2065-1, pattern: "*", extension: exr}
  - !<Rule> {name: Movies, colorspace: Rec.1886 Rec.709 - Display, regex: ".*\\.([mM][pP]4|[mM][oO][vV]|[mM][xX][fF])$"}
  - !<Rule> {name: Default, colorspace: sRGB - Display}

I will add this to the agenda for the TSC meeting on Monday.

[brechtvl]

Thanks for the reply. I think the modification to make sRGB the default role could work ok.

• For EXR give precedence to ACES or color interop ID metadata over file rules (following the recommendation).
• For movies give precedence to CICP over file rules (because otherwise every movie file is Rec.1886 Rec.709).
• For other image files, ignore the default rule (which e.g. OpenImageIO and Blender already do). Not sure if CICP or ICC profiles should take precedence over file rules or not, but either order would be compatible with the ACES config rules.

[doug-walker]

Implemented in PR #160.