ACES Metadata File Development

Unique constraint should work in this PR.

Per the request at the last meeting I’ve created a branch using pascal case instead of camel case..

Just may 2¢ but I prefer camel case. I find Pascal Case awkward particularly in situations where the element names begin with acronyms.

Examples

Camel Case
<lmtWorkingSpace>
<rrt>
<odt>
<uuid>
<acesPipeline>

Pascal Case
<LmtWorkingSpace>
<Rrt>
<Odt>
<Uuid>
<AcesPipeline>

I’d love to hear other’s thoughts

1 Like

I’ve added framing info to the XSD per @walter.arrighetti suggested method …

Frankly I could use a little more of tutorial on what the 4 integer values represent

Hi Alex.
First of all, by 4-coordinated system I mean any 4 numbers meant to represent a window, be it either (llx, lly, urx, ury) like in PDF or (x0, y0, W, H) like in most graphics programming.

We should be as generic as possible in defining framing, thus we want to include (de-)squeezing / (de-)anamorphizing and reflections, other than just extracting a window out of a frame. The most general way to specify this is describing both a first 4-tuple of the input window (for extraction) and, either

  • a target aspect ratio. described as ratio of the (W, H) 2-tuple, or
  • another window (descibed by a second 4-tuple) in which the former (extracted) windows is squezzed into.

For example, if we are to achieve a 2K central extraction of a 16:9 frame (2048×1152) out of a 4K full-ap film frame (4096×3552) and fit it into a Full HD resolution (1920×1080):

  • the first 4-tuple would be (llx,lly,urx,ury) = (1024,2352,3072,1200) or (x0,y0,W,H) = (1024,1200,2048,2400)
  • the squeezing (from 2K to HD resolution) would thus be just represented as either (W,H) = (1920,1080), or as (llx,lly,urx,ury) = (0,0,1920,1080)

By the way, the second method will also allow for horizontal and vertical reflections (exchanging top-down and left-right ordering of coordinates).

Hi Alex.
I usually hate camelCase exactly because acronyms become all-lowercase and because the first word always results in reduced visual impact (whereas it’s usually very important, like in acesPipeline).
When I implement things, I use PascalCase, but keeping acronyms all-caps, therefore <RRT>, but also <ACESPipeline>.

When I implement things, I use PascalCase, but keeping acronyms all-caps, therefore <RRT> , but also <ACESPipeline> .

This makes sense but I don’t like that it’s hard to guess what the correct case is for any given element if you don’t happen to know what’s an acronym and what isn’t …

e.g. is ACES an acronym or just a word? Hence, should it be acesPipeline or ACESPipeline? Also looks like ACESP to my eyes.

This is all subjective obviously … hardly the most important decision.

How does this denote a squeeze vs taking a window of 1920x1080, aligned to the lower left corner, out of the 2048x1152 frame?

Hi Alex, in the example above, this is just a resize from 2K to HD, but keeping the aspect ration to 1.77.
Should the target window be set to, say, 1920x2160, anamorphic 2:1 squeezing would also have take place

So where is the target window specified?

@Alexander_Forsythe - sorry for the last minute post ahead of todays meeting.

As mentioned during the last call, I suggest removing the UUID related type definitions (uuidType, uuidVersionType, uuidStringType) from the schema and instead go for the widely used (in DCP and IMF specifically) UUIDType definition from SMPTE ST433, available in this namespace:

http://www.smpte-ra.org/schemas/433/2008/dcmlTypes/

Happy to provide a pull request for review, unless somebody tells me that’s a bad idea!

Link to ST433 schema file for reference.

Hi,

Just noticing in the Schema: https://github.com/aforsythe/amf/blob/master/acesMetadataFile.xsd

type=“amf:tnRRT”

type=“amf:tnOdt”

type=“amf:tnIdt”

amf:tnRRT should probably be title cased like the others for consistency.

Cheers,

Thomas

And also:

<xs:element name="SOPNode" type="cdl:SOPNodeType" minOccurs="1" maxOccurs="1"/>
<xs:element name="SatNode" type="cdl:SatNodeType" minOccurs="1" maxOccurs="1"/>

Why the casing change here?

Cheers,

Thomas

Yes, probably need to do some clean up … separately there was a suggestion to expand out the acronyms for better readability.

This is the case used in the CDL schema … I stuck with the names they defined but I can alter them to be more consistent with our formatting.

That was my assumption but I thought I would raise the point for discussion :slight_smile:

What do you mean by expand?

Instead of RRT use referenceRenderingTransform

Oh right, I don’t really mind the short forms, especially because they have been around for a while people know them.

That said now that you mention it seeing ODT and OutputTransform is somehow not very elegant and using OT certainly not very clear.

In order for AMF to be really interoperable (for example, embedding AMF elements into an IMF package as part of either a SCM .xml or an ISXD ,mxf file), clear indications on the AMF namespace and its usage in AMF-specific element names, should be clearly and unambiguously described.

I am referring to clear indications. Is amf the chosen namespace, or wouldn’t it be better to use one namespace aces for all ACES-related XML files (including CLF) ?

Also, whatever the namespace is chosen, it should be mandatory in all AMF characteristic namspaces. Therefore, it’s <amf:RRT> or <amf:referenceRenderingTransform>, not <RRT> alone.

I just picked amf. Happy to change it if that makes sense. Note CLF is not ACES only. Hence, I don’t think it makes sense to make the CLF tags part of a aces namespace.

Is this best practice? I’m not an xml expert. Would it just be reflected as a change in the example, or is there as way to require the namespace via the xsd?

Alex

Hi Alex.
Strictly speaking, good XML syntax requires that each element has its own namespace prepended.

In real-world, I’ve seen XML files where, after assigning a namespace to an element, that namespace becomes the default for all of its children, which are then entered without namespace – unless some children are given specific, different namespace specifications – in which chase the latter have precedence.
But, in such a case, problems may arise if the AMF embeds chunks from other XML schema (e.g. CDL, CLF, etc.) or -vice versa- AMF is embedded into a bigger XML file. This latter case may happen if AMF is embedded as part of:

  • SCM or ISXD components of IMF packages (which I’d love to see in the ADSM for binding AMF metadata to an IMP)
  • digital signature wrapping the AMF for sealing its integrity and authorship
  • a video processing application’s own XML-based project file (e.g. R&S Clispter, FinalCut Pro, NUKE, etc.)

Just look at how the CPL component of any SMPTE-compliant DCP looks like, particularly at the usage of elements from the XML Signature standard, which are usually assigned the namespace ds.

Let me clarify a single point though. The namespace name (e.g. either amf or ampas) is just a convention. The real namespace is the URI reference to the XML schema file given by the xmlns attribute value; you can define any namespace name as long as this is consitently used throughout the same XML document.

Happy to have a conversation to you for more clarifications.