It appears that the titling for the individual windows is being generated from the pixel dimensions of the source video and is not being scaled to a uniform size as is the video for each of the windows.

Image #5 is pixelated. Idea: Perhaps the numeral is overlaid on a thumbnail before the image is stretched to fit the display area. Those thumbnails seem to have different resolutions, unrelated to the relative resolutions of your takes.

The pixelated image I believe has to do with a really poor proxy render of that 4K source. When I switch to "good" model the video image looks proper, but something unexpected happens with the take numbers. (I'll post outside this reply with that)

So here's a related fun finding. When I change my video dock output quality from "Preview" (it'll use the proxies I built for those three cameras/takes) to "Good" (using the original media), the take-overlay size changes too! I think you're onto something John.

Note here when output is set to "good", cameras 4 and 6 now have tiny tiny labels, and take 5 has a medium-sized label, smaller than takes 1-3. Related to source size probably, but not necessarily directly correlated.

Cams 1-3 - 1080p
Cams 4, 6 - 2K
Cam 5 - 4K
 

Also strange/undesirable -- the proxy files are all 720p 24fps, despite my project being 30fps. proxy frame rate should really match project frame rate IMO, and that 720p scaled image is really quite horrible on camera 5 when the proxy is being used (Preview quality)

In my original post image above (preview/proxies) -- it seems the label-scaling bug seems a bit more complicated. Related to the original source media size AND proxy. So it scaled it down based on higher resolution, but then back up because the proxy was now 720p and was scaled... maybe?

Perhaps this is intentional behavior to help identify different sized source media, and not a bug?

"the proxy files are all 720p 24fps"

The proxies used for editing aren't 24 fps. You are mislead by reading the proxy files properties. But the Vegas Pro internal proxy workflow works differently. It takes the proxy file video stream and reads its size and at the same time it takes the source file's metadata, reads its frame rate and apply this metadata frame rate onto the proxy used for editing.
So while using the regular proxy workflow, the frame rate of the proxies used for editing will always match the source frame rate.
Thus the advice given since this proxy workflow was introduced is: Never touch the proxy files, just use the workflow in the given way.

"the proxy files are all 720p 24fps"

The proxies used for editing aren't 24 fps. You are mislead by reading the proxy files properties.

Using MediaInfo looking at the proxy file (.sfvp0 files), it reports it as 720p, 16:9, 23.976 fps.

Playing it in VLC, it reports the stream is MPEG-1/2 (mpgv), 720p, 23.976024 fps.

The tools are all reporting it as 24fps to me. Why do you say it isn't?

But the Vegas Pro internal proxy workflow works differently. It takes the proxy file video stream and reads its size and at the same time it takes the source file's metadata, reads its frame rate and apply this metadata frame rate onto the proxy used for editing.

OK. So you're saying it generates the proxy file however it is (e.g. 24fps), and then is using the source file's frame rate for preview playback, ya? In that case, those proxies are still physically 24fps. Looking at the internal system settings, it looks like it uses the GUI for a single render format to choose the proxy format when doing the proxy render.

So while using the regular proxy workflow, the frame rate of the proxies used for editing will always match the source frame rate.
Thus the advice given since this proxy workflow was introduced is: Never touch the proxy files, just use the workflow in the given way.

not sure what you mean by "never touch the proxy files". why would anyone manipulate them anyway? I'm not touching them -- just created them for my 2K and 4K media so it edits faster, and discovered these two issues.

1. my 4k camera's proxy footage looks horrible (2k proxy footage looks fine, as does the 4k source media)

2. the take #'s are sizing differently based on proxy vs non-proxy and size of resolution

You "touched" the proxy files to let MediaInfo analyze them which then leads to a false conclusion (because Media Info (of course) reads the proxy file metadata while Vegas Pro will read the source file meta data).

For the Vegas Pro internal proxy workflow it does not matter which frame rate the proxy file is because the proxy workflow just don't use this frame rate. It reads single frames out of the proxy stream then uses the source file frame rate (by reading the source file metadata).
The Vegas Pro proxy workflow is similar to how image sequences work: Reading single frames then putting together a new clip where the frame rate is newly generated by this very project.

If it would be else using the proxy workflow with source video frame rates other than 24 fps would either result in the clips being shorter or longer, or frames being skipped or doubled. None of this is the case because within the proxy workflow the frame rate will always be adopted.

The size of the take # (for all takes except the 4K proxy on take/cam #5) changes when I change from "Preview (Auto)" to "Preview (Full)". As I understand it, whether in "auto" or "full" should not alter whether or not it's using the proxy vs original source file, and accordingly, I don't see why this should impact the size of that take # overlay.

AUTO

FULL

You "touched" the proxy files to let MediaInfo analyze them which then leads to a false conclusion. For the Vegas Pro internal proxy workflow it does not matter which frame rate the proxy file is because the proxy workflow just don't use this frame rate. It reads single frames out of the proxy stream then uses the source file frame rate.
The Vegas Pro proxy workflow is similar to how image sequences work: Reading single frames then putting together a new clip where the frame rate is newly generated by this very project.

Sure.. makes sense. Honestly it doesn't matter to me what frame rate the proxy files are built at from a tech standpoint since that won't impact final render.. only care if it adversely affects the image so badly that it's hard to use when editing. The 24fps seems fine for my 2K footage on cameras 4 and 6, looks horrible in my proxy 4K footage in cam 5 -- was just trying to figure out why it scaled/converted so poorly. I may just delete this proxy file on cam 5 and manually render a proxy for that one and remember to swap it back when the edit is done.

Anyhow -- original issue still stands -- tha take # labels seem to jump in size for reasons that aren't evident.

The bad look probably is from proxy files are always 1280 x 720. So they are downscaled from your 2k and 4k footage to build the proxy files and then upscaled to the project properties again and downsized again for the multicam view while being used with "Preview" quality setting.

I've generated my own 720p MPEG2 version of the 4K file and swapped it for the original after deleting Vegas-generated proxy. My 720p file also then is upscaled to the project propertis and then downsized again for the multicam -- and it looks perfectly clear so we can edit with it, just like the other multi-cam scaled images.

The only problem is the quality of the 4K proxies that are built by Vegas -- completely blurry and un-usable.

New project -- same problem. Here are two images.

6-up view. Note the blurry image quality of C5 (the middle cam) -- this is my 4K footage, displaying the proxy file because it's in "preview" quality.

6-up view. This is after deleting the proxy file on C5, and telling Vegas to use my own 720p MPEG2 file I generated from the 4K source using FFMPEG. Note how crisp and sharp the middle camera is

I understand your problem.  I also go through it.

Why don't you create a 1080p Intermediate just for the 4K camera? This way the display in the Preview will be the same as that of cameras 1-3 that are already 1080p. The rendering time for creating an intermediate file is about the same as for creating a proxy file. The advantage is that the intermediate file can be used in the final rendering if the output resolution is the same.