Proposal: a `bypass` Color Interop ID

[zachlewis]

Proposal: a bypass Color Interop ID

Revised 2026-06-12 — handling simplified and clarified per the discussion below; the
original text is preserved in this issue's edit history.

Problem Statement

A real color interop ID is one deterministic endpoint: everything known, the image
handled correctly everywhere that recognizes it. data is the other: heuristics off,
held as-is, identical behavior in every application. Everything between — unknown,
absent, partial container metadata — is the middle ground where each application guesses
differently, by design.

The catch: today the OFF switch asserts the image isn't color. To hold real color as-is
— a vendor passthrough, a deferred grading decision, reference media in an editorial
timeline — a writer has to lie. unknown is the honest alternative to guessing; there
is no honest alternative to misusing data: a deliberate hold has no spelling that
doesn't either claim "not color" or invite exactly the guess it means to forbid. The
practice is already common ("set it to raw so the app doesn't touch it"); the only real
question is whether its spelling lies.

Nothing here changes the meaning of unknown (≡ absent) or data.

CIID	The writer means	Reader may guess a space?	Other color metadata
data	not color — don't manage it	No — no-op	not used
unknown	no reliable value (incl. absent)	Yes — file rules / metadata / hints	used to resolve
bypass	color, deliberately unidentified — hold as-is	No — held until re-tagged	not used for resolution while tagged

Proposal

Reserve bypass: this is color, deliberately left unidentified — hold it as-is,
don't guess, carry the tag until someone re-tags it. data and bypass are two faces
of the same no-op routing: identical reader behavior, differing only in the content
claim — data says "not color"; bypass says "color, encoding deliberately withheld."

• Readers: exactly data's obligations. Wherever an implementation already has a
  data behavior — including format conversion, ICC handling, transcoding — apply it
  unchanged. The complete ask of a non-participating implementation: persist the string,
  never volunteer it, don't extend unknown's fallback handling to it.
• Precedence is positional. bypass governs only the machinery downstream of the
  CIID in the reading order: mechanisms that resolve before the ID is consulted
  (acesImageContainer, reading step 1) win exactly as today — a reader MAY warn;
  mechanisms that resolve after it (file rules, chromaticities/CICP fallback, step 4)
  are suppressed while the tag is present. Writers must never emit acesImageContainer
  together with bypass. bypass adds no new preservation requirement on other color
  metadata — per-format conventions apply unchanged; while tagged, that metadata is
  simply not used for resolution.
• Writers: the one hard rule. Applications MUST NOT emit bypass on their own
  initiative; it is set only at the explicit direction of a user, a config, or a
  pipeline step a person configured. This is what keeps the tag meaningful — its
  presence always reflects a decision.
• Persistence. bypass asserts intent, not fidelity: "this is color, no encoding
  is asserted, do not guess." Any derived output for which that remains true
  (re-encodes, crops, pixel operations on the held image) keeps the tag, by the same
  convention any CIID persists through a non-color-converting write. The tag clears only
  on a deliberate act: re-tag to a real ID; re-tag to data if found non-color; or
  downgrade to unknown/unset to re-enable resolution from other metadata.
• The user override. bypass binds automatic behavior, never a user: an explicit
  re-tag or conversion decision always wins — it is the tag's intended exit. An explicit
  request to convert to a space supplies a destination, not a source; while tagged, a
  tool shouldn't substitute its untagged-input assumption — ask for the source.
  Supplying one is the re-tag.
• Scope of the guarantee. bypass rides colorInteropID and inherits its carriage;
  per-format carriage is each format rec's existing job for all CIIDs. The hold is
  guaranteed across hops that preserve colorInteropID and degrades to today's status
  quo at any hop that doesn't — never worse than the present baseline.
• Multi-part EXR: the same first-part / per-part convention as data; specifics
  belong to the OpenEXR rec.

Transition

Today a legacy reader treats bypass as an unrecognized ID — per the existing rec,
surfaced rather than silently guessed. Behavior converges to hold-everywhere as readers
adopt, and is never worse than the status quo meanwhile. The interim is also the
urgency: until an honest spelling exists, the dishonest one keeps accumulating — every
year deepens the installed base of data-tagged color, and installed bases fossilize.

