Replies: 35 comments 60 replies
-
|
Let me throw out an alternate design for discussion:
In other words, to apps and OIIO internals, there is only "ColorSpace", though what's stored there can take a few forms (always using a CIF token if we can figure out the right one). It's a detail of individual file format readers and writers to handle translating to and from CICF fields in those file that understand it. |
Beta Was this translation helpful? Give feedback.
-
|
@zachlewis said in #4746: Honestly, I'm not wild overloading the ColorSpace attribute like this. But let me propose a counter proposal:
Given the complexity of all the moving pieces, I think it would be incredibly helpful to treat the CICP attribute as a first class citizen, for the sake of diagnostics, if nothing else:
It's not completely impossible to do most of the above with a single overloaded The way I envisioned the CICP attribute working:
Does this seem reasonable? |
Beta Was this translation helpful? Give feedback.
-
|
@JGoldstone said: n.b. these are about what came before the last three posts here Mostly the variables you use for primaries, transfer function, matrix and video full range flag are Should we be allowing the caller to set CICP components to invalid values? In particular, 0 is an ITU-reserved value for color primaries and will probably never be valid; likewise 0 for transfer function. And non-zero values for a matrix enum are just plain wrong unless the essence is either YCbCr or ITcTp. Are there other places in OpenImageIO where a user passes in what is basically an enum value, but as an int instead of a type-checkable enum, and we look at that int's validity if interpreted as that enum? Oh and there's one point in a comment where it's implied that both YCbCr and ITcTp are always "legal range" (or if you want to be more de jure in your terminology, "narrow range"). But this is not true for ITcTp; BT.2100 defines full-range ITcTp for both 10-bit and 12-bit integer encodings. Now I'll go back and read the last three posts here; but not before thanking you both (Larry and Zach) for considering this stuff so carefully. |
Beta Was this translation helpful? Give feedback.
-
|
@JGoldstone said: I like Zach's counter proposal A LOT but have some questions:
Would you see OCIO then enhanced to let you supply potentially all of the above to it, and it would apply any config-specified resolution protocol or a default resolution protocol if none were explicitly provided? I still want somehow to be able to detect when an image has other metadata that conflicts with its CICP value. That feels like something where one should be able to ask a file format's plugin "what are all the ways you can identify your colorspace" and then pass those to OCIO for sanity checking. Though I hope for a period where we see better support from CICP for certain combinations of primaries and transfer function — say someday support for 16-bit LogC4 in PNG — my feeling is that the amount of time it takes for that to go through ITU standardization will be long compared to OpenColorIO release cycles, and anyway in the meantime people can fall back on filename patterns. Personally I find that sort of thing cringe, but I've been too long out of the production trenches to suggest to others how they should work. |
Beta Was this translation helpful? Give feedback.
-
|
@zachlewis said: Fantastic feedback, Joe [sic: Joseph]. Thank you.
Good catch -- will fix!
Very good points. Like you say, the So... my possibly-misguided thinking is... we should probably include a means for converting to / from YCbCr / ICtCp, independently of color space conversions. There are a handful of ways we could approach this with OCIO. In a best-case scenario, this is somehow controlled for by the OCIO API itself -- that's something we'll have to discuss further with the OCIO folks. Another solution -- we could add in-memory to the OCIO Config used by ColorConfig a series of NamedTransforms for the relevant conversions (Rec.709-to-YCbCr, Rec.2020-to-YCbCr, Rec.601-to-YCbCr, XYZ-to-ICtCp...), and invoke their inverses either on In practice, there are four image formats that I know of that support CICP:
Great point -- I'll update the comment to better clarify.
It's your browser. If you highlight the offender and right-click, you should see some sort of "Add to dictionary" option.
Sure. There should have been a slash between "active" and "default". The Python OCIO API offers
The OCIO API currently offers a So, the three uses would be:
Maybe. It's all up for discussion.
Now... it should be possible to match / derive ad-hoc color spaces given
That would be interesting. It would be nice if OIIO could optionally reconcile the other attributes with a given CICP attribute on write.
Well, as far as OCIO release cycles go, OCIO doesn't intend to validate CICP data (beyond any heuristics provided by the config author). So, any new additions to H.273 et al. shouldn't break OCIO ABI compatibility. And there's really nothing stopping us from defining an Re: filename patterns -- they can be extremely useful in a lot of situations -- particularly where the person setting the filename doesn't have control over the metadata or the means to interpret it. Right now, it's also the only way we have to indicate whether to apply an inverse display-view transform or a colorimetric color space transform when "linearizing" output-referred encodings. |
Beta Was this translation helpful? Give feedback.
-
|
@zachlewis said: I just want to refocus the discussion here so we can move things forward... @lgritz -- given that...
...are you any more comfortable with the idea of tracking a separate I feel the benefits of creating the scaffolding for robustly wrangling CICP, among other types of downstream-decoding metadata, outweigh the costs of managing the when, where, and how of OCIO interaction; and I fear that overloading the That said, I definitely understand the allure of using a single attribute to track the internal "image state" of the buffer while it's in motion, and if that's the way you feel we should go for now, I'd be more than happy to oblige. |
Beta Was this translation helpful? Give feedback.
-
|
@lgritz said: I don't mind there being a separate "oiio:CICP" attribute. (Aside: if this is a well established standard, we can just call it "CICP". Usually the "oiio:" prefix is for things that only OIIO is expected to understand, and/or internal signalling/hinting of some sort.) I'm less sure whether it's so foundational that we should have a separate ImageSpec::set_CICP() method just for that, versus calling ImageSpec::attribute like we would for anything else. We wanted as much as possible to just use the generalized token/value metadata store, and only have special fields or single-metadata API functions growing with each new item that comes along.
I meant "only have special... when really necessary" or "NOT have special calls for each new item that comes along". But somehow I combined the two phrasings and managed to completely garble the message. |
Beta Was this translation helpful? Give feedback.
-
|
@zachlewis said: Ha! I understood your meaning. The main reason why I implemented an Another reason why I implemented an Originally, I was thinking, it would make sense to attach (I was also thinking, it wouldn't hurt to have an overloaded Anyway, we can discuss what to do with the other metadata schemes elsewhere -- I just wanted to give you an idea of where my head was at. All this said, as far as this PR is concerned, I'll happily do whatever you'd prefer. If you'd like to get rid of the Should I proceed with getting rid of |
Beta Was this translation helpful? Give feedback.
-
|
@lgritz said: How about this compromise: instead of making set_cicp a method of ImageSpec, let's make it a free-standing function (somewhat like the existing I'm on the fence about whether the string-based API call is necessary, or if it's sufficient to just make that functionality live in oiiotool. Maybe start with that part just in oiiotool, but if we decide later that we really want it directly, it's easy enough to add? But I'm happy to go with your recommendation if you want it in the API now. I don't have a good feel for how often it will come up that people will want to manipulate just one field independently and can't just "get" all 4, modify what they want, and then send the whole package back. Will that idiom of 4 or 5 lines be so commonly repeated in people's code that it's worth having a new API call for us to test and maintain? Just so you know what's currently swirling in my brain for a place to work toward eventually: You have convinced me that separately maintaining "OCIOColorSpace", "CICP", "Chromaticities", and possibly other attributes is the right approach, if for no other reason, then simply for the sake of being able to accurately report what was really in a file that we read. However, I still feel like it would be a mistake to make everyplace in the code base that needs to check or set or propagate color space information, and every piece of USER code that needs to do so, to have to check a growing list of possible attribute names and different standards for what color space the pixels are, understand them all (plus, the list may grow), and also to know which one to set in order to be supported by the output file type they are using (which is antithetical to OIIO's original core purpose of allowing near total format-agnosticism on the app side). So what I'm thinking is that there is still a use for a get_colorspace() method/function, centrally implemented, that surveys the various attributes and synthesizes a single string descriptor for the color space to put in "internal" attribute "oiio:ColorSpace", and a corresponding set_colorspace() that takes such a token and sets any or all of the individual attributes (and clearing any that contradict, can't be known, or have no corresponding version). This centralizes the logic for translating between the different standards and lets most apps, and most parts of OIIO internals, operate as if it was a single simple attribute, even though there are actually several attributes and standards that get elaborated depending on the file type. So, for example, if you read an openexr file that has a "OCIOColorSpace" attribute, that will be set in the ImageSpec and also "oiio:ColorSpace" will be set to, say, "lin_rec709". If it reads a PNG file with CICF info, the "CICF" attribute will be set, but also "oiio:ColorSpace" will end up with an OCIO name if it corresponds to one, but if not, then "cicf:1,2,3,4". Or if all that's known is chromaticities and they don't seem to correspond to any known CIF space, maybe it will just get "chromaticities:....". Is something like that going to make all the color scientists hate me? |
Beta Was this translation helpful? Give feedback.
-
|
@zachlewis said: Roger that -- I will...
Let me know if I've forgotten anything.
No, I wouldn't imagine so -- really, the kind of wrangling we're talking about would only happen under pretty unique and specific circumstances. We can make things simpler for user code by treating the CICP attribute as an
Thank you! This is crucial.
Oh, couldn't agree more - ideally, the vast majority of user code should be able to drive everything that needs driving with only the (Do format writers have easy access to the ColorConfig?)
I'm not sure about the particular method details themselves, but I think this is 100% the right idea, and aligns with the approach I imagine OCIO's API will very likely take! Sidebar: It might be useful to contrive an internal
Mmmm. I don't know... maybe I'm misunderstanding, but with a That said, I don't at all mind the idea of string-based shorthand for setting set non- I want to highlight two things:
|
Beta Was this translation helpful? Give feedback.
-
|
@lgritz said:
I think we're on the same page about pretty much all of this.
Cool. Needless to say, the specifics I outlined were just off the top of my head and speculative, all depends on how the OCIO stuff shakes out, input from others, etc.
There is one default color config, set by
I think there's an overall question we've always had about which metadata being set should invalidate which other metadata, and what to do about things that seem to contradict. The metadata needs metadata!
It won't. If you call set_colorspace("cicp:x,y,z,w"), the logic would be: Conversely, if the thing passed to set_colorspace appears to be an OCIO or CIF name 'foo', the logic would be: or something like that. Oh, and if it gets as far as an IBA that needs to know something about color space and it's anything other than an OCIO token, it just will treat it as an unknown color space. In effect, the "CICF" values that don't correspond to a known OCIO color space are really only being carried around for the sake of the eventual ImageOutput that writes the file.
We do require OCIO as a dependency now, at a minimum of 2.2, so there is always at least that built-in color config available. I'm sure there are lots of places in the OIIO code that haven't yet caught up to the best logic to apply given that as a minimum set of capabilities, and could thus be improved to give more consistency and better sensible default behavior. Elaborating a little more... There are a few possible attributes that could be set:
And there are a few operations of note: set_colorspace
ImageInputs:
ImageBufAlgo functions():
ImageOutput:
So the upshot is that most of the OIIO code base and most apps can just deal with oiio:ColorSpace and treat nothing else as special; ImageInputs just call set_colorspace; ImageOutputs need a little format-specific logic to see if the spec has the right kind of color information (or it can be deduced by what's there); ImageBufAlgo lives in an OCIO world. But all along, things like |
Beta Was this translation helpful? Give feedback.
-
|
@zachlewis said: Ah, I see -- I thought Either way, I still don't understand why we'd want
But why overload In my view:
Does that make sense? It would mean IBAs that alter the output spec's It may be the case that only approximate chromaticities can be derived, or that a "gamma" cannot be ascertained, which is fine. The approximated chromaticities will be good enough for government work, and the "gamma" either won't apply for the color space (cuz it's a log-encoded space, etc.), or, if an output format absolutely requires a "gamma" metadata, we can attempt to derive a value from the output filename, vis-a-vis the OCIO config's FileRules; and failing that, we can require user intervention to override OIIO's existing format-specific defaults. (It would also mean that we'd probably want to start adding an "opt-in" feature to the EXR writer for embedding chromaticity metadata; because, as nice as it may be that we can derive values, CIF et al would like to deprecate the attribute entirely, in favor of |
Beta Was this translation helpful? Give feedback.
-
|
@lgritz said:
At one point, so did I. I'm basically just talking out loud here, trying to grope my way to a set of rules that makes for consistent behavior while minimizing what apps using OIIO need to do. The only reason I have them separate now is to disginguish the OIIO operative color space of the image ("oiio:ColorSpace") from "the explicit OCIO name we found in the file, for those formats that support it."
I believe I was thinking that this just gives us a single item to pass all the way through the chain? But maybe I'm wrong and it's not necessary?
Maybe? But like I said, if as we are implementing this, we see that there are some redundancies or inconsistencies, we should definitely eliminate them.
Oh, I didn't know this would be possible except for a very few special cases. An area of OCIO's APIs I have never really dealt with is building configs or augmenting a loaded config with addition CS's. Do all the CIF quads map to something we could in principle add on the fly to the OCIO config, so we really can just concern ourselves with OCIO tokens?
This is the only part you wrote that I disagree with (or maybe just don't understand exactly what you mean). I wouldn't say "oiio:ColorSpace" is ignored by ImageOutput; I would say it's the single source of truth if present, but it's up to the ImageOutput for each format to know which fields and standards are supported by that format and express it the right way in the file.
I think it's simpler than that. I'm suggesting that "CICP", "gamma", "OCIOColorSpace", etc. only express input file metadata. ImageInputs also set "oiio:ColorSpace". IBA functions that don't do color space transformations just pass all metadata through untouched. IBA functions that change color space erase all of them and just set a single "oiio:ColorSpace" to carry all information forward (e.g. the only thing we know coming out of an IBA color transforming function is what we think the new OCIO color space is). ImageOutput set whatever fields they support based on oiio:ColorSpace if it is present, but otherwise may fall back on a format-specific item like "CICP" if present.
I'm in the camp of people who think "Chromaticies" should be considered deprecated for exr files. I have never considered it trustworthy, and I don't think OIIO even reads it from the file. |
Beta Was this translation helpful? Give feedback.
-
|
@JGoldstone said: Catching up (my you've both been energetic in the last 72 hours or so)
|
Beta Was this translation helpful? Give feedback.
-
|
@lgritz said:
I'm not sure what you mean by "deal with", but so far, a core assumption of OIIO is that these are encoding details that live entirely internal to the ImageInput/ImageOutput implementation of a format. The "app side" of the OIIO APIs does not have the concepts of subsampling nor non-RGB data encodings (just like it doesn't know about compressed data streams, or bit depths that aren't 8/16/32). Ideally and whenever possible, those encoding details aren't even handled in the ImageInput/ImageOutput, but are handled completely in the underlying per-format library if at all possible.
100%, that's always been our policy -- ffmpeg for video, libraw for camera raw, libtiff for YCbCr-encoded tiff files, etc.
I have an admittedly sketchy grasp of this part, even the terminology. We want to honor whatever external OCIO config is found at runtime, and in the absence of one, default to modern OCIO's "built-in" config. If there's a way to dynamically augment that at runtime in order to outsource even more of the color handling code to OCIO rather than do any of it on the OIIO side, that's great. But when you call it an "OpenImageIO custom OCIO config" I start to get confused, because that sounds (to me, and I bet to OIIO's downstream users who aren't super OCIO gurus) like it's something we're doing instead of their studio config or OCIO's built-in config. |
Beta Was this translation helpful? Give feedback.
-
|
@zachlewis In this discussion, do you think you can pull together the current consensus and your best guess at the way to proceed and express it as a simple checklist of specific changes we can start implementing and checking off one by one on the way to a 3.1 release fairly soon? As an example, the first few items might be things like (these are examples, not necessarily correct):
|
Beta Was this translation helpful? Give feedback.
-
|
I'll do my best! |
Beta Was this translation helpful? Give feedback.
-
|
Quick question about autocc / input filepaths... Namely -- OIIO doesn't have an official mechanism for internally storing input image filepaths in an ImageSpec attribute, correct? I think something like an "oiio:InputFilepath" attribute could be useful in other cases, too. Nuke has a similar idiom -- each Read node passes down "input/filename" metadata, which often informs downstream OCIO transform context variables or slate / burnin text values, frame-to-smpte:Timecode translations, etc. The specific reason why I ask is, I think it might be nice to defer "autocc" behavior (i.e., the mechanism by which an OCIO color space is parsed from a filepath) as late as possible, ideally to the same "interpretColorSpaceFromMetadata" function that we'd use just before applying a color-managed (i.e., OCIO-color-space-aware) IBA. One reason for this is, according to the current OpenEXR / CIF proposal, the file path is considered after acesImageContainerFlag and colorInteropId metadata, if they exist in the header. |
Beta Was this translation helpful? Give feedback.
-
|
Two sidebars:
|
Beta Was this translation helpful? Give feedback.
-
|
Several things here!
|
Beta Was this translation helpful? Give feedback.
-
|
Oh, right! Sorry - I keep forgetting what In my head, I keep mistakenly thinking that "--autocc" just "auto-identifies" the input color space by parsing the filename... but I keep forgetting the bit where it also performs a color-space conversion to the scene_linear working space. There's absolutely no reason to make "--autocc" the default behavior -- ostensibly a defensible position, as you say, but there's no real reason for the change. VETO. What I really meant by "make autocc the default behavior" is, "if (As opposed to only ever parsing the input filepath for a color space if autocc'ing). What I'm suggesting shouldn't elicit surprise
Awwright!! 🎸
It should never get invalidated.
Yes. But to be clear, I'm proposing that we store the entire absolute filepath, parent directories and all.
Good question. Hmm. Writing "oiio:InputFilepath" is a slippery slope... How about this:
Or, if it makes stuff less complicated, for the time being, we can just neither read or write "oiio:InputFilepath" format metadata.
Primarily just for color space identification stuff; but it would be really useful to be able to opt-in to persisting input filepath metadata for forensic purposes. I foresee the attribute being useful for detecting and applying sidecar color metadata.
Thanks for your consideration! |
Beta Was this translation helpful? Give feedback.
-
|
I implemented automatic conversion between Setting
This didn't happen in the end, and the corresponding AcademySoftwareFoundation/OpenColorIO#1975 was closed. So I implemented the mapping in OIIO. Support for ICC profile paths in the config was added in OCIO 2.5. A future improvement could be to automatically embed that on write. Not sure if there is a practical way to map from ICC profile to |
Beta Was this translation helpful? Give feedback.
-
|
Some thoughts, concerning "srgb video" / "rec709 video" <--> CICP <--> OCIO I'm curious to hear people's thoughts about this: There's a lot of controversy surrounding what the colloquial phrase "srgb_rec709_display" actually means in practice, both in terms of whether an "sRGB Display" Display Color Space should employ a pure 2.2 power function or a piecewise sRGB (~2.22) function, and whether the corresponding CICP trc byte for written images should reflect the actual transfer function used, or if the CICP value should implicitly impose a disparity between how "sRGB" images are read and written. The issue is a little more clear-cut with "srgb_rec709_scene" -- I think that should always denote the piecewise sRGB (~2.22) transfer function (CICP.trc = 13). So, my question is... should "srgb_rec709_display" denote the same CICP values as "srgb_rec709_scene"? Likewise, should "g22_rec709_display" denote the same CICP values as "g22_rec709_scene"? I think, for the sake of simplicity -- ss far as colorInteropID strings are concerned, "srgb" should always map to CICP.trc = 13, and "g22" should always map to CICP.trc = 4. This has implications for OIIO's default behavior when using the default ColorConfig to bake out a "Gamma 2.2 - Display"-based DisplayView transform -- the CICP value written for the encoded data will reflect the actual transfer function used for viewing, which is not necessarily always the desired behavior; and, thus, OIIO would be forced to "pick a side" here, perhaps somewhat controversially. I think I'm okay with this. It means that users would have to provide a custom OCIO config if they want to specify a disparity between encoding and decoding behavior, or they'd have to manually edit the CICP values retrieved from the color space; but I feel the benefits of "srgb" and "g22" unambiguously mapping to CICP trc values of 13 and 4 respectively somewhat outweigh the costs of OIIO "picking a side" and defaulting to "the wrong behavior" by some accounts. As long as there are clear pathways to doing "the right thing", and we include the necessary documentation, I think the most people will be best served in the long term. To me, it’s a question of defaulting to behavior people probably want versus behavior people will definitely understand. (I'd also argue that this isn't something OIIO itself should be concerned with -- if this isn't the behavior people want by default, it should probably be addressed by the OCIO config working group.) Upshot is, if OIIO isn't defaulting to writing the CICP values you want, you have two choices:
As far as manually adjusting the CICP attribute goes, Separately, "Rec.709 video" has a similar-but-differently fraught relationship with CICP. In as few words as possible, CICP doesn’t have a way to signal “Gamma 2.4”, so getting “g24_rec709_display”-encoded stuff to look as intended is contingent on downstream vendor-specific expectations and settings. Sometimes, you need to use CICP.trc = 1 (“camera” piecewise encoding, represented by the OCIO builtin interop_id “ocio:itu709_rec709_scene”); other times, you need to use CICP.trc = 2 (“unspecified”), and use additional format/codec-specific metadata to indicate a “gamma” (pure power function) value. Sometimes, doing the wrong thing has consequences; sometimes, it doesn’t. However, OIIO has to make a decision about how to interpret CICP pri, trc tagged “1,1,…” and “1,2,…”
What about the other way around?
Another nice-to-have: |
Beta Was this translation helpful? Give feedback.
-
|
If OIIO is going to make an exception, I would expect it to be specifically for interop ID I think that someone choosing that Gamma 2.2 display is unlikely to want their image to be written with Gamma 2.2 CICP (or ICC profile). So I can see how the change to automatically do that could make OIIO default behavior worse for some users. It seems reasonable to remove the automatic mapping from For the "Rec.709 video" issue, in my tests that applies to video files but not image files. For example QuickTime Player will interpret CICP 1,1 on videos as BT.709, while Preview will interpret the same CICP on images as BT.1886. I think CICP 1,1 behavior could be left unchanged, even for the FFmpeg reader as other video software does interpret it as BT.1886. I have no opinion on CICP 1,2 or other metadata. |
Beta Was this translation helpful? Give feedback.
-
Yeah, exactly.
Hmm. Interesting, I hadn't considered removing the g22_rec709_display --> CICP mapping entirely. Would we just avoid writing CICP metadata entirely if possible, and fail over to format-specific defaults? It's also possible that setting CICP 1-2-1 and setting custom gAMA metadata to 2.2 would cause all readers to "do the right thing", whether or not they're capable of interpreting custom gama atoms... Or, since our concern is OIIO's default behavior, maybe instead of possibly surprising people with special handling of "g22_rec709_display", perhaps OIIO could pivot to using its own internal default OCIO config instead of (or, "on top of" / merged with) the vanilla "ocio://default" (or, preferably, "ocio://studio-config-latest")?
Oh boy. That's... very interesting. I wonder how Preview treats CICP 1,2... and whether choice of display "Reference Mode" affects this behavior... and whether this behavior extends to iOS. Lots of testing in my future, I should've probably guessed.
I'm not sure I understand -- are you suggesting we should interpret CICP 1,1 as "ocio:itu709_rec709_scene" (BT.709 "Camera" OETF) or as "g24_rec709_display" (BT.1886)? Sidebar: one potential consequence of deferring the resolution of "oiio:ColorSpace" as late as possible is, it affords us the opportunity to do something different, depending on whether we're trying to resolve CICP values for an ociodisplay IBA or for the colorconvert / ociolook IBAs. Just food for thought. |
Beta Was this translation helpful? Give feedback.
-
My guess would be to not write anything for
To me it's not clear how you would specify this behavior in an OCIO config, without breaking other usage of the
I meant BT.1886. |
Beta Was this translation helpful? Give feedback.
-
For better or worse, the official ACES configs serve as a 1:1 reference mapping of interop_id strings <--> ColorSpace aliases + definitions, such that, when using the config, there is never any disparity between how data is encoded and decoded; the color space used for writing is always exact same as the color space used for reading. However, that 1:1 ColorSpace <--> interop_id relationship is not a requirement; in practice, many ColorSpaces may specify the same interop_id value, even if those ColorSpaces are not definitionally equivalent. The only requirements (as far as validation is concerned) are that each interop_id follow interop-id-legal naming conventions, and that each interop_id value matches a ColorSpace name or alias. I'm proposing that OIIO's default "Gamma 2.2 - Display" color space specifies "srgb_rec709_scene" as its interop_id instead of "g22_rec709_display". This would free OIIO to define its own default behavior for tagging "Gamma 2.2 - Display" encodings as 1-13-1, without redefining the meaning of "g22_rec709_display", independently of what the ACES config working group decides what to do with the interop_id. Users are free to specify that OIIO should use "ocio://default" if they want to explicitly align to whatever the ACES config working group decides; but this is one of the few areas where what makes the most sense for OIIO's default behavior may not align with what makes the most sense for OCIO. (Although, personally, I agree that the ACES configs should probably impose the desired behavior out-of-the-box; I think it would be worthwhile for the configs working group to publish a separate, stripped-down "interop-identities" config, serving as a backward-compatible reference defining 1:1 relationships between interop_id strings and ColorSpace identities) |
Beta Was this translation helpful? Give feedback.
-
|
Besides the topic of deferred setting of Moved to #4980 |
Beta Was this translation helpful? Give feedback.
-
Important to note -- a color space's interop_id value isn't intended to necessarily convey definitional equivalence among color spaces (that's actually closer to what the equalitygroup attribute was intended for). Instead, it serves to inform the quality of written format metadata -- i.e., "when writing to disk, if the output colorspace is Foo, but Foo's interop_id value happens to match an alias of other color space Bar, written metadata should indicate that the data is Bar-encoded, not Foo-encoded. Likewise, when downstream readers read the image, they will interpret the data as Bar, not Foo. The interop_id attribute therefore doesn't really intend to convey equivalency as much as it conveys metadata-specific behavioral intent to downstream handlers. It's a subtle distinction, but it permits config authors to essentially convey lies through the pipeline in order to elicit certain behavior of image readers. Of course, the interop_id can be used for telling the truth as well; but if it were used for always telling the truth all of the time, the attribute would hardly need to exist in the first place (for well-known color space definitions), since an interop_id could be automatically inferred by testing for equivalency a against a set of builtin color spaces. So, the CIF + OCIO current thinking is, if the interop_id value is structurally valid and exists, use it; otherwise, attempt to find an equivalent color space in a reference config (e.g., the ocio://studio-config-latest that ships with OCIO-2.5) and use that config's color space's interop_id. And if a needed missing interop_id still can't be inferred from an equivalent color space in a builtin config, there are a series of TBD heuristics for finding or generating a value that elicits valid and reliable interpretation behavior in downstream readers, potentially invoking mechanisms for searching for certain color spaces in certain configs... anyway, I think it would be best for OCIO itself to provide helpers for handling the more complex aspects of generating / interpreting namespaced interop_id for custom color spaces, to ensure reliable behavior among all software reading and writing the colorInteropID attribute. But for the immediate future, OIIO should be able to gracefully handle reading / writing / identifying / interpreting interop_ids that refer to either the standard unnamespaced CIF identities, or the "ocio:"-prefixed interop_ids conveyed by the color spaces in the OCIO-2.5+ studio-config-latest builtin config. In practice, for the next couple of years, until OIIO raises the minimum supported OCIO version to 2.5, we'll have to do a little legwork for the sake of backward compatibility. Specifically, I'd propose that OIIO ship with its own internal OCIO-2.3-compatible "interop-identities" config defining the same color spaces as those that ship with the 2.5 studio config. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the explanation. I added pull requests for JPEG XL CICP and writing OpenEXR interop IDs, and more detailed bullet points about handling interop IDs to the list. |
Beta Was this translation helpful? Give feedback.
-
|
I added two more PRs for compatibility with older OCIO configs, and handling display color space interop IDs throughout the I/O code. That's probably all the changes I'm personally most interested in having. |
Beta Was this translation helpful? Give feedback.
-
|
I was keeping this list of tasks up to date for myself, but now moved it to #4980 since it gets lost in the middle of this long discussion. |
Beta Was this translation helpful? Give feedback.
-
|
You rock, Brecht! Thank you.
…On Fri, Nov 28, 2025 at 8:21 AM Brecht Van Lommel ***@***.***> wrote:
Thanks for the explanation. I added pull requests for JPEG XL CICP and
writing OpenEXR interop IDs, and more detailed bullet points about handling
interop IDs to the list.
—
Reply to this email directly, view it on GitHub
<#4787 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AARAC4AON7OSGV2OXLZBWWT37BD45AVCNFSM6AAAAAB6N5X2QKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMJQGU3TOMI>
.
You are receiving this because you were mentioned.Message ID:
<AcademySoftwareFoundation/OpenImageIO/repo-discussions/4787/comments/15105771
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
Is the identifier in designed to signify rendering intent or signal essence? That would probably determine which is used wouldn’t it?
CICP is designed as an EXPLICIT identifier of essence and not rendering intent (although a few code points get a little bit away from this design concept).
Get Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: Brecht Van Lommel ***@***.***>
Sent: Saturday, November 29, 2025 9:12:42 AM
To: AcademySoftwareFoundation/OpenImageIO ***@***.***>
Cc: Seeger, Chris (NBCUniversal) ***@***.***>; Mention ***@***.***>
Subject: [EXTERNAL] Re: [AcademySoftwareFoundation/OpenImageIO] Workspace for deciding how we represent color space information (Discussion #4787)
Hmm. Interesting, I hadn't considered removing the g22_rec709_display --> CICP mapping entirely. Would we just avoid writing CICP metadata entirely if possible, and fail over to format-specific defaults? It's also possible that setting CICP 1-2-1 and setting custom gAMA metadata to 2.2 would cause all readers to "do the right thing", whether or not they're capable of interpreting custom gama atoms...
My guess would be to not write anything for g22_rec709_display, no gAMA and no CICP. To be conservative and keep behavior the same as before, not because I'm confident it's the best option.
Or, since our concern is OIIO's default behavior, maybe instead of possibly surprising people with special handling of "g22_rec709_display", perhaps OIIO could pivot to using its own internal default OCIO config instead of (or, "on top of" / merged with) the vanilla "ocio://default" (or, preferably, "ocio://studio-config-latest")?
To me it's not clear how you would specify this behavior in an OCIO config, without breaking other usage of the g22_rec709_display alias and interop ID. If there was a good way of doing it, then arguably the official ACES configs should be changed. But if there isn't, then I would put the responsibility fully on the application.
I'm not sure I understand -- are you suggesting we should interpret CICP 1,1 as "ocio:itu709_rec709_scene" (BT.709 "Camera" OETF) or as "g24_rec709_display" (BT.1886)?
I meant BT.1886.
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/AcademySoftwareFoundation/OpenImageIO/discussions/4787*discussioncomment-15111875__;Iw!!PIZeeW5wscynRQ!qkNhmK05VEWr4qkgB2h-Kv5Vf2FUVp4blUUd3lvZXmyex4CXWo7DMFFc8sfbtJikBZ8JjVQy_mrKb-YaduBBLePy5g$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AANIO6DIVEO2HG2EM3UMX2L37GSVVAVCNFSM6AAAAAB6N5X2QKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMJRGE4DONI__;!!PIZeeW5wscynRQ!qkNhmK05VEWr4qkgB2h-Kv5Vf2FUVp4blUUd3lvZXmyex4CXWo7DMFFc8sfbtJikBZ8JjVQy_mrKb-YaduCPRk2HiQ$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
That's a good question, and this is an area I struggle with -- it's entirely possible that I'm misunderstanding something fundamental here, so I very much appreciate any guidance you can provide. I believe the interop_id is intended to describe the essence, not the rendering intent, per se -- arguably more so for interop_ids ending in "_scene" than for "_display"... I think. Maybe @doug-walker can provide better insight? Is explicitly setting "1-13-1" to describe "g22_rec709_display"-encoded data the exact opposite of what we'd want to do? I think I'm confusing myself. In a perfect world, "g22_rec709_display" could be tagged as 1-4-1, which would accurately describe both the essence and the rendering intent; but I do know that some video players and browsers seemingly fail to distinguish between 1-13-1 and 1-4-1. Maybe the best thing to do is to set interop_id for the Gamma 2.2 - Display color space to "unknown", and decline to write CICP metadata at all, like Brecht suggests? |
Beta Was this translation helpful? Give feedback.
-
|
There's an OIIO TSC meeting tomorrow (Dec 1, 2pm PST) and we don't have a solid agenda. If any of you can make it, we can use the time to talk about these color space convention issues. |
Beta Was this translation helpful? Give feedback.
-
|
Hmmm… there’s a 75% chance I won’t be able to make it tomorrow (Dec 1), but if I can, I’ll be there! |
Beta Was this translation helpful? Give feedback.
-
Disambiguating scene- vs display- encodings conveyed by CICP
tl;dr -- let's only write CICP for display-referred data, and assume others are doing the same. One issue we've run into is the question of how to interpret CICP metadata in cases where multiple interop_id color space identities share the same CICP representation -- for example, I'd like to present the following somewhat contrived proposals for disambiguating scene and display color encodings: Strategy 1: Don't use CICP for scene-referred dataWhat if... we only write CICP values for display-referred spaces, and use other format-specific idioms for describing scene-referred encodings? And likewise, when reading the presence of CICP metadata would imply a preference for interpreting as display-referred; otherwise, custom chromaticities / "gamma" metadata would inform a scene-referred interpretation. The absence of "gamma" metadata would imply a piecewise sRGB (~2.22) transfer function, and the absence of custom chromaticities metadata would imply Rec.709 primaries.... In other words, we always use CICP (when we can) for reading and writing display-referred encodings; and other metadata when reading and writing scene-referred encodings. I believe this would certainly work for PNGs, and I think we could do something similar with JXL. Not sure what's possible where HEIF / AVIF are concerned, but I wouldn't be heartbroken if we treated the AV1 containers like video. Although I'd prefer to use format-specific metadata where possible, it's important to note that all formats [supported by OIIO] that support CICP -- HEIF / AVIF, PNG, and JXL -- also support embedded ICC profiles. Hence, the following alternate proposal: Strategy 2: Embed a redundant ICC profile to signify that CICP metadata should be interpreted as scene-referredWe always write CICP data, but also embed ICC profiles only for scene-referred encodings; and, likewise, we use the presence of both CICP and ICC metadata to indicate (to ourselves) that we should prefer to interpret CICP values as scene-referred. If I'm not mistaken, formats tend to specify that the presence of CICP data supersedes other (potentially contradictory) metadata, so when we write both CICP and ICC metadata, external decoders should just ignore the ICC bit; and because it's not very likely that external encoders would have cause to intentionally write both CICP and ICC data, when OIIO does encounter both, it wouldn't be unreasonable to assume the file was written by OIIO to begin with... General read heuristicIf we were to support both approaches, the decoding / interpretation heuristic would be:
Strategy-1-style handling of specific interop_id --> color-metadata cases
(Or, alternatively, the "scene" variants may use the same CICP values as display, as long as they include an ICC profile -- the presence of which, OIIO is essentially treating as an "is_scene_referred" flag). Notes and caveatsNotable implications of this:
This isn't a rock-solid solution that's guaranteed to work in all cases:
Troubleshooting misbehaving color metadataGiven that we can't control or necessarily predict how the metadata we write behaves outside of OIIO, the next best thing we can do is help users troubleshoot. It's highly likely that folks will want to use oiiotool to perform surgery on misbehaving image files, or to use OIIO to wedge out permutations of an image encoding + metadata in order to ascertain the behavior of external applications / operating systems under various conditions. I propose we provide global attribute settings for altering OIIO's default color metadata reading / writing behavior. For example, maybe stuff like:
(I also think we should provide a means for overriding the global settings on a per-spec basis, via "oiio:read_as_texture", "oiio:cicp_write_never", etc.) Additionally, I'd recommend that OIIO defaults to "lazily" deferring the metadata -->
Likewise, it would be useful if we had a way to manually override the written CICP value that OIIO would otherwise set. E.g.,:
|
Beta Was this translation helpful? Give feedback.
-
|
Okay.... I've given this considerably more thought. Here's my new proposal:
But an easier heuristic to follow and communicate would be:
The more I think about it, the more I agree with Doug. Until recently, CICP has only been associated with video essence; and texture workflows have evolved to leverage other means of communicating color space encodings. While it seems convenient to leverage CICP for communicating scene-referred encodings as well, we'd be doing so at the cost of worsening and proliferating the exact image state ambiguity problem we're trying to resolve in the first place. At minimum, I strongly feel that OpenImageIO should not contribute to proliferating CICP for texture encodings by default. I think the most neighborly thing OpenImageIO can do here is reinforce and encourage this display-referred-only usage of CICP by preferring to automatically embed ICC or format-specific metadata instead of CICP metadata when dumping scene-referred encodings to otherwise-CICP-capable formats.
Not an unreasonable approach... but I think this might risk fighting against the intent of users who are deliberately relying on file naming or format metadata to dictate default behavior across all application contexts (w.r.t. behavior in like contexts across similar applications consuming the same OCIO config). It may turn out that everything, for the most part, kind of works the way it should without intervention. Maybe it would make sense to provide a setting for toggling a mode for overriding / ignoring the color-space-detection heuristics...? Would it be useful if OIIO provided a method that attempts to find the name of a given color space's "evil twin" on the other side of the scene-display bridge?
As far as file reads are concerned? These configs? Probably not, unless the distinction is otherwise meaningful to Blender (Doug, correct me if I'm missing something obvious)
>>> import PyOpenColorIO as ocio
>>> config = ocio.Config.CreateFromFile("ocio://studio-config-latest")
>>> default_color_space = config.getColorSpaceFromFilepath("foo.jpg")[0]
>>> print(default_color_space)
sRGB - Display
>>> default_display = config.getDefaultDisplay()
>>> print(default_display)
sRGB - Display
>>> print(config.getDefaultView(display=default_display, colorSpacename=default_color_space))
Video (colorimetric)
>>> print(list(config.getViews(display=default_display, colorSpaceName=default_color_space)))
['Video (colorimetric)', 'Raw']
>>> print(config.getDefaultView(display=default_display, colorSpacename="scene_linear"))
ACES 2.0 - SDR 100 nits (Rec.709)
>>> print(list(config.getViews(display=default_display, colorSpaceName="scene_linear")))
['ACES 2.0 - SDR 100 nits (Rec.709)', 'Un-tone-mapped', 'Raw']The In any case, the
It's not too bad! And the OpenColorIO team would be happy to help! That said, it's absolutely okay to keep things simple, and let users explicitly handle the view transform stuff by hand. Lots of applications do exactly that. Most, even. You'd be in good company! |
Beta Was this translation helpful? Give feedback.
-
|
(Also, if you're curious about the specific reasons why "srgb_rec709_display" and "srgb_rec709_scene" behave the way they do for oiiotool's |
Beta Was this translation helpful? Give feedback.
-
|
My interest is in making things work well for individual users, that do not have tightly controlled software, OCIO configs, and file naming conventions like a studio. For those cases it would be nice if e.g. textures with P3 gamut worked well purely based on standard color metadata in the file. The problem with ICC profiles is that I don't have a way of converting them to a color interop ID on read, unlike CICP. But if it can be done then it would be very helpful even ignoring the scene vs. display referred problem.
I can see that being useful.
I was aware of the meaning of If such a config would be considered broken that simplifies things. For example, automatically converting textures to scene linear in the texture system or for making tx files would work correctly even if the color space was incorrectly guessed to be display referred. The case where it would matter in OpenImageIO then is when using the |
Beta Was this translation helpful? Give feedback.
-
Ah, I think I better understand what you're asking. Put it this way --
It's a safe assumption. Scene- and display-referred variants of otherwise equivalent CIF identities might behave differently outside of the normalized [0, 1] domain, but it shouldn't make a difference for decoding and automatically color-space-converting an image file.
This is what I was alluding to above about "fascinating, subtle, and complex" behavior... upshot is, config authors can trigger different default View behaviors, depending on the input color space. In the python snippets above, I demonstrate this behavior with the latest (OCIO-2.5) studio config (although, note, this behavior isn't defined in the versions of the builtin configs that ship with earlier versions of OCIO):
Likewise, different input color spaces correspond to entirely different sets of Views, depending on the This has interesting implications for "autocc"-like behavior:
(In the builtin ACES configs, the "_scene" and "_display" variants of otherwise equivalent color spaces elicit identical View behavior; but it's possible in other configs that textures might employ a different default View than display color spaces). |
Beta Was this translation helpful? Give feedback.
-
(This should be somewhat possible; although I don't think OCIO supports CICP-style ICCv4 profiles yet...!) |
Beta Was this translation helpful? Give feedback.
-
|
Without CICP, isn’t ICC more subjective and has lower possible precision? CICP refers to the explicit math so the highest possible precision can be obtained (from my understanding).
Best,
Chris
Chris Seeger
Director, Advanced Content Production
Office of the CTO
…________________________________
From: Zach Lewis ***@***.***>
Sent: Friday, December 5, 2025 5:04:02 PM
To: AcademySoftwareFoundation/OpenImageIO ***@***.***>
Cc: Seeger, Chris (NBCUniversal) ***@***.***>; Mention ***@***.***>
Subject: [EXTERNAL] Re: [AcademySoftwareFoundation/OpenImageIO] Workspace for deciding how we represent color space information (Discussion #4787)
The problem with ICC profiles is that I don't have a way of converting them to a color interop ID on read, unlike CICP. But if it can be done then it would be very helpful even ignoring the scene vs. display referred problem.
(This should be somewhat possible; although I don't think OCIO supports CICP-style ICCv4 profiles yet...!)
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/AcademySoftwareFoundation/OpenImageIO/discussions/4787*discussioncomment-15177007__;Iw!!PIZeeW5wscynRQ!odf-9M0fChXGoTO9wy53aUoS9pTSOllcSRw3zWzgvH1WfhromxnvbiBLNjxXvWnNPpw5dmPQx5xdiSbrDaVe-0AgMg$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AANIO6AYFK5U6GBCIRRVXQL4AH6NFAVCNFSM6AAAAAB6N5X2QKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMJXG4YDANY__;!!PIZeeW5wscynRQ!odf-9M0fChXGoTO9wy53aUoS9pTSOllcSRw3zWzgvH1WfhromxnvbiBLNjxXvWnNPpw5dmPQx5xdiSbrDaWWSjMA2Q$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Indeed. But, for identification purposes, we don't necessarily have to use the contents of the ICC profile for the actual transform; we just need to test for approximate equivalency to one of the known, supported color space identities, and use our internal definitions instead. |
Beta Was this translation helpful? Give feedback.
-
|
(As for the ICC profiles we embed, we can endeavor to use parametric representations where possible) |
Beta Was this translation helpful? Give feedback.
-
|
The OpenColorIO TSC raised a very, very good point... ICC is typically used for display-referred workflows as well, and connects through a display-referred reference space (D50). In OCIO, we'd tend to interpret ICC profiles as ad-hoc virtual displays / display color spaces, so, logically, it makes little sense to use ICC to convey scene-referred encodings. We should discourage such use. The OCIO TSC also agreed that we should treat CICP as display-referred metadata, and never write CICP metadata for scene-referred encodings. So, now I'm down to thinking, for the scene-referred cases, we should use format-specific chromaticities + "gamma" / "srgb" metadata for the formats that support it. I understand this isn't the most reliable solution for downstream consumers, but it's consistent with current practices. The TSC also agreed that these decisions really ought to be deliberated on and forged in blood by the Color Interop Forum... |
Beta Was this translation helpful? Give feedback.
-
|
It would be unfortunate to sacrifice interoperability with applications outside the VFX software ecosystem. As far as I know, current practices for scene referred images are mostly file rules and manual configuration, but that is what Color Interop Forum standards are supposed to improve. I agree that if CICP is interpreted as display-referred, then the same argument can be made for ICC profiles. But looking into format specific chromaticies for PNG/TIFF/JXL and associated documentation, it sounds pretty display referred as well. And in JPEG XL It seems these file formats just do not have any standard way to indicate that an image is scene referred. Logic to make that distinction would be specific to OpenImagIO or applications trying to be compatible with Color Interop Form standards. At that point it may be better for OpenImageIO to write |
Beta Was this translation helpful? Give feedback.
-
Meeting NotesLet's use this discussion-island for pasting / reporting / discussing notes from relevant discussions that take place outside of GitHub. 2025-12-08 - OpenColorIO TSCCopy-pasted from https://lf-aswf.atlassian.net/wiki/x/AwBnLw Interop IDs:
OpenImageIO recent color space PRs:
|
Beta Was this translation helpful? Give feedback.
-
|
Some scene-referred transfer functions are defined as being paired with an EOTF.
Examples:
1.
BT.709
2.
BT.2100
3.
sRGB
Maybe there can be some distinction for any of those scene-referred systems that are meant to be used with a pairing?
|
Beta Was this translation helpful? Give feedback.
-
|
@digitaltvguy , I think you'd agree that the BT.709, BT.2100, and sRGB specs are almost always used as display-referred encodings in the world at large. VFX has sort of hijacked them for use in defining textures to be used in CG rendering, where they are interpreted as scene-referred because they are inserted directly into the rendering process, prior to tone-mapping. I believe in some of your broadcast workflows you sometimes use a scene-referred interpretation, but that is a bit different because you are using the inverse OETF whereas VFX is using the EOTF (which, as you know, are sometimes different). Unfortunately H.273 CICP is very ambiguous. It provides OETF equations, even though those are the wrong equations to use most of the time. The text alludes to the fact that the EOTF may be more appropriate, but the lack of clarity has resulted in poor interop between applications. Some writers even intentionally set the wrong values in order to get acceptable results for an intended reader. The CICP is arguably missing a fifth value to indicate image state, though I suspect it would never be added because most of the world would always set it as display-referred. I'm not aware of other existing metadata in the file that could be combined with CICP to get this other info. ICC does not provide this either. As Brecht wrote, this is part of why we developed the CIF color spaces. I'm sympathetic to Brecht's suggestion to write CICP by default to get at least some level of interop in various readers, regardless of the image state within OIIO. CICP is not going to give perfect interop, but it is probably better than nothing? On the OIIO side, when reading files I feel like there should be some way for the user to specify which image state should be assumed, with display-referred being the default when CICP is used. Similar to what Brecht wrote, this could either be from file rules or manual configuration (perhaps an OIIO preference setting). The problem then becomes to what extent to rely on header metadata vs. external configuration when reading files. This is what was flagged at the OCIO TSC meeting as something the CIF should work on developing guidance around. |
Beta Was this translation helpful? Give feedback.
-
An OIIO preference seems reasonable to me, we should not hesitate to add global attributes to resolve these ambiguities, as long as we can agree on a reasonable default. |
Beta Was this translation helpful? Give feedback.
-
|
I updated #4972 to default to display color spaces on file read, and did some refactoring towards making this behavior controllable. For a multi-threaded DCC, a global attribute is not ideal since different parts of the application may have different preferences for display or scene referred. Putting it in If setting |
Beta Was this translation helpful? Give feedback.
-
|
@doug-walker , Here’s a document that adds more detail to CICP (adding more detail for broadcast workflows):
https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=14652
I agree that H.273 should mention the pairing more clearly in a single document. I think it is a little out-of-date (Section 8.2, Note 1 doesn’t mention BT.2100 directly). The introduction in Section 8.2 states that CICP Table represents either the OETF or the Inverse EOTF. The specific pairing for BT.709; BT.2020 are explained in “Note 1” above "Table 3”.
Well known standards (BT.1886, BT.2020, BT.2100) establish the EOTF that is used for the pairing of an OETF or Inverse EOTF identified by the CICP code.
….whether the sources are scene-referred or display referred depends on the image format. For instance, BT.709, sRGB, HLG are called “scene-referred”(although often a subjectively interpreted source format), PQ is display-referred. Both are described by CICP because they are the source signal’s essence which often has a well-known EOTF pairing. sRGB is an exception that is often used for viewing during content creation when BT.709/BT.1886 is supposed to be the final display format (and should be used for display during the contents creation).
The bottom line is that with some lack of clear information, a reader has to identify the reference EOTF standards documents to understand how to use the CICP codes for a final (correct) rendering into display light.
Where CICP is so important is that there is explicit mathematics to represent the signal format(OETF or Inverse EOTF). Because the EOTF pairings are well understood for broadcast formats, there are explicit mathematics to present the EOTF (to produce display light).
Perhaps we can draft explicit definitions for OETF(or Inverse EOTF)/EOTF mappings for each CICP Transfer functions index value. Most of the pairings are well understood. We could bring that to ITU and improve the understanding of H.273(CICP).
|
Beta Was this translation helpful? Give feedback.
-
Ah! I didn't realize this. So that's why you kept suggesting we write colorInteropID data to formats other than OpenEXR...! That's cool, I can definitely see use cases for this. I think OpenImageIO should only write canonical |
Beta Was this translation helpful? Give feedback.
-
|
This odd discrepancy is addressed by #4983 |
Beta Was this translation helpful? Give feedback.
-
I'm not so sure this is true. Very few formats allow true arbitrary name/value metadata. We know OpenEXR allows it. I would not have remembered, but Brecht points out that we can write it to PNG if the value happens to be a string. (But will readers retrieve it?) It's really not clear that any other formats give us the ability to directly write colorInteropID without resorting to trickery like embedding it in a string that's supposed to be the caption or image description. For example, where in a JPEG or TIFF would it go, exactly? |
Beta Was this translation helpful? Give feedback.
-
|
I didn't realize arbitrary name/value metadata is so limited. OIIO is already putting custom attributes like An alternative would be storing it in an ICC private tag, which seems to work in a quick test but would then ideally register an ICC tag signature to make it more standard. Or OIIO could support storing arbitrary metadata in XMP perhaps. |
Beta Was this translation helpful? Give feedback.
-
|
"oiio:AverageColor" (and a few more) are a very special case of communication from OIIO's maketx (or the IBA equivalent) and OIIO's TextureSystem. Nothing else is expected to read it or know what to do with it. It's entirely specific to texture files consumed by OIIO's texture system (and cramming it in ImageDescription is a concession to TIFF's inability to have arbitrary metadata). |
Beta Was this translation helpful? Give feedback.
-
|
I'm still confused as you would not want to tag files explicitly when their transfer function exists in H.273? For those formats that are supported by CICP, it would be extremely useful and less interpretive. It might be helpful to build a table with each CICP index value and its defined scene or display referred format because it's unclear to me whether this is completely clear to everyone. |
Beta Was this translation helpful? Give feedback.
-
I promise you, it isn't...! I apologize for the confusion... you're asking exactly the right questions, though. I'm going to find a way to more clearly and succinctly articulate what I'm trying to articulate... I appreciate your patience, in the meantime! |
Beta Was this translation helpful? Give feedback.
-
|
There seems to sill be a lingering question of "when should we write CICP data to files that support it" -- always, only for display-referred spaces, etc. There seems to be some consideration for what does OIIO reader do versus what do other apps do and how to put in the file what they will be most likely to understand and do the right thing. Remember that on the OIIO side, we want to end up with a robust, centrally defined heuristic that has a priority list of what we listen to, and can adjudicate between somewhat contradictory signals. (For example: colorInteropID, in a format that officially supports it like OpenEXR, always wins.) So I think it's ok to cater to non-OIIO apps by adding things they might understand, confident that OIIO will only rely on that if no colorInteropID is also present. |
Beta Was this translation helpful? Give feedback.
-
I hate to be kind of hand-wavy about it, but if we always follow this one rule, OpenImageIO will never generate invalid CICP metadata, and will rarely write CICP metadata that is never used; and, more generally, it'll help to frame decisions regarding when to write or not write metadata in terms of scene-referred vs display-referred workflows as they relate to application capabilities and workflow idioms. Additionally: Maybe? More generally: |
Beta Was this translation helpful? Give feedback.
-
I scribbled the following pseudocode to myself the other week (for resolving metadata to interop_id` values)... |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
This discussion thread will be for discussing and working out color space metadata conventions: OCIO color space names, CICP, chromaticities, and other info. Our goal is to work out a spec describing what metadata names and conventions ImageInputs use, how ImageBufAlgo functions that do color space things should understand and modify the metadata, and how ImageOutputs should act on what is found when it's time to write output.
Unfortunately, a lively discussion on this was in the comments of PR #4746. I will try to cut & paste the important parts of that content below, and then (after I give the all-clear) we can pick up the discussion here and hash through the rest of the details.
Beta Was this translation helpful? Give feedback.
All reactions