Notice of Meeting - ACES CLF Implementation VWG - Meeting #2 - 1/21/2020

ACES CLF Implementation VWG Meeting #2

Tuesday, January 21, 2020
1:00pm - 2:30pm PDT (Los Angeles time / UTC-09:00)

Please join us for the next meeting for this virtual working group (VWG).

Dropbox Paper link for this group:

We will be using the same GoToMeeting url and phone numbers as in previous groups.
You may join via computer/smartphone (preferred) which will allow you to see any presentations or documents that are shared or you can join using a telephone which will be an audio only experience.

Please note that meetings are recorded and transcribed and open to the public. By participating you are agreeing to the ACESCentral Virtual Working Group Participation Guidelines

Audio + Video
Please join my meeting from your computer, tablet or smartphone.

First GoToMeeting? Let’s do a quick system check:

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

More phone numbers
Australia: +61 2 8355 1038
Austria: +43 7 2081 5337
Belgium: +32 28 93 7002
Canada: +1 (647) 497-9379
Denmark: +45 32 72 03 69
Finland: +358 923 17 0556
France: +33 170 950 590
Germany: +49 692 5736 7300
Ireland: +353 15 360 756
Italy: +39 0 230 57 81 80
Netherlands: +31 207 941 375
New Zealand: +64 9 913 2226
Norway: +47 21 93 37 37
Spain: +34 932 75 1230
Sweden: +46 853 527 818
Switzerland: +41 225 4599 60
United Kingdom: +44 330 221 0097


As a follow up to today’s meeting, thank you all for your participation today.

Here is the Dropbox Paper site (as previously shared in the meeting invite above). On this page you can find the CLF Specification, group proposal form from which Doug constructed his slides, and the meeting history. The link to the recording of today’s call has been posted there under “Past Meetings”.

The next scheduled meeting will be Tuesday, February 4th, 1pm PST.

Please think about the discussion from today and use ACESCentral between now and next meeting to offer any thoughts on:

  • ideas for test images
  • ideas for valid test files
  • ideas for error-producing test files (Doug to share his strawman “starter” list on Google Sheets)

Thank you Scott. I will add one bit of homework for people prior to our next meeting:

Please review the current draft of the spec that is on the Dropbox site that Scott linked to. If you have any suggestions about how to improve the wording to make it more clear for implementers, please let us know.

Big thanks to everyone who made time in their busy schedules to participate today!


I have to say, I still find the presence of integer bit depths adds confusion, and I am still not convinced of the need for them. It leads to potential ambiguity in the documentation. For example, section 5.1.4 says:

To rescale Matrix Array values when the inBitDepth changes, the scale factor is equal to oldScale / newScale.

For example, to convert from 32f to 10i, multiply array values by 1/1023.

Logically an identity matrix which converts 32f to 10i would have 1023 along the diagonal, and zero elsewhere. So where does “multiply by 1/1023” come in? Multiplying the aforementioned matrix by 1/1023 would produce the standard identity matrix with ones along the diagonal. So that would be the matrix to use in a system that was working entirely in normalised float. So is that sentence describing the process needed to convert a CLF with varying bit depth for use in a normalised float system? I guess so.

But it’s confusing. The phrase “to convert from 32f to 10i” is ambiguous, and doesn’t necessarily suggest the above situation to me. To convert image data? To convert matrix coefficients?

Likewise the phrase “multiply array values by 1/1023” could be taken to suggest that implementers should apply that scale factor to the values they read from the array, or that CLF creators should apply that scale factor when calculating the values to put in the array. It’s not immediately obvious which is the case.

I have said in the past that dropping integer support would make things much simpler. But I know I have been out-voted!