ACES Metadata File Development

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

All,

I’ve posted the code for the ACES Metadata File schema and an example to https://github.com/aforsythe/amf

Please feel free to fork, modify, and send a pull request with any suggested changes.

The one issue I’m still trying to figure out is related to enforcing unique values for the lmtStackPosition attribute of the asc-cdl and lookFile elements.

I’ve tried using the following but I can’t seem to get it to work properly.

<xs:element name="acesPipeline" type="amf:acesPipelineType" minOccurs="1" maxOccurs="1">
	<xs:unique name="uniqueLmtStackPosition">
		<xs:selector xpath="lookTransforms/lookFile | lookTransforms/asc-cdl"/>
		<xs:field xpath="@lmtStackPosition"/>
	</xs:unique>
</xs:element>
2 Likes
2

Sorry if it was already discussed but what is the reasoning behind lmtStackPosition attribute ? Isn’t it implicitly obtained while parsing the XML ?

3

The goal is to be 100% clear as to the order the LMT elements should applied.

4

Cound this requirement of “unique position” be achieved using a DTD ?

5

@walter.arrighetti not sure I’m following. The schema (XSD) serves a similar role to a DTD but with more control.

6

Unique constraint should work in this PR.

7

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
8

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

9

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.
10

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).

11

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>.

12

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.

13

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

14

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

15

So where is the target window specified?

16

@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.

17

Hi,

Just noticing in the Schema: amf/acesMetadataFile.xsd at master · aforsythe/amf · GitHub

type=“amf:tnRRT”

type=“amf:tnOdt”

type=“amf:tnIdt”

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

Cheers,

Thomas

18

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

19

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.

20

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

What do you mean by expand?