Skip to content

fix(color mgmt): More sensible OCIO file rules #5194

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
lgritz wants to merge 2 commits into
base: main
Choose a base branch
from
Open

fix(color mgmt): More sensible OCIO file rules #5194

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
756b478
fix(color mgmt): More sensible OCIO file rules
lgritz May 10, 2026
393dc65
Address review comments for fix_config_file_rules and ImageBufAlgo::c…
lgritz May 17, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
106 changes: 81 additions & 25 deletions src/libOpenImageIO/color_ocio.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -201,8 +201,8 @@ struct CSInfo {
// Hidden implementation of ColorConfig
class ColorConfig::Impl {
public:
OCIO::ConstConfigRcPtr config_;
OCIO::ConstConfigRcPtr builtinconfig_;
OCIO::ConfigRcPtr config_;
OCIO::ConfigRcPtr builtinconfig_;

private:
std::vector<CSInfo> colorspaces;
Expand Down Expand Up @@ -815,6 +815,53 @@ ColorConfig::~ColorConfig() {}



// OIIO doctoring of OCIO configs for different default file rules. Currently,
// we only do this for built-in configs.
static void
fix_config_file_rules(OCIO::ConfigRcPtr& config)
{
OIIO_CONTRACT_ASSERT(config);
DBG("Fixing up rules:\n");
#if 1
// Just start with a clean slate
auto rules = OCIO::FileRules::Create();
#else
// Alternate universe: Start with the existing rules
auto rules = config->getFileRules()->createEditableCopy();
#endif
for (size_t i = 0, e = rules->getNumEntries(); i != e; ++i) {
DBG(" rule {}/{}: pat='{}' ext='{}' -> \"{}\"\n", i, rules->getName(i),
rules->getRegex(i), rules->getExtension(i),
rules->getColorSpace(i));
#if 0
// If we wanted to doctor just the exr rule, here's how:
if (Strutil::iequals(rules->getExtension(i), "exr")) {
// Change the rule for exr extension, if it exists, to "unknown".
// Make no assumptions. OCIO's built-in configs think it should be
// ACES2065-1, which is almost never right.
rules->setColorSpace(i, "unknown");
Comment on lines +838 to +842
Copy link
Copy Markdown
Collaborator

@zachlewis zachlewis May 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to use the same color space for both the "exr" rule and the default rule, why not just remove the "exr" rule entirely?

Copy link
Copy Markdown
Collaborator Author

@lgritz lgritz May 17, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, considering that I also clear the rules entirely, I think you could classify this whole clause as a memo to myself about HOW to change it, rather than being a consequential change at the moment. At the moment, this non-functional code marks both "exr" and "everything" as unknown, but I could imagine (and did experiment with) having them be different, such as assuming that exr files were scene_linear. And we may go back to that, I don't know.

Copy link
Copy Markdown
Collaborator

@zachlewis zachlewis May 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, I hadn't realized that this isn't even implemented..

I think you could classify this whole clause as a memo to myself about HOW to change it, rather than being a consequential change at the moment.

I appreciate that, it's helpful to see how you're thinking things through. I hope you don't mind my long-assed commentary. And I apologize if I came across as implying you were doing the wrong thing here by setting the EXR and default rules to the same thing -- I was just curious to see if you were thinking about treating responses triggered by the EXR rule differently from the default rule, and whether you had considered using the API to I think that would provide a way for you to do what I think you're trying to do, without having to patch a sentinel string value into the file rules.

Indeed, this is a tricky situation. At first, I was going to emphatically suggest switching to using the scene_linear role, but I've come around to fully grasping your concerns with the default config causing oiioltool foo.exr -o bar.exr to persist unverified, potentially incorrect metadata. I definitely think that it's not a good idea to infer otherwise nonexistent colorInteropID metadata automatically from OIIO's default ColorConfig's default file rule unless the user is actually invoking some aspect of OCIO / OIIO's color management.

At the same time, I'm uneasy about using empty strings to intentionally elicit error states, if we can possibly avoid doing so. Something I try to keep in mind when I'm thinking about hacking around OCIO's designed behavior is, how are other OCIO hosts in the pipeline likely to behave under similar circumstances? Do we risk surprising users or stepping on config authors who expect all OCIO hosts to behave more or less the same way? Do the benefits of doing stuff differently outweigh the tech-debt costs working around the way OCIO "wants to" behave? Am I burdening others by injecting additional complexity into an already-complex system? Usually, I come around, one way or another, to aligning what I'm trying to do to what OCIO already does, to whatever degree possible.

So, if we consider OCIO v2 FileRules behavior to be the lowest common denominator, what do we gain by allowing filepath parsers to return empty strings, given that OCIO has deprecated such v1-style behavior?

That's not to say we shouldn't allow empty-string responses -- I just mean, if we decide to go that route, we should have pretty good reasons for doing so; and we should work to contain the blast radius of what we break and how we break it.

One last thing: if we do want to emit empty strings, we should strongly consider using the config's strict_parsing attribute to allow config authors opt in to potentially breaking behavior.

Copy link
Copy Markdown
Collaborator Author

@lgritz lgritz May 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find your long-assed commentary extremely valuable, thank you for it. I really need this to help me think it through.

I'm really thinking about this as two separate problems:

  1. Short term and back-portable to 3.1: I need to immediately fix the really awful issues of (a) autocc with default configs unexpectedly considering exr to be ap0, and (b) raw/unmanaged color spaces of inputs getting laundered through IBA::colorconvert to look like a transform happened and they are in the destination space, when they are actually not.

  2. Long-term, hopefully ironed out to be a solid 3.2 feature: a more holistic, consistent approach to figuring out what's managed, unmanaged, and unknown, how each should be handled, and adhering to CIF as much as possible.

This PR is only meant to address part 1, be immediately deployable, and not make anything worse than it currently is. It doesn't need to fix all possible problems, and anything that did would probably be too much of a behavior change to backport to 3.1 anyway.

Copy link
Copy Markdown
Collaborator Author

@lgritz lgritz May 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One last thing: if we do want to emit empty strings, we should strongly consider using the config's strict_parsing attribute to allow config authors opt in to potentially breaking behavior.

I have to admit that I'm not really sure what that does or what else might break or change if I do it.

I'm still thinking that every suggestion needs to be considered in terms of whether it will "change/fix things that users will clearly consider broken now if they notice it" or "change the way it ought to be done in the future, when we can alter behavior as much as we want at a version boundary."

I guess I also have divided loyalties. Maybe 10% of the time I'm thinking "what does the color scientist / config author want oiio to do", but the other 90% of the time I'm primarily putting myself in the shoes of the end user who is directly using oiiotool in battle and wanting consistent and intuitive behavior regardless of what kooky config they might be stuck with.

DBG(" changed cs to \"{}\"\n", rules->getColorSpace(i));
} else
#endif
if (!strcmp(rules->getName(i), "Default")) {
// Default rule or one that matches everything -- for OIIO, we
// just want to change this to unknown. We made decisions about
// default per-file-format color space decisions in the individual
// readers. We don't even consider file extension to be reliable
// evidence of the file type.
Comment on lines +848 to +851
Copy link
Copy Markdown
Collaborator

@zachlewis zachlewis May 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting. In my mind, OCIO FileRules are a better place to store OIIO's format-specific colorspace defaults than scattered across the code base, because it keeps the coupling of extension and color space name in sync and unambiguous and easily to update in one place. But I guess it's kind of moot if the defaults we're using for non-EXR containers are always either "srgb_rec709_scene" or, very occasionally, "ocio:itu709_rec709_scene".

Anyway, whether the container defaults live in individual readers / writers or in an OIIO default config is entirely up to you -- as long as the strings you're hardcoding are known CIF or OCIO colorInteropIDs, everything should be gravy.

Copy link
Copy Markdown
Collaborator Author

@lgritz lgritz May 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2nd part first: Yes, the intent is that all hardcoded color space names that OIIO assigns will be CIF tokens.

1st part: OIIO doesn't really consider file names, even extensions, to be authoritative when reading. It's at most an initial guess. Some formats have many extensions that are sanctioned, some facilities or apps have custom extensions (like how many places use .tx for TIFF textures that are properly tiled and MIPmapped, though the TIFF standard never mentions this extension), and sometimes files are just plain mislabeled.

rules->setColorSpace(i, "unknown");
DBG(" changed cs to \"{}\"\n", rules->getColorSpace(i));
}
}

// But make the path search rule (look for the right-most color space name
// embedded in the path) have precedence over file naming rules.
rules->insertPathSearchRule(0);
config->setFileRules(rules);
}



bool
ColorConfig::Impl::init(string_view filename)
{
Expand All @@ -825,7 +872,10 @@ ColorConfig::Impl::init(string_view filename)
OCIO::SetLoggingLevel(OCIO::LOGGING_LEVEL_NONE);

try {
builtinconfig_ = OCIO::Config::CreateFromFile("ocio://default");
auto cfg = OCIO::Config::CreateFromFile("ocio://default");
OIIO_CONTRACT_ASSERT(cfg);
builtinconfig_ = cfg->createEditableCopy();
fix_config_file_rules(builtinconfig_);
} catch (OCIO::Exception& e) {
error("Error making OCIO built-in config: {}", e.what());
}
Expand All @@ -841,10 +891,13 @@ ColorConfig::Impl::init(string_view filename)
} else {
// Either filename passed, or taken from $OCIO, and it seems to exist
try {
config_ = OCIO::Config::CreateFromFile(
std::string(filename).c_str());
configname(filename);
m_config_is_built_in = Strutil::istarts_with(filename, "ocio://");
auto cfg = OCIO::Config::CreateFromFile(
std::string(filename).c_str());
if (cfg)
config_ = cfg->createEditableCopy();
if (config_ && Strutil::istarts_with(filename, "ocio://"))
fix_config_file_rules(config_);
} catch (OCIO::Exception& e) {
error("Error reading OCIO config \"{}\": {}", filename, e.what());
} catch (...) {
Expand Down Expand Up @@ -2344,33 +2397,36 @@ ImageBufAlgo::colorconvert(ImageBuf& dst, const ImageBuf& src, string_view from,
from = src.spec().get_string_attribute("oiio:Colorspace",
"scene_linear");
}
if (from.empty() || to.empty()) {
dst.errorfmt("Unknown color space name");
if (from.empty() || from == "unknown" || to.empty() || to == "unknown") {
dst.errorfmt("Unknown color space name (from=\"{}\", to=\"{}\")", from,
to);
return false;
}
ColorProcessorHandle processor;
{
if (!colorconfig)
colorconfig = &ColorConfig::default_colorconfig();
processor
= colorconfig->createColorProcessor(colorconfig->resolve(from),
colorconfig->resolve(to),
context_key, context_value);
if (!processor) {
if (colorconfig->has_error())
dst.errorfmt("{}", colorconfig->geterror());
else
dst.errorfmt(
"Could not construct the color transform {} -> {} (unknown error)",
from, to);
return false;
}

if (!colorconfig)
colorconfig = &ColorConfig::default_colorconfig();

ColorProcessorHandle processor
= colorconfig->createColorProcessor(colorconfig->resolve(from),
colorconfig->resolve(to),
context_key, context_value);
if (!processor) {
if (colorconfig->has_error())
dst.errorfmt("{}", colorconfig->geterror());
else
dst.errorfmt(
"Could not construct the color transform {} -> {} (unknown error)",
from, to);
return false;
}

logtime.stop(-1); // transition to other colorconvert
bool ok = colorconvert(dst, src, processor.get(), unpremult, roi, nthreads);
if (ok) {
// Coming from a non-color space preserves the original space
// DBG("done, setting output colorspace to {}\n", to);
if (colorconfig->isData(from))
to = from;
dst.specmod().set_colorspace(to);
}
return ok;
Expand Down
2 changes: 2 additions & 0 deletions src/oiiotool/oiiotool.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5566,6 +5566,8 @@ input_file(Oiiotool& ot, cspan<const char*> argv)
// Try to deduce the color space it's in
std::string colorspace(
ot.colorconfig().getColorSpaceFromFilepath(filename, "", true));
if (colorspace == "unknown")
colorspace.clear();
Copy link
Copy Markdown
Collaborator

@zachlewis zachlewis May 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tl;dr -- I think we should check if the config recognizes "unknown" as a valid color space; if not, we should set colorspace to an empty string if strict_parsing is enabled in the config; otherwise, use the default role.

We need to make sure we're not interfering with config authors who want to define custom behavior for handling cases where colorInteropID == "unknown". For example, a config author might create a do-nothing color space called "unknown" in order to capture and route images so tagged through a special "error" default view, so that when the view is enabled in image browsers / thumbnail previewers (or oiitool's default behavior when empty strings are provided as arguments for --ociodisplay), it's extremely easy to distinguish media explicitly tagged as "unknown" from untagged media and color managed media.

We need clarity from CIF about this -- it isn't clear how hosts should handle cases where colorInteropID == "unknown", and "unknown" is a valid color space in the config. I think the safest way to convert colorInteropID strings --> OCIO color space names is for hosts to interpret "unknown" as a signal to try the config's FileRules with the file path, i that information is available, and fail over to the "unknown" color space, instead of the "default" color space.

There's a subtle but important implication for OIIO here: colorInteropID and oiio:ColorSpace metadata communicate similar but distinct information -- colorInteropID is prescriptive of behavior ("use the CIF guidelines to translate 'srgb_rec709_scene' into something your color management framework can reason about), while oiio:ColorSpace is descriptive of internal state of the ImageBuf, as identified and understood by OIIO. In practice, this means,

  • If both colorInteropID and oiio:ColorSpace are unset: OIIO should go ahead and try to divine meaning from whatever other information is available (other color metadata, embedded ICC profiles, file paths...); if all else fails, return an empty string if strict_parsing is enabled in the config; otherwise, fail over to the default color space.
  • if colorInteropID == "unknown" and oiio:ColorSpace is unset: same as above, but fail over to the "unknown" color space if it happens to exist before returning either the default color space or an empty string.
  • If oiio:ColorSpace == "unknown": OIIO has already tried and failed to resolve the color space, and has failed over to the "exit state" color space as intended by config authors who want to elicit specific behavior for failing to identify explicitly "unknown" colorInteropID metadata.

Copy link
Copy Markdown
Collaborator Author

@lgritz lgritz May 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a couple interpretations possible, so let's get more explicit.

"colorInteropID"

This is either (a) what was actually found in the file as metadata with this name, or possibly (b) set by OIIO when if we know for sure what the color space is AND it corresponds to a known CIF token.

Distinguishing these depends on our answer to the following: For a file format like DPX that is unaware of CIF and does not have metadata called "colorInteropID", but nonetheless has differently named fields, which may at least sometimes specify a CIF-known colorspace, should we set this metadata in the ImageSpec (when it corresponds to a known token) or not?

"oiio:ColorSpace"

This continues to be an internal-only (i.e. never written to files as metadata with this name) OIIO-specific hint about what we think the pixels are. This can be a CIF token, but I'm not sure it needs to be restricted to that.

When I set "oiio:ColorSpace" to "unknown", that's for OIIO to communicate with itself.

Though I see what you mean about a case where a config has a known color space called "unknown". I'm just not sure if this is a real situation that we should care about, just like there could be a color space called "lin_rec709_scene" that is really something else, or a trick to handle that color space in a special way.

Copy link
Copy Markdown
Collaborator

@zachlewis zachlewis May 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though I see what you mean about a case where a config has a known color space called "unknown". I'm just not sure if this is a real situation that we should care about, just like there could be a color space called "lin_rec709_scene" that is really something else, or a trick to handle that color space in a special way.

I 100% agree that it would vastly simplify things if all around if we weren't concerned with color spaces named "unknown" -- pretty much all of my concerns pertain to the implications of writing or not writing "unknown" colorInteropID metadata for pipelines that use OCIO to imbue special handling of "unknown" metadata. Unfortunately, unless the Color Interop Forum guides against it, or OpenColorIO disallows it, I don't think it's safe to assume config authors aren't relying on color spaces named "unknown" to steer "explicit unknown" colorInteropID behavior. Given the unique behavior of the "unknown" CIID compared to the others, I don't think it's a stretch to presume that OCIO config authors might complement the "unknown" CIID's unique behavior with similarly uniquely behaving "unknown" OCIO color spaces. For better or worse, the current CIF guidelines coupled with OCIO's architecture makes it possible to orchestrate pretty complex (and fancy!) behaviors pertaining to reading and writing explicitly "unknown" colorInteropID metadata.

Is this a real situation we should care about? I dunno. I'd argue, per Hyrum's Law that the situation is real enough to warrant considerable thought and caution at this stage, to make sure we aren't building around assumptions that prove difficult to back out of should they prove false. On the other hand, I'm not sure if I'm trying to protect for workflows that the Color Interop Forum is consciously trying to permit. I don't think too many other people have given this as much thought as I have; and, as you know by now, I am batshit insane, so I could definitely be fretting about nothing.

I would love for OIIO to support such workflows almost as much as I would love CIF / OCIO to explicitly disallow naming color spaces "unknown", so OIIO wouldn't have to worry about supporting such workflows.

Copy link
Copy Markdown
Collaborator Author

@lgritz lgritz May 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, there is a sense in which my use of "unknown" in this PR is arbitrary. It's a signal from OIIO to other parts of OIIO, really. It will never get saved to a file, because... the ONLY color space "name" that's saved to a file is colorInteropID to exr files, and we only do that if it's a recognized CIF token.

So we could pick a different name, something that would never be found in a config. Would that help you sleep better at night? Are there any characters that have always been disallowed in OCIO color space names?

if (colorspace.size() && ot.debug)
OIIO::print(" From {}, we deduce color space \"{}\"\n",
filename, colorspace);
Expand Down
65 changes: 65 additions & 0 deletions testsuite/oiiotool-color/ref/out-ocio2.3.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
oiiotool ERROR: --colorconfig : Requested non-existent OCIO config "missing.ocio"
Full command line was:
> oiiotool --nostderr --colorconfig missing.ocio -echo "Nonexistent config"
nope: 0.5,0.5,0.5 half
raw: 0.5,0.5,0.5 half
acescg: 0.5,0.5,0.5 half
srgb_tx: 0.5,0.5,0.5 half
nope: 0.5,0.5,0.5 half
raw: 0.5,0.5,0.5 half
acescg: 0.5,0.5,0.5 half
srgb_tx: 0.5,0.5,0.5 half
Comparing "colormap-inferno.tif" and "ref/colormap-inferno.tif"
PASS
Comparing "colormap-custom.tif" and "ref/colormap-custom.tif"
PASS
Comparing "unpremult.exr" and "ref/unpremult.exr"
PASS
Comparing "premult.exr" and "ref/premult.exr"
PASS
Comparing "contrast-stretch.tif" and "ref/contrast-stretch.tif"
PASS
Comparing "contrast-shrink.tif" and "ref/contrast-shrink.tif"
PASS
Comparing "contrast-inverse.tif" and "ref/contrast-inverse.tif"
PASS
Comparing "contrast-threshold.tif" and "ref/contrast-threshold.tif"
PASS
Comparing "contrast-sigmoid5.tif" and "ref/contrast-sigmoid5.tif"
PASS
Comparing "display-sRGB.tif" and "ref/display-sRGB.tif"
PASS
Comparing "rgbfromtga.png" and "ref/rgbfromtga.png"
PASS
Comparing "greyalpha_sRGB.tif" and "ref/greyalpha_sRGB.tif"
PASS
Comparing "greyalpha_sRGB_un.tif" and "ref/greyalpha_sRGB_un-ocio22.tif"
PASS
Comparing "grey_sRGB.tif" and "ref/grey_sRGB.tif"
PASS
Comparing "grey_sRGB_un.tif" and "ref/grey_sRGB_un.tif"
PASS
Comparing "tahoe-ccmatrix.tif" and "ref/tahoe-ccmatrix.tif"
PASS
Comparing "tahoe-sat0.tif" and "ref/tahoe-sat0.tif"
PASS
Comparing "tahoe-sat2.tif" and "ref/tahoe-sat2.tif"
PASS
Comparing "cmap-magma.tif" and "ref/cmap-magma.tif"
PASS
Comparing "cmap-inferno.tif" and "ref/cmap-inferno.tif"
PASS
Comparing "cmap-plasma.tif" and "ref/cmap-plasma.tif"
PASS
Comparing "cmap-viridis.tif" and "ref/cmap-viridis.tif"
PASS
Comparing "cmap-turbo.tif" and "ref/cmap-turbo.tif"
PASS
Comparing "cmap-blue-red.tif" and "ref/cmap-blue-red.tif"
PASS
Comparing "cmap-spectrum.tif" and "ref/cmap-spectrum.tif"
PASS
Comparing "cmap-heat.tif" and "ref/cmap-heat.tif"
PASS
Comparing "look-default.tif" and "ref/look-default.tif"
PASS
8 changes: 8 additions & 0 deletions testsuite/oiiotool-color/ref/out.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,14 @@
oiiotool ERROR: --colorconfig : Requested non-existent OCIO config "missing.ocio"
Full command line was:
> oiiotool --nostderr --colorconfig missing.ocio -echo "Nonexistent config"
nope: 0.5,0.5,0.5 half
raw: 0.5,0.5,0.5 half
acescg: 0.5,0.5,0.5 half
srgb_tx: 0.213989,0.213989,0.213989 half
nope: 0.5,0.5,0.5 half
raw: 0.5,0.5,0.5 half
acescg: 0.5,0.5,0.5 half
srgb_tx: 0.735352,0.735352,0.735352 half
Comparing "colormap-inferno.tif" and "ref/colormap-inferno.tif"
PASS
Comparing "colormap-custom.tif" and "ref/colormap-custom.tif"
Expand Down
31 changes: 31 additions & 0 deletions testsuite/oiiotool-color/run.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,9 @@

import os

redirect = " >> out.txt 2>&1 "


# print("ociover =", ociover)

# Make test pattern with increasing intensity left to right, decreasing
Expand Down Expand Up @@ -97,6 +100,34 @@
# test various behaviors and misbehaviors related to OCIO configs.
command += oiiotool ("--nostderr --colorconfig missing.ocio -echo \"Nonexistent config\"", failureok=True)

# Test what happens with autocc and input files with color space names in
# their filenames, for both color-managed and non-color-managed spaces.
#
# Input: We transform an exr with each name to acescg, with autocc.
# - "nope" is an unknown color space, and should warn.
# - "raw" means known to be not color managed, and should warn.
# - "acescg" is known and should end up with output (as acescg) that is
# unchanged, so the value should still be 0.5.
# - "srgb_tx" is known but should make a real transformation, giving a pixel
# value that is not 0.5.
for c in ("nope", "raw", "acescg", "srgb_tx") :
command += oiiotool (f"--pattern constant:color=.5 1x1 3 -d half -o in_{c}.exr")
command += oiiotool (f"--autocc in_{c}.exr -o out_acescg.exr")
command += oiiotool (f"out_acescg.exr -echo \"{c}: {{TOP.AVGCOLOR}} {{TOP.nativeformat}}\"")
# Output: We transform an acescg image to outputs with each name, with autocc.
# - "nope" is an unknown color space, and should warn. Or should it?
# - "raw" should retain the 0.5 value with no warning, since you're asking to
# output a non-color-manaaged image.
# - "acescg" is known and should end up with output (as acescg) that is
# unchanged, so the value should still be 0.5.
# - "srgb_tx" is known but should make a real transformation, giving a pixel
# value that is not 0.5.
for c in ("nope", "raw", "acescg", "srgb_tx") :
command += oiiotool (f"--pattern constant:color=.5 1x1 3 -d half -iscolorspace acescg "
+ f"-autocc -o out_{c}.exr")
command += oiiotool (f"out_{c}.exr -echo \"{c}: {{TOP.AVGCOLOR}} {{TOP.nativeformat}}\"")



# To add more tests, just append more lines like the above and also add
# the new 'feature.tif' (or whatever you call it) to the outputs list,
Expand Down
59 changes: 59 additions & 0 deletions testsuite/python-colorconfig/ref/out-ocio230.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
getNumColorSpaces = 15
getColorSpaceNames = ['ACES2065-1', 'ACEScc', 'ACEScct', 'ACEScg', 'Linear P3-D65', 'Linear Rec.2020', 'Linear Rec.709 (sRGB)', 'Gamma 1.8 Rec.709 - Texture', 'Gamma 2.2 AP1 - Texture', 'Gamma 2.2 Rec.709 - Texture', 'Gamma 2.4 Rec.709 - Texture', 'sRGB Encoded AP1 - Texture', 'sRGB Encoded P3-D65 - Texture', 'sRGB - Texture', 'Raw']
Index of 'lin_srgb' = 6
Index of 'unknown' = -1
Name of color space 2 = ACEScct
getNumLooks = 1
getLookNames = ['ACES 1.3 Reference Gamut Compression']
getNumDisplays = 6
getDisplayNames = ['sRGB - Display', 'Display P3 - Display', 'Rec.1886 Rec.709 - Display', 'Rec.2100-PQ - Display', 'ST2084-P3-D65 - Display', 'P3-D65 - Display']
getDefaultDisplayName = sRGB - Display
getNumViews = 3
getViewNames = ['ACES 1.0 - SDR Video', 'Un-tone-mapped', 'Raw']
getDefaultViewName = ACES 1.0 - SDR Video
getNumRoles = 9
getRoles = ['aces_interchange', 'cie_xyz_d65_interchange', 'color_picking', 'color_timing', 'compositing_log', 'data', 'matte_paint', 'scene_linear', 'texture_paint']
aliases of 'scene_linear' are ['ACES - ACEScg', 'lin_ap1']
resolve('foo'): foo
resolve('linear'): Linear Rec.709 (sRGB)
resolve('scene_linear'): ACEScg
resolve('lin_srgb'): Linear Rec.709 (sRGB)
resolve('srgb'): sRGB - Texture
resolve('ACEScg'): ACEScg
equivalent('lin_srgb', 'srgb'): False
equivalent('scene_linear', 'srgb'): False
equivalent('linear', 'lin_srgb'): False
equivalent('scene_linear', 'lin_srgb'): False
equivalent('ACEScg', 'scene_linear'): True
equivalent('lnf', 'scene_linear'): False
get_color_interop_id('ACEScg') = lin_ap1_scene
get_color_interop_id('lin_srgb') = lin_rec709_scene
get_color_interop_id([1, 13, 1, 1]) = srgb_rec709_scene
get_cicp('pq_rec2020_display') = [9, 16, 9, 1]
get_cicp('unknown_interop_id') = None
isColorSpaceLinear('scene_linear') = True
isColorSpaceLinear('srgb') = False
isData('scene_linear') = False
isData('Raw') = True
equivalent('ACEScg', 'Raw'): False
getColorSpaceFromFilepath('in_acescg.exr') = ACEScg
getColorSpaceFromFilepath('in_srgb_tx.exr') = sRGB - Texture
getColorSpaceFromFilepath('in_raw.exr') = Raw
getColorSpaceFromFilepath('none.exr') = unknown
getColorSpaceFromFilepath('noclue.exr') = unknown

Loaded test OCIO config: oiio_test_v0.9.2.ocio
Parsed color space for filepath 'foo_lin_ap1.exr': ACEScg
Default color space: lin_rec709
Default display: sRGB (~2.22) - Display
Default view for sRGB (~2.22) - Display (from lin_rec709): ACES 1.0 - SDR Video
Default view for sRGB (~2.22) - Display (from 'srgb_tx'): Colorimetry
Color space name from DisplayView transform referencing Shared View: sRGB (~2.22) - Display
Test buffer -- initial values: [[[0.1 0.5 0.9]]] (ACEScg)
ociodisplay #1 (apply default display/view): [[[-2.123 0.671 0.8037]]] (sRGB (~2.22) - Display)
ociodisplay #2 (apply default display/view again): [[[-2.783 0.766 0.9873]]] (sRGB (~2.22) - Display)
ociodisplay #3 (inverse look): [[[-18.22 0.876 2.121]]] (sRGB (~2.22) - Display)
ociodisplay #4 (forwards look): [[[-21330. 29.03 100.4 ]]] (sRGB (~2.22) - Display)
ociodisplay #5 (inverse look + forwards look): [[[93.44 93.44 93.44]]] (sRGB (~2.22) - Display)

Done.
Loading
Loading