The some degree, what tolerance specs exist are for the Logo Program and are around making
A “well established and supported GPU” language would be nice, but there is serious custom-lock-in happening with those (DirectX12, Metal, Vulcan) If we had picked something a decade ago, it might have become a backwater. We did consider CUDA at the time, but it wasn’t open enough.
In retrospect, we would have been better off building a “Pixel API” library and a "Color processing API” and writing the functions in ‘C’. That is a fair amount of work though and for a volunteer effort was a bridge too far. Even today, no company stepped up to take over CTL after ILM developed it.
The question at the moment though is, for ACESNext, what development work is needed that would facilitate growth and the future of ACES in a hardware environment that is changing each decade.
There are technology trends that are changing as well. Dynamic metadata rendering instead of static LUTs. The transition to machine-learning centric GPUs has already started. What effect would AI techniques have on colorist work and color appearance modeling? At the TV manufacturer level, they cannot do some transforms because of complexity and time when processing 4K/8K images. Could more efficient processes allow better color rendition in a TV?
These directions somewhat overlap the use of ACES in a production context, and unfortunately, the motion picture industry is not big enough to drive the technology very far (compared to gaming for example). However, in the matter of influencing useful imaging for other areas, it can – looking at the usages of ACES concepts at NVIDIA for example.
With the start of the motion picture open-source foundation, is there a project that could get support for making a more usable production tool than CTL – after all, it biggest defect is just performance which is really a solvable problem. (and yes the second biggest being debugging).