More strangeness with Premiere Pro & Avisynth that I can't figure out

[Asterra]

It's time to return to my home video project and I've encountered another oddity. In a nutshell: It looks like Premiere Pro CS4 cannot import YUY2 without performing a bad RGB conversion (brighter greens and darker reds).

I'll give a tiny clip:
hdv_redgreen_test04.avi

This came from a Canon HV20 as mpeg2 (1440x1080i) and was rendered with Premiere Pro as uncompressed v210 ("old faithful"). Reimporting this render back into Premiere Pro reveals that it is essentially* identical to what Premiere Pro started with. So there's that.

Now, my very next step is to use this Avisynth command:

FFVideoSource("hdv_redgreen_test04.avi")

I'll keep it simple and leave it at that. FFVideoSource is the only means I have of forcing Avisynth to load v210, and it works just fine. But it does convert the input into YUY2.

I then load the script into VirtualDub and render off a new uncompressed raw (fast recompress). Comparisons between all three results (the PPro-rendered v210 linked above, the Avisynth script, and VirtualDub's new rendering) from within VirtualDub shows that all three seem to be indistinguishable. So I try loading VirtualDub's new render back into Premiere Pro.

Ah, now we have encountered a problem. A problem, in fact, I would like to believe should be limited to YUV/RGB conversions. Greens have gotten brighter. Reds have gotten darker. Everything looks just a little off. The only difference? The video is now YUY2.

Now I have to point out one more variable. I've already performed a process similar to this. Here was that workflow: PPro DV smartrender -> Avisynth FFVideoSource -> VirtualDub fast recompress uncompressed -> PPro. This did not produce the red/green issue, and the only difference here was that I was dealing with a DV smartrender rather than a v210 raw render. I mention this variable because the final raw was YUY2, yet Premiere Pro did not mess up the colors like it seems to be doing with the file above.

Something is messing things up and I am more than ready to blame Premiere Pro because it is a perpetual source of unexpected headaches. Perhaps the "solution" (one I would gladly take) would be to find a way to convert the YUY2 back to v210 before letting Premiere Pro have it. It would be a riot if that actually worked. But there is no converttov210. Anyway, I can only hope the experts here might have some insight.

*In fact, Premiere Pro appears to be completely incapable of providing an uncompressed render which is 100% identical to what it starts with. At the very least, some very subtle luminance shifts can be observed. But in this particular case (HD interlaced video) it even seems to be shifting the video upwards by one scanline - a quirk which I sincerely hope will not come back to haunt me. And no, I do not believe it is a field order error on my part.

[edDV]

It's time to return to my home video project and I've encountered another oddity. In a nutshell: It looks like Premiere Pro CS4 cannot import YUY2 without performing a bad RGB conversion (brighter greens and darker reds).

Are you familiar with 0-255 RGB vs 16-235 "Studio RGB" issues?

I think this is the root of your transcoding issues.

If luminance levels aren't being affected then look into "4:2:0" YV12 compared to "4:2:2" compared to "4:4:4".

[poisondeathray]

The reason is PP uses Rec601 for it's RGB conversion (this would usually be incorrect for HD footage)

In terms of intermediates, v210 is the only way to "force" it to use Rec709 if you are using Y'CbCr . The other way is to use Rec709 matrix and use an RGB intermediate

If you are using vdub to compare, the display uses Rec601 for it's RGB conversion (even if internally, using fast recompression, you are still in Y'CbCr). This is why everything looks the same in vdub. (you have to convert to RGB for display)

I'm pretty sure I covered this in one of your other threads, the one with the video game. Go look back there for more information

[Asterra]

The reason is PP uses Rec601 for it's RGB conversion (this would usually be incorrect for HD footage)
[...]
I'm pretty sure I covered this in one of your other threads, the one with the video game. Go look back there for more information

I'll have to apologize in this case because I am having difficulty using the information to identify where things are going wrong. I had perhaps better stress one point and explain another point which I had failed to mention previously.

The point to stress is that as far as I know, the actual video data never gets converted to RGB as a file - only for the previews. The Avisynth script is exactly as typed, and I have no reason to suspect that FFVideoSource is doing such a conversion.

