Add explanatory comments to baked LUTs. #557
Comments
|
I completely agree... Other things that would be super helpful to have as commented metadata:
|
|
I'd like to see it extend to being able to supply some information from the command line tools also, for instance to support the non-standard RV option for CSP files of the 'conditioningGamma': Yes with V2 this may not be needed. Kevin |
|
Is there motivation to try and make the comment structured so that it could be decomposed automatically or is this intended for human consumption only?
Sent using my interocitor
On Aug 23, 2018, at 01:34, Kevin Wheatley <[email protected]<mailto:[email protected]>> wrote:
I'd like to see it extend to being able to supply some information from the command line tools also, for instance to support the non-standard RV option for CSP files of the 'conditioningGamma':
https://support.shotgunsoftware.com/hc/ja/community/posts/209496628-Cinespace-csp-LUT-with-1D-Shaper-LUT-crushes-shadows<https://support.shotgunsoftware.com/hc/ja/community/posts/209496628-Cinespace-csp-LUT-with-1D-Shaper-LUT-crushes-shadows>
Yes with V2 this may not be needed.
Kevin
|
|
great idea -- definitely worth defining a schema to pair with any serialized metadata... in fact, a schema could make it easier to inject / declare custom fields, or federate transform 'essence' among different implementations (i.e., a means of 'knowing' that this .3dl and that .csp are representations of the exact same thing). Even a totally random hash could provide enough opportunity for external mechanisms to control for and debug 'state changes' in exactly the way Nuke doesn't, when a referenced file transform is overwritten or modified in-place. To the end that OCIO is able to reach across configs via scene and display handoff roles, configs could also be implicitly related via their respective use of the same transform or transforms... or, conversely, the... 'constellations' of how a given transform is implemented across and within configs, in relation to how other identifiable transforms are used could serve to provide intelligent warnings in ociocheck for probable 'improper' use, and offer more likely alternatives, like an OCIO-specific Clippy ("it looks like you're trying to use an LMT to override the RRT for this View / Display -- would you like to derive and apply approximate transforms for Views that share the same name on other Displays?") ...it would be possible to generate an ad-hoc, LMT database, simply based on what gets sandwiched between the usual suspects... ...configs could almost infer themselves into existence, based on the presence of a handful of luts in a directory, and data relating lut-config-constellations... and on and on and on... all without actually processing the data being described... in fact, maybe we can drop color processing entirely in OCIO 3 👍 If only there existed some kind of... Common LUT Format schema we could co-opt... |
|
Human consumption only, then.
I’d mentioned at the BoF the idea of treating modern ARRIRAW files or MXF-wrapped ARRIRAW or QT-wrapped ProRes as LUTs with a FileTransform node, since the modern versions carry with them any 3D LUTs used for in-camera monitoring. Those LUTs can either be transcoding of externally-designed LUTs (say a colorist associated with a production designs a show LUT in Baselight or Resolve), or they can be parametrically synthesized in the ARRI Color Tool. It’s those parameters I was envisioning making visible as comments in 3D LUT headers. They do have a structured internal string representation but I’ll just let that slide for now, based on your email below.
|
|
...? I was trying to suggest, we could support multiple types of metadata, so long as we had schemas defined explicitly for validation and automatic decomposition... I was thinking more in terms of applications for automating business logic in the context of production pipelines... but, primarily, I meant that different types of metadata could simultaneously serve different domains without clobbering each other, provided that the data is, indeed, structured... I wasn't at the BoF, so I guess there's some context I'm missing.... but I do know that being able to toggle, extract and convert AML directly from metadata is one of few pleasures I get from having to do anything at all with metadata, and I'd be eager to hear more... |
|
OK, I will have to take a hard look at your email of the 23rd again. Your ambitions for metadata are so far, far, far, far beyond what I normally hear (“all I want is to extract the clip number. Is that so hard?”) that I thought you were making fun of my suggestion.
That you were serious is amazing. I am hip-deep in revising some internal ARRI metadata tools, and had been arguing for something considerably more ambition than “clip number, please”, some grand unified theory of ARRI metadata…but your email makes me think I’m not thinking big enough.
I don’t suppose you’re in the LA area...
On Aug 24, 2018, at 4:47 PM, zachlewis <[email protected]<mailto:[email protected]>> wrote:
...?
I was trying to suggest, we could support multiple types of metadata, so long as we had schemas defined explicitly for validation and automatic decomposition... I was thinking more in terms of applications for automating business logic in the context of production pipelines... but, primarily, I meant that different types of metadata could simultaneously serve different domains without clobbering each other, provided that the data is, indeed, structured...
I wasn't at the BoF, so I guess there's some context I'm missing.... but I do know that being able to toggle, extract and convert AML directly from metadata is one of few pleasures I get from having to do anything at all with metadata, and I'd be eager to hear more...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#557 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABFQ_WLrMubHdW8mzHql1unGybR1IhIHks5uUJCggaJpZM4WHS9E>.
This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please send us by fax any message containing deadlines as incoming e-mails are not screened for response deadlines. The integrity and security of this message cannot be guaranteed on the Internet.
This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please send us by fax any message containing deadlines as incoming e-mails are not screened for response deadlines. The integrity and security of this message cannot be guaranteed on the Internet.
---------------------------------------------------------------------------------------
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------
|
|
Yeesh -- I'm sorry dude! Sometimes my sense of humor / writing style / unstructured thoughts don't come across as intended... plus, looking at what I wrote now, yeah, that's a lot of enthusiasm and words, considering the topic... yikes... anyway, totally not my intention to come across as dismissive of anyone's ideas but my own. As for seriousness... I mean, nobody wants Clippy, obviously, but all sorts of things become possible when data is able to meaningfully describe itself... I'm in NY, but I'll reach out to you privately. In any case, have you solicited 3dpro for thoughts on metadata? When it comes to metadata, the only thing I feel strongly about is that it if it exists, it should be correct. coughredlinecoughchromaticitiescough What I like about Nick's idea is, it's an inherently elegant solution to a number of problems in a single line of text, parseable to humans and machines. And what I like about Kevin and Joseph's ideas is that they have the potential to imbue luts with capabilities far beyond their apparent use, without disrupting non-OCIO consumers of the same file. And what I like about both of those ideas is that they're both pretty different from what I'd wish for, which is infinity more wishes. My first wish after that would be for a hash of the maximally reduced set of ordered transforms / md5s seeded from the namespace "com.opencolorio" (or .biz or whatever). Anyway, it occurred to me that SMPTE must've worked the whole thing out by now, for UHD-B / Dynamic Metadata for Color Volume Transforms... sure enough... https://www.doi.org/doi_presentations/seminar_20Jun06/Wilkinson-SMPTE.pdf A nested key-length-value data structure presented as YAML or JSON, and some kind of external reference schema / enumerated mapping for various "classes" of metadata seems like it could work. On the other hand, CLF also supports extensions; and that might be an inherently more convenient mechanism for "passively" extending lut capabilities, by means of wrapping the data with commented CLF nodes, or something... |
scoopxyz
added
Feature Request
|
I would appreciate all wise folks here to evaluate this entry point for a metadata system within OCIO to potentially address this issue, as well as address the complexities of software seeking to use OCIO as a CMS. Comments are open on the document, so please add them directly. https://docs.google.com/document/d/1RB_obY_G6ScCITWk_na1cd1NPrGVaWO3sX1a6kTiPaU/edit?usp=sharing |
LUTs don’t usually contain any information (other than possibly in the name) about the transform they apply, and the input and output colour encoding. If
ociobakelutadded a comment line to the LUT giving the parameters used to create it, it could be very helpful to subsequent users of that LUT.The text was updated successfully, but these errors were encountered: