@Yelandkeil

I fancy - it's only a fancy - isn't your investigation with 350x284 dimension too big?
For an immediate realization/standardization of 444 sub-sampling, it would be 2x1 - not pixel but quantum?

Apologies, I'm not sure I follow. Do you mean is the 350x284 dimension too small for Vegas to properly render?

For an immediate realization/standardization of 444 sub-sampling, it would be 2x1 - not pixel but quantum?

Could you explain more what you mean? I understand that 4:2:0 is is used to save some memory/bandwidth, and it's served its purpose well for that over the years. But I think having 4:4:4 is such a game changer for certain images/videos, that it's an even bigger priority than 4k, considering I think it's only 20-50% larger in size compared to 4:2:0. However I love 60fps and 120fps, and I think that's been a long time coming! Youtube was stuck at 30fps for goodness knows how long.

I meant the format it's in now. Older formats are irrelevant....

It is a nice wish if things would only work that way.

The truth is, the native bit depth and byte chunks do not change, they are not alchemized or synthesized to a higher color space; it only has a new name placed on it, so it is now an alleged 18 bit AGA impersonating a 24 bit PNG.

All this actually accomplishes is to "add air" to the wrapper; the popular expression is "putting mascara on a pig," my grandfather often said, "you can't make a silk purse from a sow's ear."

Above are structured graphical tests I made over a decade ago to illustrate just this behavior. Unfortunately, a lot of folks don't get it, because it is so natural to think the native bits have somehow been "transformed" to fill their new namespace. That is why it causing you trouble, because the decoder only sees the new flags and has no idea where your pictures started life. I've specialized in these rescues for clients over a very long time, and even with 50 years of work and study in the film and graphics industry, my success rate in "unbaking the cake" is only about one out of ten in these cases. My hope is that you will beat the odds and find a solution you can work with; it is in that spirit that I wish you the very best of luck.

Do let us know what you are able to come up with: the CG Panel gives you fine control over luminance and chroma, with time you may be able to write a custom LUT that will come close for your individual assets.

Just a note: you cannot rescale the Belle-Nuit chart and expect to retain the chroma subsampling test integrity. That is by definition. Also, never, ever expect an exact color match from 4:4:4 RGB to 4:2:0 Y'cBcR. That was my point when I pointed you to the chart. 4:4:4 RGB video is essentially undeliverable.

8 bit 4:4:4 Lossless RGB

8 bit 4:2:0 "Lossless" Y'cBcR (Sony YUV)

so this has to be a Vegas/codec bug, and not really to do with unmanaged colour for importing images.

I strongly encourage you to test that hypothesis by employing other software solutions, and you may get lucky!

@Musicvid

Just a note: you cannot rescale the Belle-Nuit chart and expect to retain the chroma subsampling test integrity. That is by definition

Of course I concur that would ruin the chroma subsampling test, but that wasn't the parts of the test chart I was testing or having issues with. It was the solid block colours (yellow, cyan, red etc.) that were changing. I even truncated / chopped the image to 350 x 350 instead of resizing it, and the problem still occurred when rendering through MainConcept H264. The problem didn't occur when the image was at 1920x1080, only when at 350x350.

The truth is, the native bit depth and byte chunks do not change, they are not alchemized or synthesized to a higher color space; it only has a new name placed on it, so it is now an alleged 18 bit AGA impersonating a 24 bit PNG.

The PNG may have poor colour resolution by not utilizing all 256 shades, but the colours match the original PNG if I resize the image to full 1920x1080 when I stretch it. And then if I restretch again back to the original size, and rerender, the colours are broken again. I made sure the "Project properties" resolution matched the image size in each case (and not forgetting the codec resolution settings too).

Vegas MainConcept H264 isn't just getting it wrong, it's being inconsistent too. Do you agree with that?

I'm impressed you knew about HAM8 to that level of detail, but I would still maintain there's nothing particularly special or franken about the lossless 3D tube PNG. I saved it out as a BMP file (which Vegas also had trouble with) and inspected the bytes via a hex editor. This is what I found:

The first pixel (bottom left) values match the corresponding bytes shown in the hex editor in red (I checked another colour pixel further along). It is all how I expected it to be. Each byte is a value from 0-255, one for blue, one for green, and one for red, making up 3 channels per pixel. It can't get simpler than that (unless there's some weird stuff going on in the BMP header, which I could strip anyway?). For what it's worth, the image was recreated fresh again recently (for the stereoscopic effect) when I used the C++ library, and literally coded every single pixel from scratch myself with RGB values from 0-255. It even added a brand new header. It's a completely new PNG, just with the RGB 0-255 values copied from the old picture.