Now the item I didn't point out before. After importing the VirtualDub render back into Premiere Pro and observing that the greens and reds have changed, I go ahead and export another v210 raw of this now-corrupted version. Sure enough, this new raw exhibits the green/red problem which first manifested in PPro.

Therefore, a non-preview RGB conversion must be taking place somewhere. My goal here is to pinpoint where, and (it is hoped) find a way of preventing it. The solution may be, as I pondered earlier and you later suggested, to find a way to convert the YUY2 back to v210 before giving it to PPro. I'd be happy to test this option if Avisynth had an obvious method for achieving it.

A recap of the process:

(v210 raw from PPro) -> Avisynth | FFVideoSource -> VirtualDub | fast recompress -> (YUY2 raw from VDub) -> PPro [corruption apparent] | v210 raw -> (v210 raw from PPro) -> Avisynth | FFVideoSource -> VirtualDub [corruption apparent]

[poisondeathray]

The reason is PP uses Rec601 for it's RGB conversion (this would usually be incorrect for HD footage)
[...]
I'm pretty sure I covered this in one of your other threads, the one with the video game. Go look back there for more information

I'll have to apologize in this case because I am having difficulty using the information to identify where things are going wrong. I had perhaps better stress one point and explain another point which I had failed to mention previously.

The point to stress is that as far as I know, the actual video data never gets converted to RGB as a file - only for the previews. The Avisynth script is exactly as typed, and I have no reason to suspect that FFVideoSource is doing such a conversion.

Now the item I didn't point out before. After importing the VirtualDub render back into Premiere Pro and observing that the greens and reds have changed, I go ahead and export another v210 raw of this now-corrupted version. Sure enough, this new raw exhibits the green/red problem which first manifested in PPro.

Therefore, a non-preview RGB conversion must be taking place somewhere. My goal here is to pinpoint where, and (it is hoped) find a way of preventing it. The solution may be, as I pondered earlier and you later suggested, to find a way to convert the YUY2 back to v210 before giving it to PPro. I'd be happy to test this option if Avisynth had an obvious method for achieving it.

A recap of the process:

(v210 raw from PPro) -> Avisynth | FFVideoSource -> VirtualDub | fast recompress -> (YUY2 raw from VDub) -> PPro [corruption apparent] | v210 raw -> (v210 raw from PPro) -> Avisynth | FFVideoSource -> VirtualDub [corruption apparent]

The YUY2 "raw" is uncompressed YUY2, that gets the Rec601 treatment in PP. That's where the conversion is going on

I probably sound like a broken record, and it is a lot to digest. Go back to the other threads if you want more info it's explained there. I'll try to summarize it briefly:

To summarize, native camera formats (one that PP has a preset for, eg. HDV, AVCHD) don't get converted to RGB, internally they are treated as Y'CbCr until you apply a filter or transition. The only intermedate that gets Rec709 treatment is v210. I'll say that again: The only intermedate that gets Rec709 treatment is v210. . All other ones (e.g. lagarith, ut video codec, huffyuv, dozens of others), including uncompressed YUY2 , get converted to RGB internally, using Rec601 matrix.

