Resizing on render alters colors

[Adam Sandler]

I came up with interesting results
sony’s avc codec does good with source resolution, poorly with non source, and medium with level FX on non source resolution.
Mainconcept avc codec does poorly with source and non source resolution, but good on both with the same level FX adjustments, and takes up to 10 times longer to render final video.
I made compaction on picture. bad position adjustment made deliberately to make difference more visible.

How to do things without dancing around?

[Graham Bernard]

[Adam Sandler] “How to do things without dancing around?”

Adam, I have to say, you’ve produced some of the best, if not THE best analytical, evidenced-based results on this Forum for many a long year.Well done and thank you for your effort.

* Grazie

Video Content Creator and Potter
PC 7 64-bit 16gb * Intel® Core™i7-2600k Quad Core 3.40GHz * 2GB NVIDIA GEFORCE GTX 560 Ti
Cameras: Canon XF300 + PowerShot SX50HS Bridge

[László Kovács]

Without being completely sure (as you use a pixel format I never do), for your problem I would blame the black you added around the original video.
If you encode to an mpeg-like codec, there are the “legal” levels (16-235), which don’t make problem.
When the levels are outside of this range (say they are “illegal”), the encoder may produce wrong results, which also may fool the decoder later – how wrong it is, depends on the encoder itself, I think.
So simple said, codecs, like wmv or lagarith expect computer RGB range (0..255), while mpeg-like codecs used in video industry expect studio RGB range (16..235).
So if you added that black as RGB (0,0,0) be it better RGB (16,16,16).
OR, alternatively add the levels FX to the video output with the preset ‘computer rgb to studio’.
(If you do this, remember to add the reverse of the same effect to your source media: levels (studio-to-computer), otherwise the colors and the contrast of the source will look a bit washed out)
Again, I mean this with 8bit pixelformat.

I also noticed, that Mainconcept AVC encodes way much faster if there’s no “illegal” level on its input.

Best regards

László Kovács

[Marco Baer]

“Imported mp4 file that vegas did on his own(with it’s own codecs), rendered 1280×694 file which is correct copy of source file. Rendered with sony avc internet template …”

I tried same now (in an 8 bit project because using 32 bit floating point full level linear doesn’t make too much sense here). I ran the test twice, one time with Vegas Pro 13, one time with Vegas Pro 14. One time cropped and zoomed to adjust source media, one time untouched – with black bars.
But in none of the cases I can cause such a color shift. I analyzed the colors via several control instruments and the colors are same.

Did you also check the rendered results inside Vegas Pro with its internal preview?

[Adam Sandler]

[Marco Baer] “Did you also check the rendered results inside Vegas Pro with its internal preview?”

Well, I just did what you told – both normal and resized&color shifted clips looks identical in vegas preview window(sony and maincpt), but differently in MPC_HC VLC Quicktime.
I did test twice, second time in virtual machine without any additional codec packs installed – result is the same – clips identical in vegas and different in windows media player.

Also clips look differently in Adobe Premier.

retried experiment in Vegas 11 32bit – it does colorshift with mainconcept source and resized size, and with sony codecs during resizing, however in vegas preview window those clips look identically except maincopts source size clip (it’s colorshifted)

wtf

[Marco Baer]

Then it is very likely it’s the players which decodes the files differently while the files actually all have same color. Besides different players use different video level management, some also interpret different color spaces. And what your demo pictures above show, really looks like a color space decode mismatch.

I only wonder why this happens. It may be the players take their color space base from the frame size and e.g. they use rec. 601 for any size below1280x720 and rec. 709 for sizes of 1280×720 and above.

Curious whether the differences of your renders adapt to the differences of rec. 601 and rec. 709. I’ll do some tests later.

[László Kovács]

And what happens if try to feed only with 16..235 the mainconcept encoder?
Put a solid black [16,16,16] in a track below your movie, do that resize then, and repeat the color shifting test.
Side note: in Vegas preview where you see a black in an empty space, it’s not really a black but a tranparent (which results in pure black if nothing below, but that transparent is not affected by FX levels on output…

Best regards

László Kovács

[Marco Baer]

I’d say: Bingo, that’s it (the false interpretation of color space by the players).

If you do a 709-to-601 channel blend conversion in Vegas Pro to your original sized footage, colors look exactly same.
Or –
If you do a 601-to-709 channel blend conversion in Vegas Pro to your resized footage, colors look exactly same, too.

So the easiest way for you to correct in a way the players will work as expected, is to pre-correct via an appropriate channel blend ajustments (I’m struggling through my brain getting the right order – I think your pre-correction then should be a 709-to-601 correction).

[Marco Baer]

Aaarrgghh – vice versa.

Original size: 601-to-709 corrected
Resized: 709-to-601 corrected

And pre-correction probably: 709-to-601

[Adam Sandler]

[László Kovács] “Put a solid black [16,16,16] in a track below your movie, do that resize then, and repeat the color shifting test.”

no dice. However, it really did speed up mainconcept encoding time!

btw I did test with other video with 1920×820, resized different ways and did not find color shifting.