Find attached a 2.0 FDL which exemplifies a very common framing requirement and the way I expect a canvas-minting tool to behave. Here is the scenario:
The production is 1.85:1 standard theatrical, which will release in 2k as 1998x1080. My finishing timeline carries a little vertical safety, being 1996x1124 with the central 1998x1080 framed for final delivery. My dailies timeline is HD with the central 1920x1037.84 representing the same final 1.85 area.
All camera canvases should be assumed to have gone through the "Editorial" canvas template for dailies, and all should be put through the "DI" canvas template to build the finishing timeline. If all canvases have a 1.85:1 framing decision defined then the fit_all method in the DI template is redundant since any fitting method should give you the same result, but the Editorial canvas template needs to fit width because there is no way, in the current FDL standard(s), to specify an exact 1.85 target_dimension value (since these are restricted to integers).
Most cameras will have a 1.85 clearly defined within their canvas, but there is one camera source, which I've called "Security Cam", which has size 640x480 (i.e. 4:3 aspect) and the filmmaker's intention is for the entire canvas to be fit into the height of the 1.85 frame, leaving black pillarboxing. A straightforward way to process this correctly with FDL 2.0 is to use a virtual frame that encompasses an area larger than the canvas itself, as shown in the attached FDL. The usual math for scale and positioning the frame in the targets will work naturally with these values to produce the desired results, as shown with the minted canvases in the attached FDL. Crucially, this works for both the Editorial and DI templates.
However, FDL 2.0.1 now forbids negative anchors, so we'd have to change the camera's canvas framing_decisions.dimensions to {"width":640,"height":480} and its anchor point to zero. By virtue of the fit_all method of the "DI" template, this still works for my finishing output, but the dailies will be way off correct as it will scale by 1920/640 (since it uses width). With no way of defining the correct target height in the canvas (due to the integer restriction of the target_dimensions), even changing the mode to fit_all or height, cannot result in the correct scale of 1920/888 no matter what values we use.
You could say that the way to fix this is to allow for floating point target_dimensions, and certainly I have been advocating this for a while. We could then also use a fit_all approach in the Editorial canvas. But I would suggest that also allowing negative anchors to define a virtual frame that exceeds the canvas dimensions is a handy logical description of this scenario since the intention is to retain the extra-canvas black in the intended framing, so I think we should revert to not restricting the anchor to positive values.
Pillarbox_185_Demo.fdl.json
Find attached a 2.0 FDL which exemplifies a very common framing requirement and the way I expect a canvas-minting tool to behave. Here is the scenario:
The production is 1.85:1 standard theatrical, which will release in 2k as 1998x1080. My finishing timeline carries a little vertical safety, being 1996x1124 with the central 1998x1080 framed for final delivery. My dailies timeline is HD with the central 1920x1037.84 representing the same final 1.85 area.
All camera canvases should be assumed to have gone through the "Editorial" canvas template for dailies, and all should be put through the "DI" canvas template to build the finishing timeline. If all canvases have a 1.85:1 framing decision defined then the
fit_allmethod in the DI template is redundant since any fitting method should give you the same result, but the Editorial canvas template needs to fitwidthbecause there is no way, in the current FDL standard(s), to specify an exact 1.85 target_dimension value (since these are restricted to integers).Most cameras will have a 1.85 clearly defined within their canvas, but there is one camera source, which I've called "Security Cam", which has size 640x480 (i.e. 4:3 aspect) and the filmmaker's intention is for the entire canvas to be fit into the height of the 1.85 frame, leaving black pillarboxing. A straightforward way to process this correctly with FDL 2.0 is to use a virtual frame that encompasses an area larger than the canvas itself, as shown in the attached FDL. The usual math for scale and positioning the frame in the targets will work naturally with these values to produce the desired results, as shown with the minted canvases in the attached FDL. Crucially, this works for both the Editorial and DI templates.
However, FDL 2.0.1 now forbids negative anchors, so we'd have to change the camera's canvas
framing_decisions.dimensionsto{"width":640,"height":480}and its anchor point to zero. By virtue of thefit_allmethod of the "DI" template, this still works for my finishing output, but the dailies will be way off correct as it will scale by 1920/640 (since it uses width). With no way of defining the correct target height in the canvas (due to the integer restriction of thetarget_dimensions), even changing the mode tofit_allorheight, cannot result in the correct scale of 1920/888 no matter what values we use.You could say that the way to fix this is to allow for floating point
target_dimensions, and certainly I have been advocating this for a while. We could then also use afit_allapproach in the Editorial canvas. But I would suggest that also allowing negative anchors to define a virtual frame that exceeds the canvas dimensions is a handy logical description of this scenario since the intention is to retain the extra-canvas black in the intended framing, so I think we should revert to not restricting the anchor to positive values.Pillarbox_185_Demo.fdl.json