Lagarith AVI renders as 1920x1080x16 instead of 1920x1080x24

Adam_Janz wrote on 9/28/2018, 1:49 PM

Thanks, Musicvid. "There is a fair chance the shooter did not honor his zebras"... oh, you had better believe that... :-) The footage was shot be me YEARS ago, and I've learned a lot of things the hard way since then. That said, it certainly was not a bad piece of footage by any means in terms of exposure. As for 32 bit, this was indeed an 8 bit only export. However, for many other portions of the project, I do have 8 bit footage inside a 32 bit project (2.2 video gamma) since I have a lot of soft light gradients and that is the only way for it not to look terribly banded in the render.

Looking forward to seeing your examples. :-)

Kind regards,

-Adam

Musicvid wrote on 9/28/2018, 2:33 PM

Then use the levels adjustments and histogram to level and tweak to <=[16, 235] before doing anything else. This will set you straight with the world, and you should not need a post-edit levels correction or flag. See, your noncompliant source must be preconformed to legal REC709 colorspace first, since it is FLAGGED as legal REC709, and not ot a kludge.

GIGO rules. Resistance is futile. You are doing well though, maybe down to 24:32 chances for success.

Adam_Janz wrote on 9/28/2018, 2:54 PM

Thanks for the advice. :-)

Adam_Janz wrote on 9/28/2018, 7:23 PM

Thanks to your explanations, Musicvid, I think I understand what was going on with the MagicYUV export. Let's see if I got this right: YUV video should ALWAYS be 16-235, and since MagicYUV was indeed exporting YUV, it needed to be leveled to 16-235 before export (just like when exporting an .mp4). I guess what threw me off was I was so used to exporting AVI files as RGB (0-255) which would not inflate after render. Because MagicYUV was also an AVI, I wrongly assumed it should export as 0-255. :-)

Musicvid wrote on 9/28/2018, 7:47 PM

AVI is not constrained to RGB 0-255

Your AVI will be YUV 16-235

Apples and oranges.

Adam_Janz wrote on 9/28/2018, 7:54 PM

Yes, thanks for clarifying that. A very important point I hadn't really considered since I was always previously using RGB avi files. Have a good evening. :-)

Musicvid wrote on 9/29/2018, 9:25 AM

Thanks Adam. I'm glad we found our common ground, and that you were patient with me, although I was not always. It's a disease that retired teachers get.

Anyway, since you are one of the few people actually interested in this stuff, I'm going to go ahead and knock out those tests this weekend. I had put the YUV tests on the back burner for some time because Sony YUV was the walk-on winner for over a decade, but the new numbers I'm seeing from Magic have got my interest piqued again.

As for RGB intermediates, they show their best when multiple subsequent generations are needed. It will be interesting to see how Magic holds up after 4 or 5 generations, about the time they say Huffman compression starts to look a little shopworn.

You'll see a legacy thread of mine about those RGB codecs in my signature, but it's not terribly interesting because they are, well, lossless...

Adam_Janz wrote on 9/29/2018, 1:10 PM

No problem, and thanks for your insights. Looking forward to seeing the test. Maybe I've been okay then using RGB intermediates for the past few years, as oftentimes I've needed to make multiple generations. :-)

Musicvid wrote on 9/29/2018, 6:12 PM

UT AVI codec has RGB mode, and it's faster than Lagarith, compatible with the Handbrake, and no audio problems. I've used it a lot.

Adam_Janz wrote on 9/30/2018, 4:55 PM

Thanks, yes I had tried UT codec when I first ran into the problem with Lagarith, but unfortunately it gave me the same "not compatible" error message as MagicYUV...