Christie Chan Config (Source Files Clarity?)

[Ryan Gallagher]

Perhaps someone can clarify for me as to when it, if at all, it would be justified to use or create a source file that deviates from the standard square pixel flat/scope/HD/custom or has an specified aspect ratio that differs from the signal aspect ratio and grid specified?

Our 2k CP2220 has a ton of differing grid size source files populated, either from factory or from past users. Most of which seem completely irrelevant when running 2K F/S/Custom DCPs or 1080p alt content.

Separately, the source file setup has that tickbox for "Letterboxed", and lets you specify an intended aspect ratio (that may differ from the pixel grid that is entered), but the naming of that feature seems problematic cause it seems to have the capacity be relevant to pillar-boxing too? I assume if you don't want any pixel stretching or squishing you always set the source aspect to match the signal pixel grid you entered, unless you are doing some offset perhaps.

Is my understanding correct that when the grid ratio (after any offsets) and the "specified" source aspect ratios match, that is what is considered "square pixels". And if they are mis-matched in any way effectively you are manipulating the pixels to non-square (an expression, but that is the terminology in use).

Is the source aspect ratio setting (flat/scope/or manually entered) intended as a channel tool to allow you to stretch one source into a different aspect ratio than it's signal has? If that is not the intent why would you ever enter an mis-matched ratio? Is it just there because if you were to use the offset feature, but wanted to maintain an original intended aspect, you have to tell it what that is so it can stretch to fill it?

There are also a ton of 4K source files, presumably because the CP2220 had a 4K upgrade path or compatibility to read 4K signals... as a 2K house with no 4K signal sources at this time... those are, i assume, completely irrelevant to us?

We do often take the shortcut in DCPomatic of using non-standard DCP containers such as 166 or 138 when generating preshow content (I know this won't work on every projector out there), but we use those with the standard flat source files and it behaves as expected. Perhaps it has an impact on where other values "start" such as the screen file corners, or scaling corners, if you were to tell it an exact grid to match whatever container you were playing? In fact i'm not even 100% sure one can think of the "container" and the "signal" resolution as interchangeable here.

I'm relatively comfortable within most of the other channel settings, but Source File has always been slightly confusing given those extra options and coming from a non DCI background, and the manual does not illuminate the intent much other than to say that the source file dimensions should always match the incoming signal.

Perhaps if we were using sources that needed the offset feature, or other resolution/ratio ALT sources on the regular this would become more obvious, but as it is set up, all our non-blu-ray ALT sources go through a decimator MD-HX that somewhat imposes the preferred EDID and always translates to 1080p60 at the PIB board DVI input. So really we only find ourselves needing the Flat, Scope, Custom, and HD square pixel source files.

The letterbox tickbox was at the root of why our DCI 166 channel was not quite correct for eons. Used to never be able to see the edges of a 166 test pattern until I started digging a little deeper a while ago. I didn't even know the Netflix 166 chart had border lines for a while when I was learning. *facepalm* Luckily 166 is a pretty rare format these days.

[Ryan Gallagher]

In hindsight, perhaps i'm mis-understanding a fundamental behavior and standard practice.

If "signal" relative to the source files is really just talking about the active pixel area. I could see spawning a bunch of source files for each aspect ratio as appears to have been done on and off. Presumably this is telling the projector only to "process" that area of the signal. Rather than process the blacks too when letter/pillar/window boxing is present.

This would perhaps explain the letterbox checkbox a little. If the projector's default behavior is to scale a source to the max vertical or horizontal of the native raster (and/or the aspect ratio that you inputted)... if you have given it an undersized source file, you would have to tell it if your preference is to not scale it (IE keep the "letterboxing", which can in fact be letter, pillar, or window behavior).

That said we aren't using that approach, we just use the full flat, scope, or HD source file relative to the containers of the signals, regardless of what image area is active within it, and combined with zoom/screen/ILS, size the active area to the masked area of the screen.

Maybe on fixed height/width/ratio screens, or installs without zoom motors/operators, it makes more sense to have all the individual source files configured per active pixel area of each source aspect ratio so that the projector can use the available raster to upscale to the screen area when needed?

Our DVD player is basically retired, but maybe experimenting with a source below 1080p will make it all make more sense.

[Sean McKinnon]

Where you have the periscope system and thinking that Michael Schaffer (RIP) may have set that machine up originally it is possible he was "resizing" on the chip to avoid moving the lens but I cant guarantee that was the case.

[Ryan Gallagher]

Where you have the periscope system and thinking that Michael Schaffer (RIP) may have set that machine up originally it is possible he was "resizing" on the chip to avoid moving the lens but I cant guarantee that was the case.

interesting thought. I had contemplated if one could force enter a non matching non standard aspect ratio at the source file level to effectively reduce vertical stretch.

i imagine this can be done with the corners on the screen file scaling though, and a better home for such a tweak. But have not tried. We run square pixels right now but still vertically stretched due to booth angle of course (even with the periscope).

Another clue perhaps is that our old (maybe original?) flat settings and masking marks had a pretty significant top crop. I always assumed it was a compromise to use as much width as possible considering the arched proscenium. But I could see maybe a stretch corrected flat fitting in that opening. Though scope gets stretched too, and no equivalent setup anomalies there.

I eventually got sick of intentionally letterboxed edits not having equal matting above and below and re-did the flat sizing/masking to full height, but perhaps a tad narrower than the old flat. But perhaps the missing ingredient was actually some additional compensation for vertical stretch.

[Carsten Kurz]

There was a time when some material was shown live over SDI connections from analog or digital tape recorders, or needed to be converted from video sources. Often these sources had no clean borders. There were head switching artifacts, time-code fragments in top or bottom lines, etc. For these sources, you wanted to blank these signal components out so you could show them full screen without these image artifacts. Some of the series 2 channel setup parameters have a background that may be considered historical now.

[Ryan Gallagher]

There was a time when some material was shown live over SDI connections from analog or digital tape recorders, or needed to be converted from video sources. Often these sources had no clean borders. There were head switching artifacts, time-code fragments in top or bottom lines, etc. For these sources, you wanted to blank these signal components out so you could show them full screen without these image artifacts. Some of the series 2 channel setup parameters have a background that may be considered historical now.

Yeah that was my impression relative to the offset features (and possibly the re-telling it an intended aspect ratio following an offset change). I'm old enough to remember scan line issues at the bottoms of frames etc. ;-)

I guess my fundamental "practice" question remains. For non-standard resolutions and aspects would you typically specify the active pixel area and aspect in the source file? Or leave that all configured referencing the signal container and let the black matting get processed etc. From my level of experience I can only see a benefit to doing the more specific route when the signal active area falls short of maximizing native projector raster on one axis or the other. Allowing the projector to then scale it to the raster if you don't tick the "letterboxed" option. (assuming I'm understanding the intent of that tickbox).