Please mark your calendars and join us for the ‘kick-off’ meeting of the CLF Spec / Code Review VWG.
The meeting will be lead by working group Chairman JD Vandenberg, and will take place on
Thursday January 17th, 2019 9am - 10am pst (Los Angeles time)
We will use GoToMeeting (GTM) to allow you to connect using your computer, tablet or smartphone, or call-in using any phone.
Instructions for GTM are below and also on the VWG Document 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
Reminding everyone in the ACES community that we’re kicking off our CLF Spec/Code Review Virtual Working Group this week on Thursday at 9am pst (Los Angeles) time. Please join - instructions above!
I am happy to announced that @bram Desmet from Flanders Scientific will join the call and share his thought on CLF from a hardware implementation point of view!
Thank you, @jdvandenberg. Hope to be able to answer what is possible on current hardware as well as what is feasible on new hardware available this calendar year. If there are very specific questions anyone would like answers to maybe drop me a note before the meeting and I’ll do my best to look into those ahead of the meeting.
Thank you to all who participated in the first call re: CLF.
In my assessment, two “soft decisions” were reached on the first call:
The specification will remain XML.
There is no compelling enough justification to redefine the specification. There is a thread for discussion here.
The specification should not contain optional parts.
A “common LUT format” where implementations are not required to implement support for all parts of the format loses its commonality. Discussion started here.
Additionally, it was suggested that the specification be made simpler by removing integer encodings. Discussion is on-going here, but so far there appear to be many reasons in favor of this suggestion and few reasons against it.
Please continue to discuss these items if you have a reaction, but please state your case in the relevant discussion threads linked above (or start a new one specific to your question).
Details for the next call will be sent out shortly.