Also, never, ever expect an exact color match from 4:4:4 RGB to 4:2:0 Y'cBcR. That was my point when I pointed you to the chart. 4:4:4 RGB video is essentially undeliverable.

That would seem as though it could be the problem, except once again, at higher resolutions (1920x1080) for both the images I've been testing (my 3D tube and your test chart), the colours match perfectly.

@RogerS

Looks like the Voukoder crew are already on the case. As far as I can see, someone has already reproduced the problem I've been having with Voukoder output from Vegas.

In the meantime, do you know of any decent Voukoder alternatives which allow great H264 output from Vegas? Just H264 (with 4:4:4 no less!), and maybe APNG (animated PNG) would be ideal for all my codec needs.

Actually... that was me on the Voukoder forum. Can you copy what I did and see if you are happy with the output?
I don't totally trust their presets as they are user-generated so maybe this will prompt Vouk to either fix the preset or bug that is resulting in different output for 4:4:4.

For alternatives, never used it but maybe Happy Otter Scripts? https://tools4vegas.com/home/

Or output ProRes from Vegas and then use your favorite tool to go to h264?

Vegas MainConcept H264 isn't just getting it wrong, it's being inconsistent too. Do you agree with that?

I've contributed all I wish to; I'm not willing to conduct the comparative tests necessary to assign the inconsistencies exclusively to Vegas and / or Mainconcept, as you have proposed. I have no basis to draw such a conclusion. My impressions, only on the basis of experience, are the opposite; I think it's your rewrapped source.

The reading I have done suggests that a multiplanar algorithm, not an x-y matrix, would be necessary to do what you want with any measure of consistency; I have already suggested contriving a specific-case 3D LUT for your current project (only). With that, I respectfully wish you the best of outcomes.

Just H264 (with 4:4:4 no less!), ...would be ideal for all my codec needs.

Yes, a Hi444PP AVC Profile exists. How are you planning to deliver it?

@Musicvid

My impressions, only on the basis of experience, are the opposite; I think it's your rewrapped source.

I saw the same inconsistency happen with your test chart too, but no worries. As a springboard then for my further research based on what you've said then, I have one final small question:

Once I reconvert the PNG to BMP, is the enduring 'franken'-ness aspect of my 3D tube image in the header(s) of the (24 bit BMP) file, or in its (chunky, 0-255 RGB) pixel array data?

Yes, a Hi444PP AVC Profile exists. How are you planning to deliver it?

At this rate, not Youtube haha. I'll probably just upload the MP4 directly to my own site to allow for 4:4:4 (since 420 plays havoc with the stereoscopic/anaglyph effect). Thanks for the Hi444PP recommendation!

@RogerS

Actually... that was me on the Voukoder forum

Ah twas you! Thanks for helping reproduce the problem I was having with Voukoder. I've just replied to you, but awaiting approval as comments need moderation. You'll be pleased to hear I can verify your own experiences almost exactly, including the nightmarish template issue.

Thanks for the recommendation on the Happy Otter Script. I'll give that a go along with Hi444PP.

Or output ProRes from Vegas and then use your favorite tool to go to h264?

Ah so ProRes is an intermediate codec - a half way house to lossless. I've been reading a bit about those lately, and if ffmpeg can read and convert those, that could be ideal!

Not sure if lossless is a destination- it's pretty impractical for most video which is why intermediate codecs exist. Vegas reads and writes it natively and it does up to 444 with alpha (if space/data rate is no limit).

Pretty sure it can read ProRes as ffmpeg can write flavors of it.

@RogerS

Pretty sure it can read ProRes as ffmpeg can write flavors of it.

Unfortunately, I just found out that Vegas' in built ProRes codex only allows resolutions 720x480 or above. Vokouder does a better job in that respect, allowing any resolution. No idea why they need to arbitrarily limit it like that.

While we wait for a resolution with Vokouder (did you find his latest connector to fix the colour issue?), here's the end product you asked for! I 'cheated' a bit by not using Vegas, instead relying on ffmpeg's frame to video feature. Would have preferred to do it all in Vegas, but ffmpeg works perfectly (no colour distortion!).

You'll need 3D anaglyph glasses (preferably red/cyan) to appreciate the full effect:

https://www.skytopia.com/stuff/TubeRunQ10.mp4

Make sure to see it full screen!