EDIT: This thread started as a simple question so I thought (see below), but quickly morphed into a very informative and in depth discussion on truly lossless workflows using Adobe Premiere Pro, VirtualDub, and ffmpeg. I am editing the title to reflect this fact as well as make the thread more easily searchable.
I am trying to wrap my head around this. If you read through the following thread, you will see the various export tests I did from PP.
Here is my question. Why is there so many additional dots in the vectorscope on lossless exports? It doesn't seem to matter which codec I use: Lagarith, utvideo, QT, GV HQX (granted I haven't tested every codec under the sun). I know that the reason for the problem is due to the transition between the color bars. But what I don't understand is what is so difficult? Why can't the lossless exports get it right? Is this an example of ringing or some other artifact? Below is a brief recap for those unwilling to click the link to my prior thread, but rest assured the other codecs don't look any different and are often worse.
EDIT: I am going to go out on a limb and say this is just a consequence of DCT based codecs and that maybe the problem would go away for wavelet based?
Bars and Tone Vectorscope as Generated in PPro
[Attachment 35721 - Click to enlarge]
UTVideo Export from PPro
[Attachment 35722 - Click to enlarge]
+ Reply to Thread
Results 1 to 30 of 200
Last edited by SameSelf; 29th Feb 2016 at 09:42.
A codec is only "lossless" in the same color space and color model. Sure you have no additional losses from lossy compression, but you're seeing chroma subsampling and rounding errors from colorspace conversion. You noted it yourself - you saw the deterioration between the bars
The short explanation is the colorbars internally generated in PP are actually in RGB, but the timeline is working in (A)YUV422 for colorbars. In the preview, if you zoom in to 400% or more, the color borders will be razor sharp because they have full color samples - it's a computer graphic, akin to something generated in photoshop. But you're seeing the RGB data before it gets YUV treatment. Even if you export an RGB format, you get RGB=>YUV422=>RGB conversion. Probably the reason for this is the colorbars are from a broadcast heritage, everything is in YUV
If you need to keep razor sharp RGB images, the workaround is to send it to AE and export an RGB format. This bypassess the YUV conversion, even with PP's internal colorbars
Note a host application such as premiere (and other NLE's) might not treat a "lossless" codec ideally and apply another transformation (the most usual occurrence is treat YUV lossless codecs as RGB) - this is the more common problem that people complain about, because most video sources are YUV, and you can get clipping of data
I brought the PP timeline into AE and did a simple render out as an RGB AVI per your suggestion. When I re-imported the rendered AVI back into PP, sure enough and just as you said, the vectorscope was identical with crisp edges. So that clears up a lot of things, I think. It is not obvious that the colorbar generator in PP is RGB. And personally, I am mystified why Adobe would do that.
I don't want to say I disagree with you, so correct me if I am wrong. But when I zoom in 400% as you suggested and look closely at what is going on at the edges, I see what looks like the classic ringing that results from sharp transitions as opposed to RGB->YUV conversion. I am also inclined to say this because the colorbars themselves don't seem to shift rather, artifacts appear which looks like a bunch of noise on the vectorscope. I am sure you don't need me to post a picture but here is one anyway where one can see at least three oscillations of yellow into cyan before the transient decays enough to be unnoticable. This link better explains why ringing occurs at transitions: Gibb's Phenomenon. I would be really curious if these ringing artifacts go away if using a wavelet based codec. Since I was able to get an AVI out of AE that is artifact free, I encoded it in ffmpeg using Snow. The only problem is I can't figure out how to play it. VLC doesn't work. Any suggestions on how to play a Snow.mkv or another wavelet codec that would work?
[Attachment 35731 - Click to enlarge]
FWIW, I also exported the original colorbars out of PP as an AVI with the video codec set to none. For the most part it is also identical. The ONLY difference is that the bottom left colorbar between Blue and Cyan shifts an almost imperceptible amount. If I had a 10 bit monitor, I am certain it would be more obvious. It is much easier to see on the vectorscope. But the edges are crisp.
Here is a screen shot of the bottom left square showing the color shift. The left half is the original and the right half is the AVI export. I am not sure if you will be able to see it. But when I sample the color of the original colorbar, it is [0,63,106]. The export is [1,62,106]. According to the BT.709 colorspace definitions, this transforms to Y'UV [0.2067, 0.0982, -0.1615]. I am not sure what kind of precision the colorspace conversion uses but I can easily transform the Y'UV matrix back to RGB [0,63,106] without any rounding errors. There is obviously more to the transformation than what I have shown to cause this shift. That is the only place that the colorspace conversion is resulting in a problem from what I can see.
[Attachment 35732 - Click to enlarge]
For your screenshots - You need to clarify how you are converting the YUY422 export back to RGB for display or your screenshot. Was that in PP or external program? Because PP uses different algorithms depending on if you have MRQ, MPE enabled, and/or if you have CUDA enabled. 1920x1080 YUV422 means the U, V planes are 960x1080 in dimensions. The algorithm in which you use to scale the chroma back to 1920x1080 when converting back to RGB for display affects what you "see". For example if a point resize is used, this just duplicates chroma samples. You will see blockier edges - similar to what you are seeing there. But if you used something like bicubic or spline36, it will blur the edge transitions because of interpolation. The other variable is where the chroma siting is. You can have chroma center aligned vs. top left aligned , etc.. this will affect what you see. You can play with this in avisynth to see what is going on . Start with the clean RGB image, using chromaresample="point". e.g. ConvertToYV16(chromaresample="point",matrix="rec70 9").ConvertToRGB24(chromaresample="point",matrix=" rec709"). To play with the chroma placement ,use ChromInPlacement and ChromaOutPlacement , but it only applies to 4:2:0. For example, avisynth uses MPEG2 placement (left), but PP looks like it uses center placement definitions. If some software / recieving software uses different siting, it can shift the chroma this or that way slightly more or less
You actually have more control with dither tools in terms of colorspace conversions, and the documentation has pictures to help you understand chroma siting and sampling - have a look when you have time. In some cases you want blockier chroma samples (eg. for some types of initial keying on some edges), in others you want smoother interpolated. But in no way can you every get back perfect 4:4:4 pixel resolution.
There are out of range values when you compare - I don't mean legal vs. extended range. Not all values in YUV have a coordinate or representation in RGB space. I mean values to where there no solution to the equation (negative numbers). They lie outside the RGB color cube . As for precision, you need at least 10bits to do the calculation. 8bit to 8bit is problematic
For snow, you can use ffplay to play anything that you used ffmpeg to encode.
Last edited by poisondeathray; 17th Feb 2016 at 23:06.
And I'm getting differences in CC (the trend is the same), but not quite as dramatic as your screenshot in the last post with the " at least three oscillations of yellow into cyan" . Can you explain exactly what you did to achieve that ? I don't recall CS6 was that different in terms of this stuff
Another interesting point I can't figure out is that codec "none" should in theory give the same results as any lossless RGB codec. This implies the exporting pathway is somehow different
Last edited by jagabo; 18th Feb 2016 at 08:47.
lagarith RGB , so there might be some other slight differences as to what you are getting. But the trends should still be the same. But the old AE workaround is from back to at least CS4
Wow! Great stuff! Really, really great stuff.
The part about the U,V planes being only 960x1080 is mind blowing and explains A LOT especially since I only see the ringing in the vertical edges versus the horizontal edges.
It is going to take me a while to digest everything but I will be back!
I am not certain if I am doing this right, but after a little more research, this is what I discovered. Since this is digital BT.709 space, even though we talk in YUV terms, in reality, it is YCbCr as jagabo cites, but that is just a canard in regards to the lossy conversion. See below.
For RGB values [0,63,106], these transform to YCbCr [61,153,99]. Notice how the YCbCr values are rounded to 8 bits. They are also clamped such that Y is [16...235] and Cb/Cr are [16...240]. Rounding throws away some necessary information for reconverting back to RGB. When I reconvert the rounded YCbCr values, I get RGB [0,63,105]. I am not sure why they are different from my sampled RGB values in PP. Nonetheless, the conversion is lossy due to the 8-bit rounding. Clamping doesn't impact the conversion the same way rounding to 8-bit does. For example, if you increment the RGB color to [1,63,106], clamping effects show up because the 8-bit YCbCr values don't change. But if floating point precision is maintained you can still get back to the correct RGB values. So while rounding to 8-bit makes the conversion lossy, clamping in YCbCr space means many, many RGB color pairs/triads/quads/quints like [0,63,106] and [1,63,106] look identical in YCbCr space.
Last edited by SameSelf; 18th Feb 2016 at 10:25.
ffmpeg -i RGB_AE.avi -vcodec snow -an snow.mkv
[Attachment 35750 - Click to enlarge]
I also am posting a screenshot of the YV Waveform out of PP which vividly demonstrates the Gibb's Phenomenon:
[Attachment 35754 - Click to enlarge]
Which brings me to my next point. So we can clearly see the ringing in the vertical boundaries. But the horizontal boundaries are clean as a whistle. Here is another screenshot showing the clean horizontal vs the ringing vertical:
[Attachment 35752 - Click to enlarge]
But then I realized. Wait a minute. I can export in RGB using utvideo from PP. So I tried that and what do you know? Clean as a whistle! So this is all due categorically to the RGB->YUV conversion.
But then I remembered you asked where my screenshots are from. They are all from the PP Program Monitor, zoomed in at 400%. But, I thought, why not queue it up in vdub and see if the same artifact is present? Here is a screen shot from vdub zoomed in at 400%. The ringing is not present although there appears to be some overlap in the bars.
[Attachment 35755 - Click to enlarge]
So now I am studying your comments about chroma siting. It will take me a while to walk through all your suggestions. I don't even know what I have enabled in PP: MRQ, MPE, CUDA. So much to learn. I will likely be back with many questions. I remember watching a video on Youtube a while back on how to use vectorscopes for color grading and the guy said never to trust software scopes. Of course, I could never afford a $$$$$ hardware scope. But I think I now know why he said what he said.
VirtualDub uses a point resize for for it's preview panes (unless you have DirectX/Direct3d enabled). Hence, no ringing artifacts.
If you were trying to test the wavelet theory - there are lossless wavelet codecs variants such as jpeg2000 using lossless profile . In theory it doesn't matter, because mathematically lossless is lossless. But in reality you have all these other factors, such as how software handles certain codecs or if they apply other manipulations behind the scenes like you are seeing here. But in terms of lossy codecs - wavelet codecs are overhyped - they just trade off different types of artifacts compared to DCT . The prototypical comparison is prores or dnxhd (dct) vs. cineform (wavelet)
RE: Adobe PP and scaling algorithms - it might be slightly changed now, I can't find an updated chart (for example AE, has different scaling now in CC, including a detail preserving upscale), but here is the info for CS5, which was the first version that had MPE
Note , that even within a certain scaling algorithm, there can be dozens of different variants and settings. For example, in bicubic you have the b,c parameters (you can play with this in avisynth) , some have number of iterations and taps,etc...
Thanks for the responses. I am slowly beginning to figure this stuff out and wrap my head around it. After playing around last night and not having any idea what I was doing or why, this is what I have come up with:
YUV444: No scaling needed
YUV422: Horizontal scaling needed
YUV420: Both horiz and vert scaling needed
So recapping what I was struggling with:
When PP generates a colorbar, the colorspace PP uses is RGB24/32 which is 4:4:4 (full chroma). I can stay in this colorspace on export and all is well in the world. However, upon export as YUV422 (which is lossy going from RGB->YUV), the chroma is subsampled (is that correct?) to 4:2:2. When I bring the YUV422 export back into PP, PP needs to: 1) reconvert back to RGB for display and 2) scale up the subsampled 4:2:2 chroma horizontally to 4:4:4, or 2x from 960 to 1920. The scaling algorithm that PP uses can be any number of the well known scalers: bilinear, bicubic, spline, etc., depending on how Adobe is configured, e.g. MRQ, MPE, CUDA, etc. The ringing I am seeing on the monitor in PP and the scopes is due to the scaler that Adobe is currently using.
To exactly mimic the above, I need to employ an Avisynth script similar to this:
ConvertToYV16(chromaresample="sinc",matrix="rec709") # Converts to YUV422 using a sinc rescaler for the chroma subsample ConvertToRGB24(chromaresample="sinc",matrix=" rec709") # Converts to RGB24 using a sinc upscaler for the chroma
Last edited by SameSelf; 19th Feb 2016 at 09:23.
Do you not understand what the "N:N:N" nomenclature means? Originally it was strictly the ratios of the components. 4:2:2 meant for every four Y values in the image there are 2 U and V values (with the chroma channels are subsampled horizontally). So a 720x480 4:2:2 image has a 720x480 Y channel and 360x480 U and V channels. 4:1:1 meant for every four Y values there is one U and one V value. There are two ways this can be done: 720x480 Y + 180x480 U/V, or 720x480 Y + 360x240 U/V. To differentiate the two "4:2:0" is used to describe the latter (though, as ratios, it makes no sense). And of course 4:4:4 means there are Y, U, and V values for every pixel. RGB is typically referred to as 4:4:4 because it has R, G, and B components for every pixel.
Nomenclature and especially jargon, while convenient, is rarely explicit enough to fully elucidate a topic to the uninitiated and often masquerades as code to obfuscate. Saying something in another way provides additional insight where none previously existed. This is an effective pedagogical technique.
Are you saying that there is something in my previous post that is incorrect? Please correct me if I misstated something. Like I said, I am trying to sort this out. Accuracy and precision reign supreme in this thread!
However, if I understand correctly, when I export my colorbars as YUV422 (I am in CS6), with my Quadro K2000 (MRQ checked doesn't matter), it will subsample the chroma using Lanczos 2 low pass with bicubic sampling. Then when I re-import and playback (really paused because the vectorscope doesn't display on playback) it is using Lanczos again.
So, here is my question. What exactly does "Lanczos 2 low-pass sampled with bicubic" mean? How is this replicated in Avisynth? Thanks.
OK, thanks. Good to know I am slowly converging on the right answer!
I seem to have come full circle. My original goal was to have a colorbar chart to QC my workflow. Generating one in PP seemed like the way to go. However, it is fraught with difficulties as outlined in this post.
After distilling everything I have learned, this is what I have come up with. Chroma subsampling using point resizing, under normal circumstances, is inadvisable as it simply discards half the chroma data with no sampling whatsoever. However, when generating a YUV422 version of the colorbars, it is ideal! If I bring that into PP and render out again as YUV422, that should be lossless since no resizing is needed. Only one way to be sure of course. It will still be subject to the upscaling algorithm for playback, but export should not be subjected to any scaling.
EDIT: Here is my full workflow:
3. Import into PP and scope up
Last edited by SameSelf; 19th Feb 2016 at 21:10.
If you want standard RGB colorbars use
Seems like only AVI formats are affected for the RGB export, at least in the current CC version. The bars have slightly different values (Not just a chroma subsampling issue, deterioration can be detected right in the middle of a bar) - you can see with a colorpicker or vector scope. For example on the SMPTE HD color bars, 255,0,0 becomes 254,0,0
So instead of having to send to AE, you could export MOV . Works with animation codec, UT video codec, magic YUV. Image sequences work as well . I verified with both internal bars/tone and external RGB test images as the input source. Seems like no AVI love
jagabo, thanks for the tip. I didn't read the Avisynth wiki close enough to realize I could generate YCbCr bars without going through RGB first. The example code at the bottom of the wiki is confusing. I want accurate YCbCr colorbars anyway, not RGB. So I went with the following:
But this is my real goal. I want some 422 colorbars that will be lossless because that is the space I work in. So I tried this:
ColorBars(1920,1080,pixel_type="YV24") ConvertToYV12(chromaresample="point") Trim(0,149)
Plus, exporting the YUV422 bars out of PP as Utvideo YUV 422 results in generational losses. Here is a pic I put together from PP monitor screen shots showing how the borders get increasingly messy. The other thing that bothers me is that the horizontal borders are messy as well while they are clean when generated using Adobe's colorbars.
The good news is that vdub is LOSSLESS. When I re-export the YUV422 colorbars a second time (no Avisynth script), the scopes overlay perfectly. I can see why people complain about Adobe now. If you bring a YUV422 video into a timeline and export as lossless, that is not a lossless pipeline. Maybe I am missing something about PP?