define which color metadata OpenImageIO trusts, and when it resolves it

Start with #5507, #5514, and #5422, then trace the PNG reader, set_colorspace(), colorconvert, ociolook, ociodisplay, FLIP, and oiiotool entry points named in the proposal. Done means the agreed evidence precedence, assignment semantics, conversion cleanup, multipart OpenEXR behavior, and listed oiiotool follow-ups are implemented consistently; the maintainer questions still need decisions.

OpenImageIO makes color-space decisions in readers, in conversions and in
explicit assignment. These paths can read the same file differently, or leave
source metadata beside a destination label, so an image can end up making a
color-space claim its file does not support.

This covers the #4980 items "Refactor reading color space metadata to share
logic", "Deferred and unified resolution of color interop ID from metadata",
"Read cicpTag from ICC profile" and "Determine interop ID from ICC profile
by comparing OCIO transforms". It builds on #5507 and #5514, and extends
the multipart OpenEXR handling from #5422. Related discussions: #3114
(converting from an embedded ICC profile) and #5134 (stale ACES container
metadata after assignment). Upcoming PRs implement it.

Proposal

1. Readers record file facts; callers resolve them. #5507 stops readers
   from consulting a color config. Building on that, the PNG reader parses
   cICP, sRGB, gAMA and cHRM itself, because libPNG before 1.6.47
   rewrites or drops some of them while reading (and before 1.6.45 ignores
   cICP). gAMA alone is recorded as oiio:Gamma with no label, since it
   states no primaries. gAMA with Rec.709 cHRM keeps the Rec.709-gamma
   label; an sRGB chunk, or no color chunk at all, still means sRGB. A file's
   own colorInteropID of unknown is kept as evidence, not as a label.

2. set_colorspace() is an assertion.

   • set_colorspace(name) makes the name or
     color interop ID
     authoritative, even when it is already the label. Other color attributes
     are kept if they agree, rewritten if the name determines them, and
     removed otherwise (including acesImageContainerFlag).
   • set_colorspace("") erases only the label; the evidence stays.
   • set_colorspace() with no argument sets an unset label from the
     evidence, and only to a configured color space or a color interop ID.
   • set_colorspace("unknown") states that nothing is known and removes the
     other evidence.

3. One evidence order: explicit assignment; the ACES container flag;
   colorInteropID; cICP; a supported RGB matrix/TRC ICC profile; the PNG
   sRGB chunk; numeric metadata (PNG gAMA with or without cHRM, OpenEXR
   chromaticities); the reader's label; a caller's failover. oiiotool can
   also consult OCIO FileRules, either first or just before the reader's
   label. PNG gAMA alone selects the first configured space with that
   transfer, display-referred spaces first, and assumes its primaries. For a
   conversion, an ICC profile or complete numeric metadata that matches no
   known encoding gets a process-local conversion endpoint (<synthetic>...);
   unmatched gAMA alone gets one for its transfer only. That endpoint is never stored as a label or written as a colorInteropID.
   LUT-based ICC profiles make no claim.

4. One resolver for every implicit source: colorconvert, ociolook,
   ociodisplay, FLIP, oiiotool --autocc, and terminal output. It runs
   under the caller's config and effective OCIO context, the same ones the
   processor uses. Metadata that was stated but cannot be used resolves to
   unknown, never to linear, unless the config defines a space named
   unknown. After a conversion, source-encoding metadata is removed and the
   result is tagged with its destination, including a colorInteropID. That
   ID is unknown when there is no single portable destination, such as a
   partial region or a context override.

5. OpenEXR. A part's own colorInteropID wins. An ID a later part
   inherits from part 0 (#5422) is only a label, so that part's own ICC
   profile or chromaticities can outrank it. An inherited unknown stays
   evidence, and strict multipart validation treats unknown like a missing
   ID. Writers treat chromaticities as a claim of linear encoding. They drop
   chromaticities that contradict the header's ID; with no ID, they keep them
   only beside oiio:Gamma 1, and otherwise write colorInteropID unknown.
   Chromaticities that agree with a linear colorInteropID are still written
   beside it. This is a deliberate, temporary departure from the
   OpenEXR recommendation,
   which advises against writing both, so that readers have time to adopt
   colorInteropID. A future change will stop writing them by default.

Smaller follow-ups covered by this issue

• oiiotool --runstats prints color cache statistics (retained entries, ICC
  bytes, cold-work counters) when the run built a color config.
• oiiotool --colorspacesearch lists configured color spaces that match
  requested primaries, measured transfer, encoding or scene/display use,
  without needing an image. Its property display separates an authored
  declared-linear from a transfer measured to be linear.
• oiiotool --colortransfer prints a color space's exact encoding transfer
  function as CTF, CLF or OCIO syntax, under the effective OCIO context. It
  reports an error when the curve cannot be stated exactly, rather than
  approximating it.

Behavior this changes

• Asserting the current label again now reconciles the metadata; before, it
  changed nothing.
• A PNG with only gAMA is no longer labeled as a Rec.709 gamma. Non-Rec.709
  cHRM with gAMA can now identify a configured source.
• colorconvert and ociodisplay with an empty or current source used
  scene_linear. Now they resolve the image's metadata, and for an image that
  states nothing they follow the config (its default file rule, then its
  default role, or unknown under strict parsing). ociolook, FLIP and terminal output still treat a
  completely silent image as scene_linear. --autocc still leaves silent
  inputs unconverted by default.
• colorconvert can convert from a supported (RGB matrix/TRC) embedded ICC
  profile.
• A later OpenEXR part's own evidence can override an inherited label.
• Converted images no longer carry the source's chromaticities.

Questions for maintainers

1. Are the assertion semantics right, including "" versus no argument, and
   "unknown" as an assertion versus a file's unknown as evidence?
2. For multipart OpenEXR, should an inherited ID stay a weak label, or be
   represented separately?
3. Is keeping chromaticities beside an agreeing linear colorInteropID the
   right transition, and when should the default flip?
4. Should process-local endpoints for unmatched ICC and numeric metadata be
   on by default?

Assisted-by: OpenAI Codex (GPT-5.6 Sol)
Assisted-by: Claude Code / Claude Opus 5.5