One small clairification folks ... the code to be reviewed under this group is considered an embodiement of the spec and not an implementation per say.
ok!
Lean is good!
I think we need a good reason to move away from XML. What advantage would a new format bring?
I agree with JD and Nick... I'm don't find XML particularly problematic
Tend to agree JSON is easier to read but not worth the trouble of moving
+1 to doug's point
agree. was just something that was mentioned at some point and didn't want to dismiss any input. i agree with "let's not fix things that aren't broken"
Staying with XML, we should confirm that we have a schema for CLF.
There's a schema in Annex A of the Academy Spec (S-2014-006). The spec is posted multiple places including the Virtual Working Group Workspace (https://aces.mp/CLF_SPEC_VWG)
I think it's important to keep integer. Integer is precise.
+1 to Rod's point
6 decimal places of text float is sufficient to unambiguously code 12-bit int, or 16-bit half, is it not?
I think there's a point where enough digits of float can encoding an int but you get into issues of rounding on the way back.
I did some testing, and I believe 6 decimal places means a 12-bit int can be converted and read back without rounding error
great
Is it a problem to multiply by 1023 or 4095 at parse time?
The spec already acknowledges that precision will vary between implementations.
Hi. I could make it in the end
Sorry for being late
Welcome Walter!
yes
feels out of scope to me ... this is a lut format not an ACES implementation per say
Same. I suspect ACESclip will handle some of this and then reference a CLF, which should just be a LUT
Seems like the lut boxes would just need to make a LUT from the equations anyway
If you have suggestions on meeting logistics or how to get the word out about the VWG meetings, please share! You can find me on ACESCentral or email me at steve@letoentertainment.com