What OCIO would need

• Recognize bypass as a reserved un-namespaced interop ID alongside data and
  unknown (the character grammar already accepts the string).
• Resolvers that already special-case data/unknown as non-resolvable sentinels add
  bypass to the same guard.

Suggested patches to existing documents

Color Interop ID rec — one definition alongside data/unknown:

bypass — color whose encoding is deliberately withheld. On read, handle exactly like
data (do not color manage; do not auto-assign a color space); persist the ID until a
user or pipeline step explicitly re-tags the image.

OpenEXR rec, Writing steps — insert after step 1:

1a. If the image is color but is deliberately being left unidentified for a later step
to resolve, set the colorInteropID to "bypass". Unlike "unknown", readers will not
auto-assign a color space to it. Applications must not set "bypass" on their own
initiative.

OpenEXR rec, Reading steps — extend step 2's first sentence:

If the colorInteropID is "data" or "bypass", the images should not be color
managed.

Figure 2 (read): E{Is InteropID _data_?} → E{Is InteropID _data_ or _bypass_?}

Figure 1 (write): split node C's False edge:
C--False-->W{Deliberately holding as-is?} · W--True-->X["Set InteropID to _bypass_"]-->M · W--False-->F[…unchanged…]

An executable demo exists — a loadable OCIO config plus an OpenImageIO notebook showing
the held/managed/unknown cases side by side in one timeline — happy to share.

Decision requested

Reserve one ID whose reading rule is data's, for color. The proposal is refuted iff
the forum holds either (a) that data may legitimately be applied to color
encodings to elicit unmanaged behavior — in which case bypass is redundant, and data
now officially means "don't touch" rather than "not color"; or (b) that a deliberate
hold should not ride in image metadata at all. If neither, the proposal follows.

Open question: the name

bypass is proposed — it reads as the instruction it is ("bypass attempts to
automatically manage color"). A naming review also shortlisted passthrough (strong
broadcast precedent; hyphenation instability) and hold_color (carries the is-color
claim in the string; compound form). Alternatives welcome — we avoided raw (already an
alias of Data in common configs) and "un-" words (they read as absence, not intent).

[doug-walker]

Zach, thank you for this clear and detailed proposal. I'm curious how common this use-case is, this is not something I've run into before.

One question I have is what is blocking people from implementing this use-case with the current document. In other words, it's already possible to create an Interop ID zach:bypass and then add a bypass color space with that ID and isData=true to an OCIO config. That seems like it would give the desired behavior without placing any additional burden on implementers.

From an implementer point of view, the need to handle another special case (e.g., search for a color space where isData is true) adds complexity. I feel like we need to give implementers plenty of freedom about what to do if there is not a match for an ID. To forbid using file rules, or any other generally reasonable course of action, in this case seems problematic to me.

I'm not opposed to adding this as an official interop ID, or adding it to the default OCIO configs, as long as it may be handled the same way as the others. But before placing additional burdens on implementers, I think we should get input on how common a scenario this is. Will look forward to hearing other's thoughts.

[carolalynn]

Yeah thanks Zach for this, it's certainly interesting. But I think I disagree with the fundamental principle that an image should be able to control fully whether or not it is color-managed in an application or process. I think that decision should rely on a user/pipeline to set in a context (in an app, in a script, whatever) not in image metadata.

In your example of setting "no input transform" in nuke - if nothing else was happening in the node tree to change that decision, I actually think the correct color interop ID for the app to write to the file is the same one it came in with - i.e. the color space has not changed. If the app can't know that, write unknown.

Even if there is examples of where this would be useful, I'm not convinced it's a "correct" thing to ever do.

[lgritz]

Yeah thanks Zach for this, it's certainly interesting. But I think I disagree with the fundamental principle that an image should be able to control fully whether or not it is color-managed in an application or process. I think that decision should rely on a user/pipeline to set in a context (in an app, in a script, whatever) not in image metadata.

