ACES Metadata Spec Draft

Discussions - ACESNext VWG – ACES Metadata File (AMF)
21

Hi Alex.
Thanks for clarifying about the multiplicity of <archivedAcesPipeline> elements. I didn’t understand beforehand and I’m fine with the XML hierarchy you just explained.

As regards the manufacturer table (let me clarify: just one global, 2-columns table – not a table per each manufacturer), this is a workflow requirement.

Currently, AMF links to footage via either filename (too loose) and <clipID> (ClipID). However, which exact camera-native metadata corresponds to the ClipID of AMF is still undefined.

While some cameras and file formats have, at most, one unique clip identifier, that may be implicilty mapped to AMF ClipID, many professional cameras (and other file-formats) have potentially multiple identifiers, like:

  • absolute TimeCode,
  • ToD timecode,
  • EdgeCode,
  • reel name,
  • short clip name,
  • long clip name,
  • UUID,
  • KeyKode,
  • file hash / digest,
  • etc.

If we don’t provide indication as to which camera-native metadata maps to ClipID, several production workflow ambiguities may arise.
For example:

During DI, an online conforming software B parses an AMF’s <ClipID> by looking for footage matching it vs the short–clip–name metadata, whereas the on-set department’s off-loading software A had been generating the ClipIDs based upon the camera files’ UUID-v4 metadata. Result: no automated color pipeline would be expected out of this scenario.

Therefore, at least identifying one metadata per camera-native format would be necessary.

The further proposal for an optional <metadata> element is due to the requirement to provide a ClipID that can be flexibly assigned to different camera metadata, according to the specific on-set / production workflow.

If we don’t allow this flexibility, we are constraining production workflows to conform or associate ClipIDs to metadata that may change according to production pipelines that may not be color-related (e.g. location-based).

Happy to briefly discuss further via chat, if needed.

Plese note that nested XML ements may be used, within <metadata>, in place of XML attributes, if the latter are to be avoided. This can be trivially specified.

22

Thomas raised a number of interesting points, but I wanted to second his criticism of the lookTransformStackPosition. I had also raised this point during one of the meetings.

For implementors it is always a bit of a hassle to have a file format provide a given piece of information in more than one way. It means that the code needs to handle more than one path for obtaining it and also handle the case where a given file provides contradictory information. It also adds additional QA and testing work.

In this case one could argue that the lookTransformStackPosition is in fact the only official way to specify the order but the problem is that the ordering of the XML file itself is the more “natural” order both to human readers and in terms of what is returned from an XML parser.

I would advise the implementation VWG to add that case to their test plan – namely, where the two orderings disagree.

Doug

23

During preparation for work in the AMFImp VWG a few questions came up here in our team when reading the current version of the AMF specification. These topics probably have been discussed in the AMF VWG already, so my appologies for rising that again.

1. “applied” attribute

The amf:asc-cdl and amf:lookFile have an “applied” attribute. As far as I understand this means, that the look transform is “baked in” the footage already.

What would be a typical use case for using the “applied” attribute?

In my understanding if the look transform is baked in, also the input transform will be “applied”. Does the input transform to be marked as “applied” then as well? Or is this attribute indicating that the clip is even rendered with certain output transform (such as “dailies in Rec.709 with look applied”)?

2. “amf:hash”

I think this is clear for example for a referenced ASC-CDL file, but what is hashed when it’s used in the context of for example an input or output transform? The underlying CTL file?

Any insights would be appreciated. Thank you!

24

The questions have been answered in the AMFImp VWG meeting, thanks to everyone. Here are the short versions (as far is I understood):

  1. “applied” is used for example with an input transform for footage that originally had been in a camera native color space, but has been transferred to OpenEXR in ACES color space. Then the IDT is already applied, but carried in the AMF for reference.

  2. amf:hash is an optional tag, that you would probably not use for “standard” input and output transforms, but is intended rather for custom transforms.

25

@Thomas_Mansencal @CClark …
I’ve added an <aces:author> element with subelements for <aces:name> and <aces:emailAddress>. From what I can tell XML does not support array formats as in @Thomas_Mansencal example.

26

