Container window

[revisionfx]

Just to supplement Dave Stump doc notes

1. One thing we considered not a thing in ASC-FDL is the extra window camera records.
   Variation on that theme:
   A. the typically 2 extra photosites each side of the image to allow the edge pixels to be properly debayered
   B. for example Arri with some ProRes output needs to produce pixels that fit their internal processor, so if you look at the Arri format chart you will see they have an extra container window to address that.
   C. Some applications have hard coded supported resolution (or said another way fit everything in a specific project size - that can be letterbox and pillar)
   D. some real-time system as they run with a couple of frames delay use overscan (larger image) to make sure that by the time the virtual camera image has not edge gaps

2. Also, I could note for clarification
   You can with Red Monstro record full sensor but output 2K ProRes (4x4 sub-sampling).
   Framelines (and ROI in industrial camera) are usually set in sensor space.
   Physical dimension units (CAD) are typically measuring the 4 corners like putting a vertex at each corner while many 3D renderers have shifted now (used not to be like that) to center of pixel model resulting into a 1/width scaling difference. Variations on that theme includes one person in the FDL sessions noting that a camera vendor supporting extracting lower-resolution (I guess working in proxy mode) can offset the image... and variations on that theme. As I did a fair amount of projection mapping in my life, we ended up here with supporting (enum candidate) 3 basic way to match a particular renderer to texture. Just saying as being 0.5 off in such mapping is loosing a lot of resolution and when doing inverse UV / ST mapping as the destination can project the source over multiple pixels easy to be disaligned. Will return to this topic on comment about distortion mapping.

3. Also the SMPTE references are behind a paywall for me