Our policy for scope features is to provide the client with 2 passes: one is a 2.39 image letterboxed inside a 1.78 frame (for UHD), and the other is a 4096x1716 wide image ready-to-go for theatrical. We don't charge them for it, because it's just render time. I agree that nobody should deliver a letterboxed image for DCP unless it's a non-standard size.
Aspect Ratios: imprecise precision / precise imprecision
- Thread starter Jerome Raim
- Start date
Our policy for scope features is to provide the client with 2 passes: one is a 2.39 image letterboxed inside a 1.78 frame (for UHD), and the other is a 4096x1716 wide image ready-to-go for theatrical. We don't charge them for it, because it's just render time. I agree that nobody should deliver a letterboxed image for DCP unless it's a non-standard size.
We use the Universal Studios CM-001C - Aspect Vertical Blanking Chart for all video (non DCI) deliverables. It's very complete. I have attached it to this post.
Thanks for sharing, Eric! Great stuff.
It mostly lines up with the numbers I posted. Slight deviations on the more esoteric ones (e.g 1.37 they are using 1.3700 instead of 1.375 and 2.35 they are using 2.3500 instead of 1678:715). The ratios I went with are based on the film dimensions listed here https://www.widescreenmuseum.com/widescreen/apertures.htm )
But their rounding logic matches mine (and ARRI's and Filmlight's).
In my opinion their document would be irreproachable if in addition to "aspect ratio" and "pixel ratio" they were to provide what I'm calling in my table, for lack of a better term, "precise ratio".
...Fun anecdote: in researching this topic, I found out that v1 of DCI spec went with 4096x1714 for Scope (which is in fact closer to the "true 2.39" they were attempting to match). Only in v1.1 did they decide to sacrifice the aspect ratio accuracy in order to make the 2K variant (2048x858) compatible with the 4K one: 4096x1716. This compromise very much lines up with @Andy Minuth's process of deriving from 2K/HD the 4K/UHD numbers.
~1.66 is an interesting and dangerous outlier.
Universal is using 5:3 (1.666666...:1)
ARRI is using 2048:1234 (1.659643436:1)
Both UHD and 4K Theatrical finishes will have the height be 2160 (how convenient!).
If Production uses ARRI frameline tool and those numbers are used throughout Dailies, Editorial, VFX, DI, etc., they will ultimately be pillarboxing 3584x2160.
And then Universal asks for 3600x2160, but there's no imagery left and right of the 3584 width! And so everything will need to be zoomed in slightly (cropping a bit of the DP's intended framing top and bottom).
That's why it's absolutely critical that Universal, ARRI and all the other stakeholders provide the "precise ratios" they are using, not just ambiguous shorthand.
There are actually quite a few 1.66 European films done in the 1960s and 1970s. I'm guessing I've done at least 15 or 20 of them in the last 15 years.
We generally just matte it on the sides (pillarboxing) within 16x9 and call it a day. So far, zero rejections from QC or any streaming service. No viewer has ever complained. If we had zoomed in for 1.78, you would actually be missing framing top and bottom -- it's literally hard-matted in 1.66 on the film. It's not my favorite aspect ratio, either.
BTW, I just was told about this Arri workflow document about aspect ratios (especially anamorphic squeezes), which I found interesting:
I am not saying to pan&scan to 1.78. I'm saying zoom in 3584x2160 (what the DP approved in camera) to to fill 3600x2160 as mandated by Universal.
You can't call it a day yet. How much pillar boxing?
1.660:1 = 3586x2160
5:3 = 3600x2160 (Universal)
2048:1234 = 3584x2160 (ARRI)
It looks like I'm splitting hairs (and yes, I am). But time and time again I'm seeing the imprecision of the shorthands cause confusion throughout on-set, dailies, vfx, di, distribution.
We call it a day if the client accept it and it passes QC. I can point you to at least a dozen 1.66 releases I did that were very well-reviewed on Blu-ray.com. As I like to say, "hey, I cashed the check and spent the money, so it's a moot point now."
I think we just take the default in Resolve, and nobody has complained/noticed/commented yet.
This is a nice summary Jerome.
Specifically in regard to scope aspect ratio, one thing that I have noticed over the years is that some DPs can really fixate on the difference between 2.39, 2.40, 2.35 etc. Some DPs are highly detail oriented (to say the least).
With that in mind I think it can be useful to consider that historically these ratios in anamorphic cinematography were not that precise... that doesn't mean we can't be precise now but its something to consider. Historically speaking:
1) Anamorphic lenses were quite imprecise in this respect, some were labeled 2.40, others 2.35, etc but the ground glass did not necessarily represent this precise difference, and also the lenses could vary by as much as 5% in terms of the squeeze factor (2x +/- 5%)
2) On the projection side, the lenses doing the unsqueeze were also fairly imprecise similarly varying by at least a few percent from lens to lens.
3) Not specific to anamorphic, but with all 35mm projection, of course the actual frame edge is determined not by the film print but by the projection aperture in combination with the screen masking, both of which combined can cut off up to 5% of the film image area around the edge in a way that is not always precisely controlled despite our best efforts.
Of course all the various standards from SMPTE and the academy that defined precise camera aperture and projection aperture attempted to minimize the error in the process defining precise camera aperture and projection aperture with a specific amount of image recorded onto film outside the projection aperture, but no matter what at the end of the day there was a fair amount of imprecision involved and the numbers being thrown around "2.40" and "2.35" were really not that precise, and just categorized the image as "scope" as opposed to flat and should not really be interpreted as precise enough to distinguish 2.35 from 2.39 from 2.40.
Thanks for chiming in, Nat.
I do yearn for that bit more... "room for error" that projecting film allowed/expected (with the understanding that there's always a trade-off to be found).
These oh-so-subtle differences are incidental if, for your final UHD master, you're just deciding what that letterbox or pillarbox mask is going to be. I feel this attitude can work well on lower budget projects or documentaries where the aspect ratio(s) can be played with in post.
But all it takes is for a single "highly detail oriented" person (DP, DIT, Editor, AE, VFX supervisor, etc.,) to call out the subtlest of mismatches for the entire production to question the robustness of the pipeline and whether creative intent is being preserved.
For the scope formats, bottom line for me is:
- If there's a theatrical component to delivery, it needs to be 1024:429. If the client pushes back, we get in writing that they understand cropping or boxing will be needed.
- If it's streaming/broadcast only, I recommend 1024:429 (for DCI compatibility) but do not push back too much.
Bit late to the party - definitely a jungle out there in terms of understanding principles and accurately using definitions and numbers.
I found the Netflix calculator pretty robust and helpful in most of real life scenarios, including those described in this thread:
tinyurl.com
cheers, BG
I found the Netflix calculator pretty robust and helpful in most of real life scenarios, including those described in this thread:
Production Technology Tools
Tools made for Netflix Productions. Calculate the Framing Resolution and Working Resolution of your Camera Setup, and check if it is compatible with Netflix UHD.
cheers, BG
Thanks @Bogdan Grigorescu. It is pretty good. I still wish the precise ratios would be shown. I do appreciate that they say upfront:
"Be aware:All pixel counts are rounded up to even numbers."
But the round up to even (as opposed to round to nearest even) will cause issues (in real life scenarios).
Example:
2.39 show. Using ALEXA Mini LF 2.39:1
If you take the (correctly calculated) 4430x1856 active area at source resolution (2.3868534483) and fit it inside UHD, that's a 0.8668171557562077 scale factor, resulting in 3840x1608.813.
But the calculator says 2.39 in UHD is 3840x1610 (2.3850931677) (and not what most studios agree is 3840x1608). There's not enough imagery top and bottom! You'd need to punch in ever so slightly (cropping left/right).
This type of problem could be mitigated if Production agreed to always shoot with just a tiny bit of lookaround/extraction. In that case, rather than needing to punch in, you could simply mask/blank a few less pixels top and bottom.
tl;dr:
- rounding up to even instead of rounding to nearest even will cause compounding precision loss
- the calculator would benefit from also showing precise aspect ratio numbers
"Be aware:All pixel counts are rounded up to even numbers."
But the round up to even (as opposed to round to nearest even) will cause issues (in real life scenarios).
Example:
2.39 show. Using ALEXA Mini LF 2.39:1
If you take the (correctly calculated) 4430x1856 active area at source resolution (2.3868534483) and fit it inside UHD, that's a 0.8668171557562077 scale factor, resulting in 3840x1608.813.
But the calculator says 2.39 in UHD is 3840x1610 (2.3850931677) (and not what most studios agree is 3840x1608). There's not enough imagery top and bottom! You'd need to punch in ever so slightly (cropping left/right).
This type of problem could be mitigated if Production agreed to always shoot with just a tiny bit of lookaround/extraction. In that case, rather than needing to punch in, you could simply mask/blank a few less pixels top and bottom.
tl;dr:
- rounding up to even instead of rounding to nearest even will cause compounding precision loss
- the calculator would benefit from also showing precise aspect ratio numbers
I found Netflix's backing document for the calculator clear and detailed - shows the considerations they take into account when determining the 'working resolution'
partnerhelp.netflixstudios.com
It does mention rounding up to 'nearest even'
)
cheers, BG
Working Resolution: Considerations & Best Practices
Skip to Translations INTRODUCTION In this article, we take an in-depth look at the concept of a working resolution and outline best practices for image scaling throughout the production lifecycl...
It does mention rounding up to 'nearest even'
)cheers, BG
Respectfully disagree on this...
It seems to me that we agree that its best practice to place 2:1 for theatrical inside a DCI FLAT 1.85:1 container (3996 x 2160) so we are just discussing how much black masking "letterbox" is baked into the DCP and DCDM. We are only talking about a difference of a single line of pixels on the top and bottom, but why not mask to the actual 2:1 edge namely 3996x1998? I understand that it's nice for the resolution to be divisible by 4, but in this case if your content is precisely 2:1 then by including that extra line of resolution at the top and bottom if you fill to fit actual 2:1 content into that container you will have a single line of black pixels on the top and bottom. Seems to me not good.
Last edited:
Hi Nat,
of course one can make a 4K DCP with 3996x1998, maintaining the exact 2:1 aspect ratio.
The argument for using 3996x2000 instead is that if someone takes that DCDM/DCP and creates a 2K version from it, it would result in 1998x999, leaving us with uneven letterboxes at the top/bottom. This is not the end of the world, but adding one line at the top/bottom does not change the creative framing of the DP.
Both options are valid, and I can understand if someone prioritises maintaining the exact aspect ratio; one has to pick one (small) poison.
of course one can make a 4K DCP with 3996x1998, maintaining the exact 2:1 aspect ratio.
The argument for using 3996x2000 instead is that if someone takes that DCDM/DCP and creates a 2K version from it, it would result in 1998x999, leaving us with uneven letterboxes at the top/bottom. This is not the end of the world, but adding one line at the top/bottom does not change the creative framing of the DP.
Both options are valid, and I can understand if someone prioritises maintaining the exact aspect ratio; one has to pick one (small) poison.
Right, I see your point about wanting to avoid 1998x999 at 2K.
Hi All,
This post has been a long time coming. Jerome emailed me many months ago when posting this thread to get my take on the discussion here. As a result of those discussions I ended up redoing the cheat sheets to be more format based where the container size is fixed and aspect ratios are assumed to need to fit within those.
Additionally, I also built an aspect ratio tool that allows a user to select the format, aspect ratio and how the sizing operation works. By default, the tool opts to fit the selected aspect ratio inside the container size, but this can be adjusted to only consider the height or width constraint. Those use cases may be less common, but could be important for DITs or those doing less common framing operations.
The tool lists the exact fraction that is being used for calculations as well as giving the decimal approximation. For example Scope 2.39 is calculated at 2048/858 = 2.38695. The actual fraction is used for mathematical calculations on the backend to maintain accuracy and eliminate rounding errors.
For aspect ratios that don't downscale neatly, resolutions are rounded down to the nearest even integers. This avoids partial pixels and maximizes compatibility for video encoding - especially for interlaced formats.
Lastly, for users that need framing masks, I added a PNG frame generator to the tool that will generate a PNG at the selected resolution with an alpha channel for letterboxed or pillarboxed frame sizes.
Hopefully this proves to be a useful resource!
The latest version can always be accessed at: https://www.unravel.com.au/aspect-ratio-cheat-sheet
This post has been a long time coming. Jerome emailed me many months ago when posting this thread to get my take on the discussion here. As a result of those discussions I ended up redoing the cheat sheets to be more format based where the container size is fixed and aspect ratios are assumed to need to fit within those.
Additionally, I also built an aspect ratio tool that allows a user to select the format, aspect ratio and how the sizing operation works. By default, the tool opts to fit the selected aspect ratio inside the container size, but this can be adjusted to only consider the height or width constraint. Those use cases may be less common, but could be important for DITs or those doing less common framing operations.
The tool lists the exact fraction that is being used for calculations as well as giving the decimal approximation. For example Scope 2.39 is calculated at 2048/858 = 2.38695. The actual fraction is used for mathematical calculations on the backend to maintain accuracy and eliminate rounding errors.
For aspect ratios that don't downscale neatly, resolutions are rounded down to the nearest even integers. This avoids partial pixels and maximizes compatibility for video encoding - especially for interlaced formats.
Lastly, for users that need framing masks, I added a PNG frame generator to the tool that will generate a PNG at the selected resolution with an alpha channel for letterboxed or pillarboxed frame sizes.
Hopefully this proves to be a useful resource!
The latest version can always be accessed at: https://www.unravel.com.au/aspect-ratio-cheat-sheet
If our clients tell us, "we need a theatrical 2.39 scope format for DCP," then we create a 4096x1716 file, label it as Rec709 Gamma 2.4, and let the DCP company handle the conversion. We always, always have a conversation with the DCP company an dask to see written specs first.
If it's for home video/streaming, it's always a 3840x1608 letterbox inside a 3840x2160 container. No rejects, no phone calls, no angry emails "so far." But again, get it in writing and double- or triple-check it to be sure. The only QC rejection we've gotten in 3 years was "missing foley on M&E track," which had nothing to do with us.
Thank you to @Brad Allen for weighing in on this thread.