@CClark @doug_walker
I’ve removed the lookTransformStackPosition attribute from aces:lookTransformType.
The order in which the lmts is applied shall be based on the order they appear in the AMF XML.

27

@CClark
I’ve removed the restriction on the number of lookFile or asc-cdl elements that can occur in the aces:lookTransforms element. Also, I’ve removed the restriction on the number of aces:archivedPipeline elements.

28

@CClark

Changed the movie names in the descriptions used in the examples.

29

@CClark

changed example file extensions from .xml to .amf

30

@Thomas_Mansencal I’m open to this … makes sense to me. FYI … there’s a lookTransformsType and a lookTransformType this is intentional with the current structure.

Now that we’ve decided to remove the lookTransformStackPosition and rely on the order in the XML I believe it might make sense to move each Look Transform to the top level.

That raises a question though that I haven’t fully thought through the implications of … should I then eliminate the <asc-cdl> and <lookFile> nodes underneath <lookTransform> and perhaps indicate the if it’s a CDL or a file via an attribute on <lookTransform>
(e.g. <lookTransform type='cdl' applied='false'>)

31

It looks like I can’t restrict the children of an element based on the attribute of the parent element …

So … I’ve added a choice under lookTransform where lookTransform will either contain the contents of what what previously in asc-cdl or lookFile plus the other common elements (e.g. description).

Let me know what you think …

32

All,

Per @dtatut comment at the meeting … I’ve updated the algorithm attribute of the hash tag to use the standard URIs.

33

Hi Patrick.
I think your raised bullet question #2 has not been completely aswered yet.
It’s true that the <hash> is mostly for custom transforms, but it may still be useful to have it in Academy-provided transforms to make sure that a particular implementation of a project doesn’t override standard transforms (for example, the Academy RRT) with “tweaked” ones.

The specification should clearly state the order of precedence by which the hash is computed (digested) on. I would propose this ordered set of alternatives:

  1. if the transform is specified by, at least, a <filename> element (for example, a LUT file), then the value is the hash of the whole external file; otherwise,
  2. if the transform is specified by a <transformId> element, then there should be a reference CTL for that TransformID, that the hash is computed against.

Please note that, in case of non-Academy provided transforms, the corresponding CTL does not need to be public – just the hash is. That also works with vendor-supplied transforms, that can be at least referenced by TransformID (and whose conformance is checked by means of a hash), even if the CTL is not publicly available to users.

34

Currently this is specified as a string. Does it make sense to change this to anyURI and offer guidance in the spec? I’m not sure about relative vs. absolute. Any thoughts here?

35

Hi Alex,

This is great! Only caveat here though is that there is only a single author possible, it might be enough for practical purposes but quite certain that the question about multiple authors will come :slight_smile: Alternative would be a single authors string like that: "Foo Bar <foobar@onset.com>, John Doe <johndoe@onset.com>".

I quite like it from initial perusal, feels much more elegant! Here is the AMF file with both CDL and LMT nodes I was looking at: amf/example3.amf at 70443b306a92b72e950e130b784e70d7fd8f8cc9 · aforsythe/amf · GitHub

Good idea, if adopting anyURI, it would be like that:

../path/to/aces.amf
file:///C:/path/to/aces.amf
file:///Users/John/path/to/aces.amf

Cheers,

Thomas

36

I set that there could be an unlimited number of author tags. See the example :

This would be much more easily parsed by software too.

I agree!

Sounds good

37

Oh super! I missed it, job done then! :slight_smile:

Any comments about my two points about:

  • The maximum number of aces:archivedPipeline and aces:lookTransforms
  • The minimum of 1 RRT?

Those are the two only things that were blocking (for me) when re-reading my notes above.

38

Hi Alex.
I think paths shouldn’t be in AMF at all. Filenames may well be there, but paths are too “loose” and easy to change.

39

Hi Walter,

Would you bind them to a sequence via the .amf filename being the same than the base name minus frame number of an image of the sequence?

40

@walter.arrighetti

File name / path was only one of the ways to reference the essence in the clipId. The other’s were sequence and uuid. I blieve all of those came from your proposal.