I'm not sure I understand the distinction in practice.

It's already in some sense not the image saying it. Somebody/something put that nugget into the image, and that is the user/pipeline that you are wanting to hear from. But the image itself is the handoff between two halves of the pipeline (which may exist in totally different software systems or facilities, so this is the only coordination point they have).

[carolalynn]

The color management. (i.e. OCIO) should be another coordinating factor between apps/facilities (on a specific project). The image just is what it is, or it's unknown.

[lgritz]

Yeah, but what I'm saying is that they are two different software systems, separated in time and space and design, that don't necessarily even know about each other. There is no coordinating factor other than the image. We're not talking about a full pipeline that was coherently designed within one controlled facility or process. I think that's the use case we're worried about here.

[carolalynn]

I guess.... I just don't understand how 'unknown' doesn't solve this.

[lgritz]

I don't want to put words in Zach's mouth, and maybe I'm misunderstanding, too.

But imagine a pipeline where I have an image, and I don't know what it is (some flavor of unknown to me), and I'm handing it off to some intermediate pipeline that will do some things to it and then save it out again. One of those steps along the way might see something unknown, and apply a default, or file rule, or whatever (like maybe it will assume that an "unknown" exr must be using ap0 primaries). As it passes it through the chain having made that assumption, by the time it gets written at the end of the chain, what should the output file say it is?

I think that the distinction Zach is making is between three scenarios:

1. It's explicitly known to be not color. We call this "data".
2. I don't know what it is, but I'm ok with assumptions possibly being made downstream. I think that's what Zach is calling "unknown." It's a non-committal unknown. I don't know, but maybe you do.
3. It's really unknown (STOMPS FEET), and I want it to STAY unknown all the way to the other side of that pipeline, and not get laundered into thinking it's known. That's "bypass"?

Local unknown that might get defaulted versus "sticky" unknown?

[carolalynn]

To me, asking an image to direct an application in that way is outside the scope of what an image should reliably do. You're basically saying "I, the image, regardless of anything, am telling you that I am unknown and to not try to do anything about that". I'm fine with the unknown bit, what I'm not fine with is the image alone being an arbiter of decision making.

It feels like we're trying to retrofit a solution into an image that does not belong there, it belongs in user/developer control of pipelines and applications where we feel a workflow is missing?

It honestly feels like what folks are really still objecting to is the functionality of OCIO file rules. and if that's the case, let's discuss there, and not try and shoehorn solutions elsewhere.

[zachlewis]

Interesting... I'll be working on a v2 draft over the weekend that hopefully clarifies things...

Let me try framing this another way... as I understand the OpenEXR guidelines, setting colorInteropID to data provides a way to "short-circuit" the entire colorspace-resolution-heuristics block of the diagram entirely on the reader side -- as soon as colorInteropID == data is detected, we immediately resolve an isData=True color space before considering any other metadata or file rules or any other hints. And because isData=True color spaces elicit NoOp processors when used as a source for ColorSpaceTransforms and DisplayViewTransforms, it means setting the colorInteropID to "data" prevents readers from considering other metadata / heuristics, and nullifies any automatic conversions that might otherwise take place (e.g., conforming to a timeline working space). In other words, setting colorInteropID to "data" is functionally equivalent to telling readers to "treat as raw", and leave the buffer "as-is" -- nothing happens automatically, no matter what metadata is present, acesImageContainerFlag aside). If you're with me, it follows that OCIO config authors can create color spaces that allow users to selectively imbue images with "sticky-unknown" (known-unknown) reader behavior, the same way they'd use interop_id attribures to imbue images with "auto-color-convert-to-working-space" reader behavior... e.g., something like...

   - !<ColorSpace> {name: Bypass, aliases: [known:unknown, data], interop_id: data, categories: [file-io], isData: true}

ANYWAY -- my point is, if my logic holds, under the current guidelines, setting colorInteropID == "data" functionally serves as a "forcibly-switch-off-color-management" signal to downstream readers. There are very valid reasons for imbuing this "sticky-unknown" read behavior to unspecified color (non-data) encodings; and I think it's extremely likely that the "data" CIID will be exploited for its unique "color-management-bypass" prescriptive behavior (i.e. for data and non-data encodings alike), thus poisoning the "descriptive" validity of the attribute).

