In the new documentation page, step 5 of the template application algorithm demands: "Round all dimensions and anchors according to the template's RoundStrategy". However, I do not believe that the rounding was ever intended to be applied to 'all dimensions' since this breaks one of the most fundamental features of the FDL description.
To illustrate, suppose I used an Alexa LF open gate (4448x3096) with a spherical lens and framed for theatrical 2.39:1 such that the central 4096x1716 was the framing decision. The standard way to present this in dailies would be to map that same framed area to the central 1920.0 x 804.375 of an HD frame and allow the rest to be cropped. I believe this common dailies strategy is described with a template like:
{
"label":"Editorial",
"id":"E",
"target_dimensions": {"width": 1920, "height": 1080},
"target_anamorphic_squeeze": 1.0,
"fit_source":"framing_decision.dimensions",
"fit_method":"width",
"preserve_from_source_canvas":"canvas.dimensions",
"maximum_dimensions":{"width": 1920, "height": 1080},
"pad_to_maximum":true
}
and the resultant editorial canvas for this camera should have a framing decision with:
"dimensions": {"width": 1920.00, "height": 804.375},
"anchor_point": {"x": 0.0, "y": 137.8125}
Notice the non-integer dimensions. If you rounded these in any way, then you would not be correctly describing the dailies process for this camera. Indeed, the spec explicitly implies that this is reason for having floating point anchors (section 7.3.4.10.5 of the 2.0.1 document):
anchor_point uses float versus int values to avoid scaling ambiguities and rounding issues when scaling.
The way I read the FDL specification, rounding should only be applied to the new canvas dimensions and only in the event that a pad or crop has not been applied (with the use of a maximum_dimensions value). See section 7.4.12 of the 1.0.2 document:
round is a pad or crop function used to refine the calculated height and width values of an output
canvas’ canvas.dimensions.
round is only applicable to the canvas.dimensions of the output canvas ...
If maximum_dimensions is defined and pad_to_maximum = true, then round has no effect
And note that rounding the new canvas dimensions does not necessarily imply that the new quantities end up as integers (though they often will). Consider the same camera canvas as above but with a template that kept only the framing decision, like:
{
"label":"Example Template 2",
"id":"T",
"target_dimensions": {"width": 1920, "height": 806},
"target_anamorphic_squeeze": 1.0,
"fit_source":"framing_decision.dimensions",
"fit_method":"width",
"preserve_from_source_canvas":"framing_decision.dimensions",
}
To keep the result centered, as intended, the resulting canvas should have a framing decision with:
"dimensions": {"width": 1920.00, "height": 804.375},
"anchor_point": {"x": 0.0, "y": 0.8125}
Although this is a bit of a contrived case, it illustrates that having framing decision dimensions (correctly) permitted to be non-integer implies that anchor points must also be non-integer even after processing through a canvas template.
In the new documentation page, step 5 of the template application algorithm demands: "Round all dimensions and anchors according to the template's RoundStrategy". However, I do not believe that the rounding was ever intended to be applied to 'all dimensions' since this breaks one of the most fundamental features of the FDL description.
To illustrate, suppose I used an Alexa LF open gate (4448x3096) with a spherical lens and framed for theatrical 2.39:1 such that the central 4096x1716 was the framing decision. The standard way to present this in dailies would be to map that same framed area to the central 1920.0 x 804.375 of an HD frame and allow the rest to be cropped. I believe this common dailies strategy is described with a template like:
and the resultant editorial canvas for this camera should have a framing decision with:
Notice the non-integer dimensions. If you rounded these in any way, then you would not be correctly describing the dailies process for this camera. Indeed, the spec explicitly implies that this is reason for having floating point anchors (section 7.3.4.10.5 of the 2.0.1 document):
The way I read the FDL specification, rounding should only be applied to the new canvas dimensions and only in the event that a pad or crop has not been applied (with the use of a
maximum_dimensionsvalue). See section 7.4.12 of the 1.0.2 document:And note that rounding the new canvas dimensions does not necessarily imply that the new quantities end up as integers (though they often will). Consider the same camera canvas as above but with a template that kept only the framing decision, like:
To keep the result centered, as intended, the resulting canvas should have a framing decision with:
Although this is a bit of a contrived case, it illustrates that having framing decision dimensions (correctly) permitted to be non-integer implies that anchor points must also be non-integer even after processing through a canvas template.