I agree with @jmcc that including non-ACES working spaces in AMF may be overkill definitely slowing down the spec’s completition.
The ACESclip requirement VWG had identified such a feature to be, indeed, a requirement for AMF; that is why it is still being discussed.
I was, personally, neutral to that.
However, to clarify the rationale behind lmtWorkingSpace to @jmcc, it should be considered that one may have a pre-existing show LUT working, for example as a ACEScc-to-ACEScc LUT, or "LogC-to-LogC LUT.
Re-using such in an ACES-workflow as a LMT means, otherwise, It is hard to tell these guys to manually convert it into an ACES2065-to-ACES2065 LUT first, before it can be included as the LMT part of an AMF: it makes more sense to define the space(s) it works on in case they’re not implicitly ACES2065-1.
That said, I also agree that, due to the fact that AMF is an ACES component, it could be narrowed down, for now to support only ACES color spaces.
I put together a solution to address the output referred use case where we want to go through the inverse of an output transform or inverse ODT / RRT.
You can take a look at it here :
Basically underneath the <aces:inputTransform> tag you can have a transformID for an IDT, or a series of tags specifying the transformID of an <aces:inverseOutputTransform> or an <aces:inverseOutputDeviceTransform> and <aces:inverseReferenceRenderingTransform>.
You’d use the inverse transforms to convert output referred images to ACES before going forward through the rest of the pipeline as specified in the AMF.
Let me know if this makes sense before I write it up in the spec document.
I want to voice my support for Joe’s grammatical edits to the spec. If there are no objections, I will update the spec with those edits.
I also agree that the non-ACES working spaces adds significant challenges to both implementation and interoperability (as we have already seen). In going back to old recordings from our Requirements group, it sounds like the use case was from a real-world project that used LogC as the LMT working space. Personally, I feel that this workflow could be adapted to utilize an ACEScct working space, and greatly reduce the complexity of the spec. This may deserve its own thread but I wanted to voice my opinion here.
I just had the chance to take a very brief look today, but the syntax in the new example4.amf looks very good to me. I like that it is explicit that this is not a regular IDT. So yes, that specific issue with the inverse-ODT “IDTs” seems solved very well with that.
Generally limiting the definition of a working color space to the transforms that actually require it – namely the ASC-CDL node – seems like the right way to me in order to limit the use of WCS to necessary use cases, and to further substantiate the intended use of working color spaces in the context of LMTs. It also might help reduce maybe yet unforeseeable consequences for the future of “regular” LMTs, where now ACES 2065-1 (AP0) is always required in order to make them applicable as universally as possible.
I have one question about how to use that in a use case that we currently cover in our software:
In Livegrade (and I guess also in other applications) users have the option also to apply one or more 3D LUTs in the WCS (e.g. ACEScct) before or after the ASC-CDL.*
If we want to recreate such a pipeline (for instance IDT X -> ASC-CDL in WCS Y -> 3DLUT in WCS Y -> RRT -> ODT Z) in other systems, how would we encode that in the proposed AMF variant?
Maybe we are missing a second “legacy” transform node that also requires a WCS definition, namely a “LUT-based transform”. Again you could argue that it is necessary to specify a WCS for that (because applying LUTs in linear doesn’t make much practical sense the same ways as ACS-CDLs). So we might need to introduce a similar mechanism for 1D / 3D LUTs as for ASC-CDLs. Or is this already covered somehow else?
I feel we’re getting very close now, but didn’t nail yet the use cases with externally defined transforms in the role of “LMTs”. With this I mean transforms that are custom-created for certain scenes or productions, and thus need to be defined outside the AMF file (e.g. as the mentioned 3D LUT files, or maybe also as CLF files), and that yet need to be referenced from the AMF file somehow as look transforms in order to be able to recreate that pipeline.
(*) Allowing to apply 3D LUTs in the WCS together with the ASC-CDL has become necessary in order to allow “custom LMTs” (e.g. provided by a post house or dailies facility) to be transported and applied in the format of 3D LUTs – especially as long as we didn’t have CLF or other formats that allow to be applied meaningfully in the scene-linear encoding of ACES 2065-1. Thus providing such “LMTs” as 3D LUTs (to be applied in a certain working color space) has become a practicable way of encoding and applying custom LMTs in such available 3D LUT formats.
My understanding of the current spec is that it does allow your use-case (in your example, applying 3DLUT in WCS Y). But the proposal in that thread is to remove the ability to apply transforms other than a CDL in a working color space (other than ACES2065-1). This is why I wrote in that thread that I was worried that it would remove the ability of AMF to easily support certain use-cases.
The reason that I was not entirely opposed to the proposal is that CLF does support packaging more typical log-space based LUTs into a container that expects and produces ACES2065-1. So that would be one work-around that would allow implementation of the use-case you describe, even with the latest proposed change.
In other words, the working space conversion gets moved from within the AMF implementation into a step of packaging the original LUT from the production into an appropriate ACES2065-1 based LMT as a CLF. We could potentially add something to OCIO to provide that service, if people would find it useful (e.g. using any of the existing ACES CSC transforms and any of the 20+ LUT formats supported by OCIO).
This is an extra step, but as Chris wrote in the proposal, the benefit is that there is no uncertainty about what color space an LMT expects as input and output – it is always ACES2065-1, and thus follows the existing LMT spec from ACES 1.0.
I think Doug hits the nail on the head here. For a LUT that currently assumes ACEScct (or any other working space) in, there’d need to be a repackaging step that makes the LUT compatible with ACES 2065-1 in/out.
Thanks for clarifying that (sorry that I had not seen that other thread yet).
So to put it differently, the latest proposal of AMF (with the limit of WCS definitions to ASC-CDL) purposely cuts out use cases that use custom 3D-LUTs as look transforms – and relies on the implementation of CLF as a replacement for such 3D LUTs.
I have to admit this is a clean solution, but I agree with Doug Walker that this will have an impact on adoption. While “80%” of use cases (with ASC-CDL only in WCS) might be covered well with AMF then, the “20%” of special cases – where a custom transform is required – cannot be covered with AMF by systems not supporting CLF yet. So the availability of CLF support now becomes a prerequisite for AMF support in systems that want to cover common use cases with AMF comprehensively.
If this becomes the version for ACES 1.2 now, I think these constraints should be clearly communicated as part of the AMF documentation in order to make the requirements clear for implementers.
For instance the ambiguous word “LUT” or vague references to an “external look file” then should be entirely replaced by something like “CLF-based look transform”.
Example (in S_2019_00x_AMF_DRAFT from 2019.12.19):
p7:
AMFs may also embed creative look adjustments as one or more LMTs (using the <lookTransform> elements). These looks may be in the form of ASC CDL values, or a reference to an external look file or LUT.
→
AMFs may also embed creative look adjustments as one or more LMTs (using the <lookTransform> elements). These looks may be in the form of ASC CDL values, or a reference to a CLF-based look transform.
I think our intention is to keep the AMF somewhat implementation neutral. It lays out what the processing steps are to get from camera images or ACES images to a screen. The implementation may or may not decide to use LUTs (CLF or others), GPU code, CTL, or others. They may have specific issues that they need to tackle or may choose the concatenate steps. LMTs being the exception I guess …
Currently TB-2014-010 says they are CLF so I guess existing show LUTs would need to be “rewrapped” as ACES to ACES CLFs. This may be something to revisit in ACES 2.0.
I’ll try rewording but “external look file” may be a CLF or something like an EDL with embedded ASC-CDL values.
Hello.
I just read the example AMF from the lates draft and I have three points I’d like to discuss – either today or at another date.
FIRST
One of the CDLs referenced in the AMF sample (approx. line #114) employs the ColorCorrectionRef element: <cdl:ColorCorrectionRef ref="03345"/>
Actually that is to be used when there is an actual collection of color corrections (in a file with .ccc extension), so that each EDL or ALE file may just reference the name of a specific CDL within those listed in the CCC, without retyping the numeric parameters each time.
Using such CDL feature in AMF means that the AMF is referencing something not within the AMF itself and --ever worse than this-- it is a reference to something that AMF provides no actual mechanism to unambiguously refer to: where could this reference #03345 be ever found externally?
It makes sense to explicitly say in the AMF specs that only individual CDLs may be referenced within AMF.
Or, alternatively, CCC may be allowrd as well in AMF (I suggest under the generic LookTransforms element), so that internal cross-referencing happens, independently in the IDT, LMT, RRT and ODT parts of it.
SECOND
The XML namespacing in the example (a generic xmlns attribute in the root element and no namespace specification in any of the descendant XML elements ) is good as long as AMF is not to be embedded inside something else.
An even better implementation would be to use a namespace tag (actually any namespace tag), like for example amf, specified in a named xmlns:amf attribute in the root element, and use it consistently in any descendant elements. I would recommend that AMF parsers are capable of at least this latter forms – even if most implementations would use the simpler one. I am attaching the two variations here:
The latter sample is good in case AMF is to be embedded into larger XML files. Using the former sample requires the embedding application to create a namespace and convert the former into the latter before embedding – which embedding application may not be able to do.
This may seema a neglectible problem now, but if you think about it many existing applications already use XML-based project files: Foundry Nuke, Autodesk Flame, FilmLight Baselight, R&S Clipster, Colorfront, Apple FinalCut ProX, etc. They may ultimately benefit from having the opportunity to streamline the embedding of AMF into their products.
This would eventually facilitate adoption of AMF by manufacturers of software that is already XML-based based.
THIRD
As agreed during one of the recent VWG calls, I am attaching a few variations of the sample AMF, with a few stressing of XML syntax in a ZIP file.
The files are all valid XML files, therefore the any application honoring AMF should be capable of parsing all of them. If not, the parsers may not be complete.
I would strongly suggest adding some soft of reference AMFs so that manufacturers can stress their AMF parsing capability.
Those who are long time in the business know that just saying XML is not good… somethimes XML files from “obscure” implementations need to be post-processed by whitespce / end-of-line / syntax-check tools before they become totally interoperable among different implementations that use incomplete writers to generate data files, and/or incomplete parsers to read them.
In the end:
applications writing AMFs should write files in a clean (possibly canonical) XML style;
applications reading AMFs must read any file with an XML-vaid syntax
I completely agree but I think this an issue for the implementation group to deal with rather than including the spec. I could add a details about required line endings to the spec if people want.
The latest complete draft spec is posted at the top of this thread. There’s also a link to the working copy on overleaf that is a work in progress but incorporates changes such those to the LMT working spaces that we’ve been discussing.
I think your point about the cdl:ColorCorrectionRef may be valid even though it isn’t in the latest examples. The type for the cdl:ColorCorrectionRef attribute ref is AnyURI. Would it be useful to specify the pattern for the ref URI?
Hi Alex.
The ColorCorrectionRef element should be either avoided in CDLs used inside AMF, or it should be defined how to reference external CDLs (the same way AMF may reference an external LUT, or an external piece of footave gia clipID)… which I’d rather avoid.
In my opinion, CDLs inside AMF should be fully described as Slope/Offeset/Power/Staturation 10-tuples. But if ColorCorrectionRef is to be allowed as well, then the specs shouls clearly state how to reference.
Possible, alternative solutions are:
ref is allowed to be a UUID which is an identifier pointing to another part of the AMF, where that CDL’s slope/offset/power/saturation values are defined. This pars with my earlier (2019) proposal for hosting a repository of transforms inside and AMF file, which the transforms used in the IDT, LMT, RRT, ODT parts of the AMF file all refer to.
ref is allowed to be a UUID to CDL embedded somewhere else by means of default XML extensibility features. For example, it points to the id attribute of an XML element containing both a SOPNode and a SatNode.
ref is allowed to be a filename or an online resource (in this case a AnyURI may stay). In that case AMF may reference external CDLs (like it does with referring to external LUTs or external footage via clipID). In which case, however, it should be stated clearly that applications “validating” AMFs should check whether the externally-referenced CDLs are available as well.
Choice #1 is also good in the case of AMFs with looong pipeline histories. where most of the pipelines in the history share many color transforms: having one “vault” with all the used the transforms helps keeping the size of the AMF file small.
The AMF currently supports CDLs specified inside the AMF itself using <cdl:SOPNode> and <cdl:SATNode> or <cdl:ColorCorrectionRef> as a means to reference a CDL in an external file. See details in the schema.
Hi Alex.
I gues I am being misunderstood here.
I know that SOPNode and SatNode are supported in AMF.
However, ColorCorrectionRef referenes a CDL specified somewhere else.
In ASC CDL, this usually means a CDL specified in another .cdl, or .ccc file.
So my concern here is: how is ColorCorrectionRef referencing mechanism implemented in AMF? (IF it needs be implemented rather than disallowed?)
In that case the either:
ColorCorrectionRef still references an external file (so AMF needs a double reference: one to the external CCC file itself, and one to the particular CDL inside that CCC file – only the latter mapping to the ref attribute)
ColorCorrectionRef references a SOP/Sat specified CDL embedded within the same AMF file.
Either way, we need to write in the specs how this works, otherwise we risk of having AMFs referencing externally-defined CDLs that aren’t just there.
I agree … this needs to be specified, but given the type is AnyURI is there a way to specify both the external file and the CDL inside that file within a single ref attribute?
I don’t see why one would do this? The schema allows for either SOP/SAT nodes or a ColorCorrectionRef. The intention in AMF is that ColorCorrectionRef be used to reference external CDLs, no CDLs within the AMF. Is this a problem?
Hi Alex.
As Josh and I remarked during last VWG call, having AMF referring other components outside the AMF file itself, by using filenames (and even worse – absolute or even relative pathnames) exposes AMF to severe interoperability issues.
What happens if one application --or human-- moves/copies/transfers either the AMF and/or the referenced LUTs/CDLs without changing the pathnames in the AMF as well?
That would breadk the AMF purpose and break the workflow completely.
As Josh said: we don’t need to solve filesystem consistency issues among the files: applications are there to solve this issue. For make every app happy. the AMF must be either self-consistend (e.g. embed all CDLs and LUT it needs) OR it must refernece external files (LUTs, CDLs, etc.) in a smarted way that is not broken by filesystem operations.
That is why my circle-squaring proposal from the last VWG call comes from: move all CDLs into a CommonLUT file and embed the CLF into the AMF itself, by simply extending the XML namspaces.