Which flavour of MagicYUV are you guys using? MagicYUV RGB is 100% lossless for me, every time.

I'll add Magic YUV 4:4:4

I need to check my settings as well! I assumed the default was 422.

John, I think your results are probably correct. I've been scratching my head over this; my first result seemed improbable except in context with 444.

I am still looking for "YUV Magic," if such a thing truly exists. As far as file size, John, was your Sony YUV codec 8- or 10-bit?

If Magic 444 is truly 4x smaller than Sony 422, this may be "case closed" on size, quality, and speed. So much for monolithic thought processes in production, doh?

Again, I'm really glad to have other sets of eyes on this. I'll try to find a way to measure true PSNR using the chroma interference bars.

Anyone got ProRes 422 to test?

I used the 8 bit version of Sony YUV.

That's a huge size, and I presume rendering time savings.

I'm going to dust off UT codec and compare 444 compression.

 I added UTVideo 444 to my results page. I use a flavor of UTVideo for my OBS screen recordings on an older, slower machine that has a lot faster I/O than CPU.

And you report 9% smaller than UT. And Handbrake reportedly accepts it now.

@Hope

"Will be sticking with the RGB flavour for my intermediates."

I rendered Magic YUV RGB and added it to my results. I found it indistinguishable from the original.

I tend to agree.

Are you seeing a difference between 444 and RGB ?

I think I have a way of running SSIM analysis on these that would indicate if there are perceptual differences.

I'm able to measure a difference between Magic YUV 444 and Magic YUV RGB.

What I can see is a completely different matter. 

It snowed today and the Broncos had a bye week so here are some numbers.

SSIM is a Structural Similarity tool that picks up compression artifacts, among other things. PSNR is Peak S/N Ratio, aka shadow noise. 30-50 psnr is good for compressed camera video, but not so good for animation and generated motion media source.

The AVC internet numbers, which are the only 420 interframe compression example, may be artificially high because the effects of temporal processing, such as motion estimation, cannot be factored in.

SSIM 1.0 = 100%

PSNR 100 dB = 100%

Are you seeing a difference between 444 and RGB ?

On the clip I tried (which was of a load of puffins, and not color bars) I can't see any difference with my eyes but my video scopes move significantly. The histogram gets kind of jagged.

Well some old favorites seem kind of bland against "newer" RGB codecs. UT was just coming into favor the last time I really looked at this.

can some smart person do an idiot's guide rating from 1 to 5 stars on each result? (I know size and other factors will affect people's needs and uses)

Updated to include new codecs, correct typos and added "ratings, " 1 being the best, 5 being yesteryear's best.

Magic and UT RGB are pretty cool, iindeed. Yesterday I "thought" I could see the effects of 40 dB PSNR in the 422 render, but now I'm not so sure. (I was a grain-peeper, well before there were pixels.)

I waffle a lot here on subjectively held beliefs. This time around, the eyes aren't helping.

Lagarith, Cineform, DNxHD, will not be tested for various annoying reasons.

I am having fun learning the new version of the MSU SSIM Tool.

http://www.compression.ru/video/quality_measure/vqmt_download.html

Here's Uncompressed RGB vs. 422; this is the one that puts it all in a better perspective for me.

For the majority of my full-motion work, RGB at 13% of Uncompressed size is the sweet spot afaiac.

For larger projects and slideshows, 422 at 1% of Uncompressed size is ideal, lacking conclusive evidence of visual differences, again afaict. 444 is just a red herring because it is no smaller than RGB, and takes longer to compress.

.

@Hope

"Will be sticking with the RGB flavour for my intermediates."

I rendered Magic YUV RGB and added it to my results. I found it indistinguishable from the original.

I tend to agree.

+1

I downloaded Magic YUV and it just keeps giving me the error message:
"The selected codec does not support the current render settings".
EDIT: I changed it to Magic YUV RGB and it worked - sorry!
I say it worked, but it estimated a render size of 1GB for a 40 secs timeline, and gave me a rendered .avi file of 3.45GB!
The files I have (Galaxy S7  - Video: 00:00:08.289, 59.233 fps progressive, 1920x1080x32, AVC   Audio: 00:00:08.255, 48,000 Hz, Stereo, AAC) are only short clips amounting to about 260MB in total so I'm guessing I am missing something obvious.
Originally I just wanted to render this project (I just edited out the footage I don't want from some clips) as lossless as possible for further editing and came across this thread.
After much searching, I've found nothing that states that this is even possible.
Am I missing something glaringly obvious here also?
Thanks for any help/input/feedback

I've just re-read this thread and maybe there is something I didn't properly understand. Although Nick didn't mention how long his edit was, as it rendered in 21s and the resulting file size was 3.82GB, I'm guessing this is a good result?
I'm just shocked that I'm working with files totalling 260MB which equate to a 3.45GB file when rendered together as a .avi.
I'm just reading an article about rendering intermediate files, so maybe my question will be answered in that!

Without your own test data and file properties, we can't draw comparisons. Here's a basic math formula for you to work with:

Time (Sec) x Bitrate (Mbps) x .125 = Size (MB)

 This thread did not intend to compare render times, which introduces outside variables (equipment and source).

Welcome to the discussion, and keep thinking!

https://www.mediaarea.net/QCTools. An interesting program for video analysis. Maybe someone will come in handy.