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