There was some discussion of an ACES process node being “out-of-scope” of the LUT format. What about ASC-CDL and Matrix nodes? Should the CLF really only encompass 3D and 1D LUTs?
Yes, I wondered what that was about. Do some people think ASC CDL should not be in there?
To me, although SOP can be expressed as a 3x1D LUT, and Sat as a matrix, ASC CDL makes the transform more human readable, and potentially editable.
One of the great benefits of CLF would seem to be the possibility to break a transform down into a series of components, where each can be labelled as to what it does (and therefore bypassed if required) rather than baking everything into a single “black box” like most LUTs are.
I think ASC-CDL is useful in the CLF spec.
But in the spirit of ‘keeping it lean’ – I would vote for leaving out the ACES-specific processes from the CLF spec. As Doug (I think) mentioned on the call, if someone wants to have these types of conversions as part of a CLF, they could make them part of the 1D+3DLUT.
The ACESclip spec could handle the ACES specific steps, perhaps surrounding a reference to a CLF, which might be a LUT or ASC-CDL.
Just my 2 cents.
1 Like
Good points. There is always a tradeoff between “keeping it lean” and “not fixing what’s not broken” vs convenience. I think that adding complexity should be avoided wherever possible. My personal mantra for all things ACESNext is “simple and simplify”. So I’m in favor of not adding more if the existing spec can meet the needs (albeit “less conveniently” at first).
I personally think that those often needing to go from linear ACES to ACEScct, for example, will develop the most precise but efficient way to encompass that in the existing spec and then use that as a drop-in whenever that conversion is needed. However, easier said than done as I haven’t much tried bundling up various concatenations of transforms in CLF (due to lack of implementation).
I think the questions on adding metadata like colorspace conversions, vs the keeping integer/halfs/floats paves the way to an integrated philosophy, whose main driver, in my opinion, is which applications should CLF be designed to work natively with
- If low-computability devices (LUTboxes, monitors, etc.) are in-scope as well, to be able to read and use a CLF, then integers and half-floats should be kept, whereas references to colorspace transforms and higher-level color operators (possibly with the exclusion of CDLs) should be removed.
- If CLF should be elective format to only “devices” with some computational power, conversely, higher-level operators should be factored-in, while integers/halfs may be let go without a tear, as those higher-power applications may be demanded to do the back-end conversions (in an as-much-as-possible controlled/pre-determined way).
I agree with keeping it lean - I was just alarmed that a transform like linear to ACEScct using a size of 1D LUT that most use as a maximum possible size is not precise enough.
I really think that anyone that supports CLF should be able to handle all parameters of CLF. All or nothing. I should be able to have a CLF with 20 3D LUTs with CDLs in between each LUT and have that be read in and displayed the same anywhere it is used. I perceive it as a master format, after all.
I agree with you Greg.
That is why my personal opinion is:
«goodbye integers, nice-to-meet-ya “color-metadata”».
What I think @doug_walker said was that a linear to ACEScct conversion could be performed with very high precision using a halfDomain 1D LUT. While this is true, my concerns with that are that:
-
All applications will need to support
halfDomainif they want to claim CLF support. I won’t mention specific apps, but this is not currently the case. -
A
halfDomain1D LUT has 65536 lines in the table, so a simple LMT which is an ASC CDL in ACEScct becomes over 130,000 lines long, because it needs ahalfDomainLUT at the start and end.
imho ASC-CDL and matrices should absolutely stay in the specs. I am more conflicted about ACES specific processes. Maybe we could added to a v2 of the spec? Again, I am undecided as of now.
About the all or nothing support for CLF: absolutely. But, as I said in another thread, if the CLF needs to be process, after import, to match, say, a hardware implementation, the user should be warned about it. e.g. Flanders Scientific’s BoxIO, TVLogic (formerly FujiFilm and Wowow ent.) ISMini, feature a 3x1D->3D->3x1D LUTs. If a CLF defined as such is loaded, great. if not (say there is an added matrix or two 3D LUTs in the CLF), then the implementer will have to process the CLF to match the hardware. I’d love to see an indication of the error generated by that processing (I have ideas about how to do just that).
What @CClark said about possibly leaving ACES-specific features in ACESclip (and out of CLF), brings to a slightly skew issue: what goes in ACESclip and what on CLF?
This is a central question that should probably need cross-discussion among both VWGs.
Sticking with CLF here, if ACES-specific features are pulled of a generic CLF specificatio, then I believe that CLF (as general as they are for a LUT) should include integer arithmetics, because a lot of generic use-cases demand it.
ACES-specific uses of CLF (possibly including constrains on the “float” arithmetics) may be added to the standard.