and just what compression will you let me use?

[Sharc]

If you care about "lossless", 8bit YUV to 8bit RGB is not lossless either

Isn't it lossless if you limit yourself to using only those YUV combinations which result in valid RGB values? (I think it is called "legalizing").

[poisondeathray]

Vegas internally works in RGB, filters in VirtualDub as well -- so the conversion happens anyway.

Yes, but if you about truly lossless workflows:

1) uncompressed UYVY and v210 are the exception - these preferred pixel types mentioned before are lossless and get pass through treatment when exporting uncompressed (also 8bit422 UYVV, 10bit422 v210) , they do not incur RGB conversion automatically (unless you do something else like add some RGB filter ). You can emulate these fourcc's with avfs vapoursynth script, or use "physical" uncompressed files

Vegas cannot export 8bit 4:2:0 uncompressed, only 8bit 4:2:2 as UYVY. If you started with 8bit 4:2:0 original, you can lossless up and downsample by using nearest neighbor algorithm to 4:2:2 and back to 4:2:0 (e.g. "Point" resampling in avisynth or vapoursynth). The chroma samples are just duplicated and discarded.

2) EXR float preserves negative RGB values generated that get clipped in the 8bit YUV to 8bit RGB conversion . If you control the YUV to 32bit RGB float conversion in vapoursynth, EXR sequence import to vegas, EXR export, convert back to YUV in vapoursyth, it's lossless too (again Nearest neighbor for chroma up/downsampling)

[poisondeathray]

If you care about "lossless", 8bit YUV to 8bit RGB is not lossless either

Isn't it lossless if you limit yourself to using only those YUV combinations which result in valid RGB values? (I think it is called "legalizing").

No , it's always lossy . Remember the color cube diagram ? YUV describes a much larger space. YUV to RGB produces many negative RGB value combinations that get clipped to 0 . Also many 8bit YUV values "map" to the same 8bit RGB value, so 8bit RGB is not accurate enough to describe all those unique YUV values. Remember gavino's animated gif ? You lose potentially millions of unique YUV color combinations (many of them are arguably "aliasing" to begin with) . The only way to keep those original YUV values past RGB and back to YUV is to use RGB float for that RGB step. Negative RGB values are retained.

The point about "legalizing" is to not lose the easily visible problems right away - such as superbrights e.g. cloud details on a bright day. You still lose potentially millions of unique color combinations even when legalizing

[armyofquad]

Right......what's a cubit?

Um....any diy step by step guide a diy person could follow to capture lossless, and do whatever needs to be done to use it in Vegas without the issues you describe? I suspect many others are also in the group of us that know how to operate a VCR, know how to do a little research to try and make a better workflow than a composite out to a cheap capture device, but don't have a clue about the color cube diagram, what YUV stands for, or negative RGB values. I'm not opposed to learning, but I don't expect i'll ever pick all of this up, really just trying to keep up enough to build a semi-decent workflow for a diy-er, and follow the best practices to get the best results I can.

[poisondeathray]

Right......what's a cubit?

Um....any diy step by step guide a diy person could follow to capture lossless, and do whatever needs to be done to use it in Vegas without the issues you describe? I suspect many others are also in the group of us that know how to operate a VCR, know how to do a little research to try and make a better workflow than a composite out to a cheap capture device, but don't have a clue about the color cube diagram, what YUV stands for, or negative RGB values. I'm not opposed to learning, but I don't expect i'll ever pick all of this up, really just trying to keep up enough to build a semi-decent workflow for a diy-er, and follow the best practices to get the best results I can.

You already settled on cineform ,right ? You don't need a lossless workflow for your goals . You won't notice a difference on the end delivery

Don't worry about that geeky stuff. It's only for very specific situations where someone needs a lossless workflow for other specific reasons.

There are dozens of capture guides and info on equipment

[armyofquad]

True, I am currently leaning towards the option of cineform. But that hasn't made my curiosity of making the lossless version work in vegas go away, and what all these things I have no clue about mean. I don't expect to figure it all out, but the more I become aware of how much I don't know, the more I want to know it.

[Sharc]

If you care about "lossless", 8bit YUV to 8bit RGB is not lossless either

Isn't it lossless if you limit yourself to using only those YUV combinations which result in valid RGB values? (I think it is called "legalizing").

No , it's always lossy . Remember the color cube diagram ? YUV describes a much larger space. YUV to RGB produces many negative RGB value combinations that get clipped to 0 . Also many 8bit YUV values "map" to the same 8bit RGB value, so 8bit RGB is not accurate enough to describe all those unique YUV values. Remember gavino's animated gif ? You lose potentially millions of unique YUV color combinations (many of them are arguably "aliasing" to begin with) . The only way to keep those original YUV values past RGB and back to YUV is to use RGB float for that RGB step. Negative RGB values are retained.

