The fourth meeting of the CLF Spec / Code Review Virtual Working Group will take place on
Thursday, May 2nd, 2019 9am - 10:30am PDT (Los Angeles time / UTC-07:00)
The meeting will be lead by working group Chairman JD Vandenberg and will be focused on finalizing this group’s deliverables. Those deliverables include a list of the changes being requested to update the specification in order to advance it toward its goal of serving as a universal LUT format for communicating and archiving transforms in LUTs. An agenda and any supporting documents will be shared here in advance of the meeting (and on the CLF VWG Workspace).
You can see a summary of previous meeting decisions/outcomes on the CLF VWG Workspace.
We will again use GoToMeeting to allow you to connect using your computer, tablet or smartphone, or call-in using any phone. Abbreviated instructions for GoToMeeting are below with full list of international dial-in numbers available on the CLF VWG Workspace which also provides relevant background documents for this group.
We look forward to your participation!
The ACES Team
Instructions for using GoToMeeting to join an ACES VWG Meeting
All Virtual Working Group Meetings will use GoToMeeting for their meeting calls. Check
ACESCentral for the specific time and date of each VWG’s next meeting.
You may join via computer/smartphone which will allow you to see any presentations or
documents that are shared or use a telephone which will be an audio only experience.
Please note that meetings are recorded and open to the public. By participating you are
agreeing to the ACESCentral Virtual Working Group Participation Guidelines
Audio Only
You can also dial in using your phone.
Dial the closest number to your location and then follow the prompts to enter the access code.
United States: +1 (669) 224-3319
Access Code: 241-798-885
In preparation for Thursday’s meeting please review this Google Sheet.
This document is an attempt to compile a list all the changes, no matter how big or small, that this group feels are required for the update to the CLF specification. Note that this is an update of an old tracking sheet from just before the publication of the S-2014-006 document, so a few of these might no longer be relevant. The “to-do” items are categorized as editorial (changes to the text in the specification), feature (adding new elements to the spec), or metadata (metadata fields that should be supported). The objective is to get this list to reflect the consensus of this group on all the topics and features that were discussed across the various discussion threads and in the meetings.
Please review and comment either on the sheet itself or reply to this post. There has been a lot discussed in this group and it’s very likely I missed items. Look for your personal “must-haves” and if we’re missing something, make sure we get it on the list or discuss it on Thursday. We’re aiming to wrap this “review” virtual working group and then reform a new group to actually make the changes in prep for ACES 1.2.
Speak up now, or forever deal with a spec you hate…
Hi Scott.
Put my two cents for the next VWG call as comments on the G-Docs version of the spreadsheet.
Since I saw it was flagged as “No”, I strongly advice the group to include a <ColorSpace> tag at both node inputs and outputs (we’ll figure out how to specify color-spaces), because that would greatly help streamlining processes.
Besides, I’d like to ask another point is discussed. Discuss pure syntax extensdbility (e.g. XML namespaces) when a XML file from another dialect wraps / includes a CLF: is the extension/inclusion performed unambiguously with today’s CLF schema, or are there any actions still needed?
Usecases:
embedding a CLF within an ACESclip;
archiving a CLF in the SCM or as dynamic-metadata in the ISXD of an IMF package.
A handful of tiny requests / proposals I’ve been meaning to make:
Alternate / additional clamp behavior styles or options – specifically, an option to linearly extend / extrapolate monotonic functions / 1D LUT arrays based on the slope of the extrama, as opposed to fully clamping or not clamping at all. What I’m really after is a way to mimic the Nuke grade node behavior in CLF. The existing set of nodes gets us most of the way there, but [I believe] linear extensions would bring us to full parity.
I don’t think I saw this on the spreadsheet, but a Group node would be really useful.
A number of the items in the spreadsheet you posted are related to bit-depth, precision, etc. I had hoped we had come to a consensus on this during the previous calls, but perhaps not, given what’s in the spreadsheet? Anyway it’s an important topic so I’d like to reiterate my view on this subject here.
There are three different precision/bit-depth values of interest:
The bit-depth of the input and output pixels to be processed.
This must be controlled by the application/device, independent of whatever is in the CLF file. For example, if someone has a CLF and the first inBitDepth tag is 10i but they want to process a 32f float image, this must be permitted. The application simply needs to scale the input/output in order to be able to use a given CLF with any bit-depth images that are required.
The internal processing precision for the computations.
This should always be 32-bit float. (If that’s not possible, e.g. hardware devices, then it should be best available.)
The bit-depth scaling used to interpret the LUT, matrix, etc. values in the CLF.
Item 3 is what the inBitDepth and outBitDepth attributes in the spec control. (Only this, NOT items 1 and 2 above.) In other words, if a Lut1D has an outBitDepth of 10i then it means the LUT values should be interpreted relative to a 1023 scaling. Once the file has been parsed, it is a simple matter to normalize the LUT values to any desired scaling, as required to satisfy items 1 and 2 above (as described in the spec).
Please note that this implies that no clamping or quantization should be done based on the inBitDepth and outBitDepth tags. The Range node may be used to add clamping to a CLF if desired.
The description above is also consistent with how bit-depth/precision is handled within OpenColorIO and in the Autodesk implementation of CLF.
Thank you all for reviewing and for your feedback. Where appropriate, I’ve added new items and/or transferred comments posted here onto the relevant items in the sheet. Individual acknowledgements of your comments below. We will review the sheet on the GoToMeeting during tomorrow’s call and (hopefully) avoid getting stuck on any one item for too long. I hope we can keep things moving and get through the whole list.
<ColorSpace> tag is listed as “Yes” for inclusion. It said “No” engineering design required, which is a bit misleading since the implementation group will need to determine how to design this. Either with enumerated colorspaces or other. Key point for this group is that it’s a desired addition to the spec.
added XML namespaces to the sheet and will list as point of discussion for tomorrow
I’ve added linear extrapolation as a clamp behavior to the spreadsheet for discussion
the Group node is already listed as change ID #30
@doug_walker
Thanks for delineating the precision/bit-depth items so clearly. What’s in the spreadsheet has some holdover from an earlier version and I’ll clean it up. Some of this text should be put into the spec to better explain this to users and implementors. I have added your items as editorial items to make sure these get more clearly stated in the spec.
And, for convenience, the instructions for the GoToMeeting are pasted again below:
Instructions for using GoToMeeting to join an ACES VWG Meeting
All Virtual Working Group Meetings will use GoToMeeting for their meeting calls. Check
ACESCentral for the specific time and date of each VWG’s next meeting.
You may join via computer/smartphone which will allow you to see any presentations or
documents that are shared or use a telephone which will be an audio only experience.
Please note that meetings are recorded and open to the public. By participating you are
agreeing to the ACESCentral Virtual Working Group Participation Guidelines
Audio Only
You can also dial in using your phone.
Dial the closest number to your location and then follow the prompts to enter the access code.
United States: +1 (669) 224-3319
Access Code: 241-798-885
Thank you to all who participated on this morning’s call.
For those who missed it or would like to review certain parts of the meeting, the recording has been posted to the CLF VWG Workspace. I myself will be reviewing the call and outlining the key points made and seeding conversation where the group decided to defer to continued discussion on ACESCentral.
We’re looking at two weeks from today as the next call, and will be having discussions here on ACESCentral before then.