So, the question is... do we care if people tag data and non-data encodings alike as CIID data? Is it important that we provide a way to support pipelines that explicitly distinguish and preserve the semantic distinction between "non-color-data" and "unspecified color data"? If yes, this purpose of this PRD is to propose a name for such a "unspecified color data" CIID -- bypass (although I'm not at all attached to the name); and a light guidelines to ensure that the data vs bypass distinction is consistently honored by all readers and writers, regardless of whether or not a given reader / writer supports OCIO; and to make sure that applications / libraries aren't trying to specify CIID = bypass of their own volition.

I'll update with more detail later this weekend!

[zachlewis]

Alrighty, I've updated the proposal text -- hopefully it clarifies my intent...!

[zachlewis]

Isn't this really an objection to OCIO file rules — shouldn't it be solved there?
File rules are just one heuristic among several (defaults, container metadata, chromaticities, "ask the user"…), and they're OCIO-only. bypass doesn't change file rules; it marks the images that opt out of all auto-resolution at once, in a way that survives a handoff to a tool that has never seen your config — including non-OCIO tools. Fixing file rules wouldn't reach any of that.

Should an image be allowed to "direct" an application?
It carries a decision; it doesn't make one. A user/config/pipeline sets it, and an explicit user override always wins — it never overrides a human. It's the serialized form of exactly the user/pipeline control being asked for: when two facilities don't share a session, the file is the only place that decision can ride.

Why doesn't unknown cover it?
unknown is defined as the value readers MAY resolve (file rules, defaults, hints) — that's the guess a deliberate hold needs to forbid. We can't make unknown "sticky" without breaking every app that writes it freely meaning nothing.

Then how is it different from data? Why not just use data?
Identical reader behavior — both short-circuit to a no-op. The only difference is the content claim: data says "not color," bypass says "color, encoding deliberately withheld." Tagging real color data is a false statement that quietly turns data from "not color" into "don't touch." bypass exists so people don't have to lie to get the behavior — and so data's descriptive meaning stays intact.

Is this common enough to bother?
It's already common — just currently spelled as data/"raw" misuse, so it's invisible in the metadata record. The data no-op is observable behavior, so color media will keep coming to depend on it; the only open question is whether that dependency's spelling lies.

Why not a private myco:bypass ID + an isData space in my own config?
That works exactly where you don't need help — inside the pipeline that loads your config. To any reader that doesn't (every non-OCIO tool, any other facility), it's an unrecognized string that gets unknown treatment. Reserved tokens are the only entries every reader already shares.

What do implementers actually have to do?
Handle bypass exactly as you already handle data — no new mechanism, no new search. The one real rule is on the write side: don't emit it on your own initiative.

Is "sticky vs. non-committal unknown" the right read?
Yes — with one tweak: it isn't really "unknown," it's a deliberate withholding ("this is color; I'm choosing not to assert an encoding; don't guess"). The stickiness follows from that, and "laundered into thinking it's known" is exactly the failure it prevents.

[doug-walker]

Thanks for the work on this Zach, you have pretty much convinced me! However, the proposed instructions for the writer in your modified proposal seem unnecessary. If I understand correctly, bypass should act like a data space on read and a color space on write. As such, bypass could appear in the list of options, along with other color spaces, and if the artist selects it, that's what the application writes. So it seems no special action should be required of writers.

[carolalynn]

Yeah, if folks in the group want this and say it would be useful, I guess I don't have enough reason to be fully opposed. I still don't think the use cases are clear to me, but I am only one person :) so that's not reason enough to object. Appreciate the dialogue on this.

Last question - if you're using this, would you, in your ideal experience, want anything different to happen on an app side for VIEWING these images? To me, that's a big difference between data and this - data "images" will likely never be directly "viewed". These images presumably would. Viewing is outside the scope of this document, but I am personally curious as the the workflow that would be preferred in an app.