ACES Metadata File Development

(Alex Forsythe) #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>
1 Like
(Rémi Achard) #2

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

(Alex Forsythe) #3

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

(Walter Arrighetti) #4

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

(Alex Forsythe) #5

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

(Rémi Achard) #6

Unique constraint should work in this PR.

(Alex Forsythe) #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

(Alex Forsythe) #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

(Walter Arrighetti) #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.
(Walter Arrighetti) #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).

(Walter Arrighetti) #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>.

(Alex Forsythe) #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.

(Alex Forsythe) #13

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

(Walter Arrighetti) #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

(Alex Forsythe) #15

So where is the target window specified?

(Florian Schleich) #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.