The point about "legalizing" is to not lose the easily visible problems right away - such as superbrights e.g. cloud details on a bright day. You still lose potentially millions of unique color combinations even when legalizing

Yes, I am aware of the color cube diagram with only a small fraction of the possible YUV values being within the RGB cube. Hence the conversion is lossy by principle. My point was that a correctly authored Blu-ray for example should basically contain YUV (Y'CbCr) which are withing the RGB cube only, means it would avoid RGB clipping upon conversion. Therefore I wrongly assumed it would be 'lossless'. But you say that even if the YUV are all within the RGB cube the conversion YUV(legalized)->RGB is still lossy due to the 8bit integer math (limited precision, integer rounding -> spikes and gaps in the histogram), right?
Also, when "legalizing" YUV one has to tweak the values to "shift" them into the RGB cube which introduces losses by principle.

[poisondeathray]

But you say that even if the YUV are all within the RGB cube the conversion YUV(legalized)->RGB is still lossy due to the 8bit integer math (limited precision, integer rounding -> spikes and gaps in the histogram), right?
Also, when "legalizing" YUV one has to tweak the values to "shift" them into the RGB cube which introduces losses by principle.

Yes. it' s not a lossless roundtrip also for rounding, precision reasons. The spikes and gaps are also from redundant values (many YUV values map to same RGB value), and clipping . But also,those "legalized" Y 16-235, UV 16-240 do not correspond to the RGB color cube boundaries; they are different concepts. Many of "legal range" YUV values still map to negative RGB values (and values >255 in 8bit RGB) . Overall you potentially lose a few million unique YUV values, even if you use "full range" conversion (0-255 YUV <=> 0-255 RGB) . It's not just on the low end either; there are resulting RGB values >255 on the high end that get clipped to 255

eg.
YUV (234,148,195) results in RGB float of (1.46647, 0.838689, 1.16111)

So a legal range 8bit YUV value , gets clipped in the red and blue channel on the high side (in float 0-255 would correspond to 0.0-1.0) when you convert to 8bit RGB, and you're losing dynamic range

These YUV values occur natively in a "regular" 8bit camera (many of them are aliasing - you generate many "false values" from chroma subsampling in the YUV recording format - but some of them are real - it's camera dependent) . Upstream, the raw data gets debayered and processed at a higher depth (DSP chips usually work at 12bit (very low end) - 16bit) - that's where those values come from. In camera, you're not starting from 8bit RGB, not even low end very cheap cameras

Interesting article
https://www.provideocoalition.com/solutions-to-resolve-6-clipped-exports-the-yuv-enigma/

[armyofquad]

Interesting stuff. So what steps should a novice diy-er that might want to use lossless and import it into Vegas take to not run into this issue?

[poisondeathray]

Interesting stuff. So what steps should a novice diy-er that might want to use lossless and import it into Vegas take to not run into this issue?

Don't worry about it. 99.99% of people don't care about this stuff about RGB clipping, and you won't see the problems on your VHS sources.

But you work in 32bit float . There are problems with earlier vegas (Sony) versions with float workflow that were fixed in Magix versions, so don't worry about it


Definitely don't use "lossless" YUV codecs (lagarith, huffyuv, ut video etc...) in YUV mode, without "legalizing first" - because those are problems you CAN see (everyone can see , even novice). These all clip Y channel immediately (16-235) on import because you incur limited range YUV to "computer RGB" conversion - there is nothing user can do about it. Y 16-235 => RGB 0-255 . So you lose Y <16 , Y>235. Rarely do you have usable data <16 on most sources, but often you have usable data >235 - e.g. cloud details on an outdoor shot

Cineform doesn't clip automatically - it's treated as "studio RGB" in vegas instead of "computer RGB" - that's what I'd use for general use. Y 16-235 => RGB 16-235 (Or Y 0-255 => RGB 0-255), the entire range is kept

[armyofquad]

I appreciate the "don't worry about it" comment as trying to save me time about things that may not need to be of concern. But I'm tired of being frustrated about my lack of knowledge in these confusing things, and I'm capable of picking up enough to not be confused, so thank you for responding to my questions, and please continue to humor my further inquiries as time permits.

Sounds like this boils down to 2 options for the novice diy-er that would insist on sticking with lossless. Use a Magix version of vegas that fixed these problems, or "legalize first". Is this understanding correct?

I'm sure legalizing has been discussed plenty and is something that doesn't need further typing out of a how to - could you point this thread towards a guide on how to legalize, or cut and paste something on how to legalize?

[armyofquad]

There is a version of Cineform bundled with vdub2 (2 not classic) , and vegas requires the cineform codec be installed separately (search for go pro cineform studio)

If there was a reason you were using huffyuv in the first place, there must be a reason why you wanted "lossless" - so I would weigh your options carefully. Cineform is near lossess, not lossless. You can see compression artifacts if you really look closely, even at the highest quality setting (filmscan 3, or 3+ if you are using ffmpeg) . It's similar in quality to ProRes HQ, very high quality. More than suitable for most situations, but not acceptable for others

Spent hours today capturing video in cineform.

As you instructed, I googled for "go pro cineform studio"

Googling has led to me installing 3 things that are not a cineform codec that vegas recognizes, and finding multiple forum threads that provide no useful information.

This codec is nowhere to be found.

Please advise how one is supposed to use these files in Vegas 13. Please answer completely.

[poisondeathray]

I'm an old customer when they still charged for it , so I have a different install.

The free version everyone used when Go Pro took over was "Go Pro Cineform Studio". Unfortunately it installs a bunch of other bloated crap, a player for go pro files - but it works for vegas. The bloat was the "price" for free I guess. Many users have used it, you can see on this forum and the old Sony vegas forum. This definitely works - I've had it installed on multiple computers - I have no idea why it doesn't work for you

If it doesn't work for you for whatever reason, you can try this quik installer . I've never tried this version, but it looks like a legit link from gopro.
https://software.gopro.com/PC/GoPro_Quik-WinInstaller-2.3.0.5383.exe

See these links for more info and video tutorial; it's the movie studio version, but it should be similar
https://www.moviestudiozen.com/free-tutorials/vegas-pro/render-cineform-video-from-veg...o-movie-studio
https://www.moviestudiozen.com/forum/vegas-pro/2673-importing-cineform-files-into-vegas-pro-17-edit

[armyofquad]

I'm an old customer when they still charged for it , so I have a different install.

The free version everyone used when Go Pro took over was "Go Pro Cineform Studio". Unfortunately it installs a bunch of other bloated crap, a player for go pro files - but it works for vegas. The bloat was the "price" for free I guess. Many users have used it, you can see on this forum and the old Sony vegas forum. This definitely works - I've had it installed on multiple computers - I have no idea why it doesn't work for you

If it doesn't work for you for whatever reason, you can try this quik installer . I've never tried this version, but it looks like a legit link from gopro.
https://software.gopro.com/PC/GoPro_Quik-WinInstaller-2.3.0.5383.exe

See these links for more info and video tutorial; it's the movie studio version, but it should be similar
https://www.moviestudiozen.com/free-tutorials/vegas-pro/render-cineform-video-from-veg...o-movie-studio
https://www.moviestudiozen.com/forum/vegas-pro/2673-importing-cineform-files-into-vegas-pro-17-edit

Poisondeathray to the rescue again.

Not sure why all my searches brought up installers that aren't the right thing, but I can verify that the installer linked here did the trick.

Thanks, I owe you a coke.

[Sharc]

I'm sure legalizing has been discussed plenty and is something that doesn't need further typing out of a how to - could you point this thread towards a guide on how to legalize, or cut and paste something on how to legalize?

It's a topic of its own.
In a first and most important step you would have to adjust the luma (Y) of the YUV to be within 16<Y<235 range. One can do this in Avisynth for example using its waveform monitor, and adjust the levels (or tweak parameters like contrast, saturation, brightness .... ) accordingly.
See the discussion here for example:
https://forum.videohelp.com/threads/340804-colorspace-conversation-elaboration#post2121568

That step alone is however no warranty yet that the YUV is fully legalized, but this step (luma adjustment) is often adequately sufficient in practice. One would actually have to do more verification tests taking into account all 3 components of the YUV triplet, and eventually apply some fine tuning. In worst case the full legalization may however end up in a dull or washed out picture, so one has to choose his poison.

Alternatively you could also use a tool (NLE) which does NOT immediately convert YUV to RGB at import. Shotcut for example is based on ffmpeg and operates in YUV color space (unless one uses specific RGB filters).

Anyway, as you have now a working cineform installation for VEGAS it's probably much easier to follow that route, I think.

[Sharc]

Interesting article
https://www.provideocoalition.com/solutions-to-resolve-6-clipped-exports-the-yuv-enigma/

Here an attempt to "legalize" the YUV of the video in that article. The details are recovered from the clipped REDs for example. Not optimized though......

https://imgsli.com/MTkxOTY4