So let's assume you're not making any edits. Just import then export testing. The HDV source is a native camera format, it has a preset sequence, so it is treated correctly with Rec709 for the display, but internally it's still a Y'CbCr project. Look there is no red render bar (red render bar usually means mismatched sequence, and PP has to convert to RGB). When you export v210, it's still in the same Y'CbCr (matrices are only applied when there are Y'CbCr <=> RGB conversions) . When you use vdub in fast recompress mode, it's still Y'CbCr.... But you changed it to YUY2 uncompressed. That's the problem (or rather, the problem with Premiere): It doesn't "see" uncompressed YUY2 as Y'CbCr. It converts it to RGB. When it converts to RGB it uses Rec.601

Hope that's more clear

[Asterra]

But you changed it to YUY2 uncompressed. That's the problem (or rather, the problem with Premiere): It doesn't "see" uncompressed YUY2 as Y'CbCr. It converts it to RGB. When it converts to RGB it uses Rec.601

Hope that's more clear

Indeed, thanks. Truthfully I had half-suspected that Premiere Pro was mistreating the YUY2 and joked about it in my original post. The solution, then, is to find a way to convert back to v210. I have looked. Avisynth doesn't seem to have a plugin for this. I pretty much don't know how I might go about it. Obviously I am trying to avoid adding a converttorgb to my script when, strictly speaking, I shouldn't need it.

[poisondeathray]

I explained the method I use in the other thread: use batch scripts for ffmpeg

Remind me again - What are you doing that requires vdub ? and reimport back into PP ?

The other way you can do it is install drastic codecs (free), v210 will show up as one of the options in the VFW menu (the vdub compression menu). You can encode through avspmod as well (and access the same comrpession menu). Be careful, there are several variants, like 012v (byte order is swapped). The one you want is v210. Verify it with mediainfo

[Asterra]

Remind me again - What are you doing that requires vdub ? and reimport back into PP?

Well, it seems most camcorders record luma values above 235 (specifically, 16-255) and I'm basically forced to jump through several hoops in order to preserve that detail. Every DV camcorder I've used does this, as does the Canon HV20 (a pretty good 1080i60 model). I haven't yet tested the footage from the 1080p60 Panasonic model but I am willing to bet it does the same thing. It sure would save a lot of time if it didn't, though.

Obviously this means adding converttoyv12 and smoothlevels to the Avisynth script. They were missing from my original post (and my test scripts) in order to avoid confusion.

Just tested the new process (Vdub drastic codec v210) and the result is 100% identical to the original, which makes me quite happy. Thanks again.

[poisondeathray]

Remind me again - What are you doing that requires vdub ? and reimport back into PP?

Well, it seems most camcorders record luma values above 235 (specifically, 16-255) and I'm basically forced to jump through several hoops in order to preserve that detail. Every DV camcorder I've used does this, as does the Canon HV20 (a pretty good 1080i60 model). I haven't yet tested the footage from the 1080p60 Panasonic model but I am willing to bet it does the same thing. It sure would save a lot of time if it didn't, though.

Obviously this means adding converttoyv12 and smoothlevels to the Avisynth script. They were missing from my original post (and my test scripts) in order to avoid confusion.

Just tested the new process (Vdub drastic codec v210) and the result is 100% identical to the original, which makes me quite happy. Thanks again.

In CS5, there are filters called "YUV" filters, they are applied before the RGB conversion, so you access the range Y' 235-255 (bring them down) before the RGB conversion clipping

In CS4 and earlier, some of the filters can salvage superbrights before the RGB conversion. IIRC "fast color corrector" can do this. Check it out with the YC waveform .

Of course this only applies to formats that PP "sees" as Y'CbCr (e.g. native camera formats like HDV, DV-AVI etc...)



But why are you going to PP, then to vdub then back to PP ? (why don't you start in vdub, then export v210 or whatever format then go to PP ? why that initial PP step ?) . You can salvage all that superbright data in avisynth as well, smoothlevels is your friend.

[Asterra]

In CS4 and earlier, some of the filters can salvage superbrights before the RGB conversion. IIRC "fast color corrector" can do this. Check it out with the YC waveform .

Well holy crap. It really does. And the conversion to 235 is actually smooth just like smoothlevels! (No banding in the luma channel.) What an incredible time savings! It's almost beyond belief.

But why are you going to PP, then to vdub then back to PP ? (why don't you start in vdub, then export v210 or whatever format then go to PP ? why that initial PP step ?) .

It's a bit moot now, but the reason was because VDub is not an editor, and I had no interest in processing dozens of hours of video when all I really wanted was about 30 minutes of select clips.

You can salvage all that superbright data in avisynth as well, smoothlevels is your friend.

Yes, actually this was the reason I was exporting raw in the first place. ;p

[Asterra]

In CS4 and earlier, some of the filters can salvage superbrights before the RGB conversion. IIRC "fast color corrector" can do this. Check it out with the YC waveform .

I have noticed one important difference between smoothlevels and fast color corrector and I was wondering what your thoughts might be.

Smoothlevels from 16-255 to 16-235 produces video with luma in that range, but the CbCr channels also get constrained slightly - presumably in proportion with the overall reduction in brightness you get when squashing luma 255 down to 235 (it seems about right). This is verifiable with PPro's scopes. Meanwhile, PPro's fast color corrector leaves the CbCr channels more or less untouched. Certainly their peaks stay the same. This means that the two functions are producing a visibly different result, with fast color corrector looking a bit more saturated.

Right now I can't even get my head around which one (between leaving the color untouched and modifying it in proportion with alterations to the brightness) is technically correct. If smoothlevels is correct, then I need some means of achieving the same thing from within Premiere Pro, or else I'm back to square one. :/

Edit: The "means" in this case is the saturation bar in fast color corrector (adjusting it from 100% to about 92.16%). My worry is that this function is not tied to luma adjustments by default, the way it seems to be with smoothlevels.

[poisondeathray]

In CS4 and earlier, some of the filters can salvage superbrights before the RGB conversion. IIRC "fast color corrector" can do this. Check it out with the YC waveform .

I have noticed one important difference between smoothlevels and fast color corrector and I was wondering what your thoughts might be.

Smoothlevels from 16-255 to 16-235 produces video with luma in that range, but the CbCr channels also get constrained slightly - presumably in proportion with the overall reduction in brightness you get when squashing luma 255 down to 235 (it seems about right). This is verifiable with PPro's scopes. Meanwhile, PPro's fast color corrector leaves the CbCr channels more or less untouched. Certainly their peaks stay the same. This means that the two functions are producing a visibly different result, with fast color corrector looking a bit more saturated.

Right now I can't even get my head around which one (between leaving the color untouched and modifying it in proportion with alterations to the brightness) is technically correct. If smoothlevels is correct, then I need some means of achieving the same thing from within Premiere Pro, or else I'm back to square one. :/

Adjust the chroma parameter. If you want only Y adjusted, use chroma=0. This would be like YLevels filter
http://avisynth.org/mediawiki/YLevels


EDIT: (this doesn't affect you) but when you are using the TV<=>PC presets, the official spec conversion consistent with ITU parameters uses the value chroma=84. (someone did a bunch of tests). The default is 100 and it goes up to 200 in the recent versions.



There is no "correct" or "incorrect" unless you are doing a rec601 <=> rec709 conversion or a TV<=>PC levels conversion. Yes as a general rule, you don't want to clip data, but that's about the only thing that you should do. Everything else is subjective

If you want to be really fancy, you should be doing everything with linear workflow and scaling. Premiere can't do that. Linear workflow is the "most correct" way.

Just my opinion, but you do think you might be "obsessing" over this just a tiny bit? It's one thing to salvage superbrights, but this is an HDV source, I don't think a tiny difference will impact your final result

[Asterra]

Just my opinion, but you do think you might be "obsessing" over this just a tiny bit? It's one thing to salvage superbrights, but this is an HDV source, I don't think a tiny difference will impact your final result

I need to provide some perspective. First, the entire project takes a lot of time and effort by default, so there is already no option to simply whip out a result and call it good. Since that is the case, I may as well do as good a job as I can. Second and most important, whatever the answers to these questions turn out to be, they will still be the correct answers in any future project I take on. I can either iron out such unknowns now or deal with them perpetually.

In this particular case, there also may or may not be a lot of additional work added, depending. I am making use of a noise reduction plugin, and this plugin has to be finetuned on a clip-by-clip basis or the results can be fairly devastating to whatever true detail remains in the video. I have already done this finetuning, but I will probably have to redo it all if smoothlevels had been defaulting to an arbitrary, irrelevant chroma setting as it seems to have been.

That leaves the question of what should actually be done with the chroma in order for it to correctly match an adjustment to luma from 255 to 235. Should it be left alone, or reduced to 92%? A quick experiment (for example, reducing luma to 32 and leaving saturation untouched) shows that the correct answer must be the latter. In deference to your observation and the demands of sanity, however, I may elect to leave my thus-far finetuned results as-is and limit the correct approach to the remainder of this video project.

[poisondeathray]

Just my opinion, but you do think you might be "obsessing" over this just a tiny bit? It's one thing to salvage superbrights, but this is an HDV source, I don't think a tiny difference will impact your final result

I need to provide some perspective. First, the entire project takes a lot of time and effort by default, so there is already no option to simply whip out a result and call it good. Since that is the case, I may as well do as good a job as I can. Second and most important, whatever the answers to these questions turn out to be, they will still be the correct answers in any future project I take on. I can even iron out such unknowns now or deal with them perpetually.

In this particular case, there also may or may not be a lot of additional work added, depending. I am making use of a noise reduction plugin, and this plugin has to be finetuned on a clip-by-clip basis or the results can be fairly devastating to whatever true detail remains in the video. I have already done this finetuning, but I will probably have to redo it all if smoothlevels had been defaulting to an arbitrary, irrelevant chroma setting as it seems to have been.

That leaves the question of what should actually be done with the chroma in order for it to correctly match an adjustment to luma from 255 to 235. Should it be left alone, or reduced to 92%? A quick experiment (for example, reducing luma to 32 and leaving saturation untouched) shows that the correct answer must be the latter. In deference to your observation and the demands of sanity, however, I may elect to leave my thus-far finetuned results as-is and limit the correct approach to the remainder of this video project.

Technically, neither is correct, because you're basing your observations on an applied gamma of 2.2. You should linearize your workflow to get "correct" values. (Apply the reverse gamma curve, linearize it, then make adjustments in linear workspace, then re-apply the standard 2.2 gamma curve when you distribute)

In a practical sense, as long as the chroma isn't clipping you're fine. You're going to grade it anyway. So the only thing you need to worry about is having all the information there before you do your final grade.

RGB and Y'CbCr don't overlap completely, and most grading software make color adjustments in RGB. So this is even more reason to make sure there is no clipping.

note - Some cameras clip chroma before luminance, so you have no way of monitoring this through zebras or waveform monitors when shooting. This is bad , because the inequality can lead to colored highlights (instead of being "white", there is a hue shift to it). If it's clipped, there is no way to fix it. So if your camera does this , a good guideline is to shoot a stop under all the time.

[Asterra]

Technically, neither is correct, because you're basing your observations on an applied gamma of 2.2. You should linearize your workflow to get "correct" values. (Apply the reverse gamma curve, linearize it, then make adjustments in linear workspace, then re-apply the standard 2.2 gamma curve when you distribute)

Hmm. I am learning quite a lot today, it seems.

Premiere Pro CS4 appears to have only one function for gamma correction ("Gamma Corrector"). This function uses what seems to be a non-standard range (1 to 28, default 10). It also works in RGB and so clips the superwhites.

So if I want to perform a linearized levels adjustment, then - barring a revelation about a well-hidden video effect in PPro - I'll have to render raws for Avisynth after all.

Edit: Actually, the luma adjustor has the gamma function built in. HOWEVER. The gamma adjustment causes banding in the luma channel. (Readjusting back to 2.2 does not fix this.) So much for that.

[poisondeathray]

Technically, neither is correct, because you're basing your observations on an applied gamma of 2.2. You should linearize your workflow to get "correct" values. (Apply the reverse gamma curve, linearize it, then make adjustments in linear workspace, then re-apply the standard 2.2 gamma curve when you distribute)

Hmm. I am learning quite a lot today, it seems.

Premiere Pro CS4 appears to have only one function for gamma correction ("Gamma Corrector"). This function uses what seems to be a non-standard range (1 to 28, default 10). It also works in RGB and so clips the superwhites.

So if I want to perform a linearized levels adjustment, then - barring a revelation about a well-hidden video effect in PPro - I'll have to render raws for Avisynth after all.

Edit: Actually, the luma adjustor has the gamma function built in. HOWEVER. The gamma adjustment causes banding in the luma channel. (Readjusting back to 2.2 does not fix this.) So much for that.

It's not the same thing. I'm not talking about gamma corrections in sRGB space. I'm talking about linearized workflow and linearized workspace in 32bit

Do a search on Google, there are a bunch of sites that talk about it and some vidoes might describe it better.

Here is one, it focuses on scaling ,but the concept is the same with color manipulations and sRGB and gamma curves
http://www.4p8.com/eric.brasseur/gamma.html

I wouldn't worry about it, because premiere can't do it correctly, and avisynth can't either . AE supports it , but it won't make a huge difference unless you have alot of non live action footage (like CGI elements), or use a lot of HDR 32-bit effects.

Don't go all OCD on me