VideoHelp Forum
+ Reply to Thread
Page 1 of 7
1 2 3 ... LastLast
Results 1 to 30 of 200
Thread
  1. 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.

    https://forum.videohelp.com/threads/376644-What-Codec-Do-I-Need-to-Play-This-AVI#post2430481

    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
    Image
    [Attachment 35721 - Click to enlarge]


    UTVideo Export from PPro
    Image
    [Attachment 35722 - Click to enlarge]
    Last edited by SameSelf; 29th Feb 2016 at 09:42.
    Quote Quote  
  2. 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
    Quote Quote  
  3. Wow, pdr, that is a very eloquent explanation. I also appreciate the workaround tip. I will give that a shot because I am interested in understanding this more fully. I will probably be posting back with my results as well.
    Quote Quote  
  4. Originally Posted by poisondeathray View Post
    The short explanation is the colorbars internally generated in PP are actually in RGB, but the timeline is working in (A)YUV422 for colorbars.

    Even if you export an RGB format, you get RGB=>YUV422=>RGB conversion.

    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.
    This is quite long, so forgive me.

    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?

    Image
    [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.

    Image
    [Attachment 35732 - Click to enlarge]
    Quote Quote  
  5. 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
    http://avisynth.nl/index.php/Convert

    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

    https://software.intel.com/en-us/node/503873
    Click image for larger version

Name:	0EF01A88-F874-4ECB-B2B6-3ADC38636CD4-imageId=3A71A8D6-7CC0-4E37-B85E-2831185476F9.jpg
Views:	1116
Size:	27.9 KB
ID:	35734


    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.
    Quote Quote  
  6. 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
    Quote Quote  
  7. Originally Posted by SameSelf View Post
    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 not a one to one correspondence between all 16 million 8-bit RGB colors the corresponding 8-bit YUV values. In fact, there are only about 2/3 as many different colors in 8 bit rec.601 or rec.709 YUV (Y 16 to 235, U and V 16 to 240) and a large portion of them are outside the the RGB cube. PoisonDeathRay should have shown you the RGB in YCbCr cube:

    Click image for larger version

Name:	ycbcr.jpg
Views:	1072
Size:	29.5 KB
ID:	35742

    So maybe you can make a round trip without errors with that particular RGB value but you cannot with all 16 million.
    Last edited by jagabo; 18th Feb 2016 at 08:47.
    Quote Quote  
  8. Originally Posted by poisondeathray View Post

    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
    And in CC I do get the same results as "none" with UT RGB, 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
    Quote Quote  
  9. 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!
    Quote Quote  
  10. 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.

    Click image for larger version

Name:	YCbCr.png
Views:	1090
Size:	77.1 KB
ID:	35743

    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.
    Quote Quote  
  11. Originally Posted by poisondeathray View Post
    For snow, you can use ffplay to play anything that you used ffmpeg to encode.
    Cool, thanks for the tip. I had no idea ffplay even existed. Learn something new everyday. Here is a screenshot out of ffplay of the artifact free AE RGB export encoded using Snow which is wavelet based. Sadly the same artifacts are present here as well.

    Code:
    ffmpeg -i RGB_AE.avi -vcodec snow -an snow.mkv
    Image
    [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:

    Image
    [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:

    Image
    [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.

    Image
    [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.
    Quote Quote  
  12. Originally Posted by SameSelf View Post
    So this is all due categorically to the RGB->YUV conversion.
    No, it's due to the chroma subsampling -- and the resizing algorithms used to downscale and upscale the chroma.

    Originally Posted by SameSelf View Post
    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.
    VirtualDub uses a point resize for for it's preview panes (unless you have DirectX/Direct3d enabled). Hence, no ringing artifacts.
    Quote Quote  
  13. 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)
    Quote Quote  
  14. 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

    http://blogs.adobe.com/premierepro/2010/10/scaling-in-premiere-pro-cs5.html

    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...
    Quote Quote  
  15. 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
    Y: 1920x1080
    U: 1920x1080
    V: 1920x1080

    YUV422: Horizontal scaling needed
    Y: 1920x1080
    U: 960x1080
    V: 960x1080

    YUV420: Both horiz and vert scaling needed
    Y: 1920x1080
    U: 960x540
    V: 960x540

    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:

    Code:
    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
    This seemed to reproduce the same results that I was seeing in PP. I need to play around with it some more. But like I said, it is slowly coming together. Thanks for all the help.
    Last edited by SameSelf; 19th Feb 2016 at 09:23.
    Quote Quote  
  16. 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.
    Quote Quote  
  17. 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!
    Quote Quote  
  18. Originally Posted by poisondeathray View Post
    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

    http://blogs.adobe.com/premierepro/2010/10/scaling-in-premiere-pro-cs5.html

    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...
    That blog post on CS5 is VERY interesting, now that I have better insight as to what is going on. Confirms some things I had heard before, like the fact PP only uses bilinear/bicubic resizing. I am surprised about the Lanczos resizing with Quadro. It is strange that Adobe only offers the higher quality resizer if you pony up for a workstation card, when Avisynth offers Lanczos and many, many more. Of course, that post is about CS5, maybe the situation is slightly different under CC as you state.

    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.
    Quote Quote  
  19. Originally Posted by SameSelf View Post
    Are you saying that there is something in my previous post that is incorrect?
    No, I'm saying your observations are exactly what's expected once you know what the nomenclature means.
    Quote Quote  
  20. 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.
    Quote Quote  
  21. Originally Posted by SameSelf View 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.
    Yes, point (nearest neighbor) is usually inadvisable (other interpolation algorithms are usually more aesthetically pleasing to the eye) - but as mentioned earlier there are times when you prefer to use it. One is for certain types of initial keys and compositing when you need less interpolation , the other is multigeneration - the more interpolation, the more "blurring". Each generation will blur it more and more. Nearest neighbor (when done properly) can be done with less loss because you're just duplicating and discarding samples back and forth
    Quote Quote  
  22. It seems that the colorbar generator in PP does not conform to Rec. ITU-R BT.801-1. Here is the Avisynth generated RGB colorbar scoped up in PP. Or maybe it is the other way around.

    Image
    [Attachment 35765 - Click to enlarge]
    Quote Quote  
  23. How did you generate the colorbars in AviSynth? Try ColorBars(pixel_type="YUY2") or "YV24".
    Quote Quote  
  24. Originally Posted by jagabo View Post
    How did you generate the colorbars in AviSynth? Try ColorBars(pixel_type="YUY2") or "YV24".
    It is the default ColorBars(1920,1080,pixel_type="RGB32") without any conversions. Needed to confirm it was the same as the PP RGB bars first, and strangely it is not.

    EDIT: Here is my full workflow:

    1.
    Code:
    ColorBars(1920,1080,pixel_type="RGB32")
    Trim(0,149)
    2. Set compression in vdub to Utvideo RGB VCM and Save As AVI
    3. Import into PP and scope up
    Last edited by SameSelf; 19th Feb 2016 at 21:10.
    Quote Quote  
  25. AviSynth's RGB colorbars are in limited range RGB so it can include blacker-than-black and whiter-than-white. To get "normal" limited range YUV video use ConvertToYV24(matrix="pc.709") or ConvertToYV12(matrix="pc.601").
    Quote Quote  
  26. So I brought the colorbars into another program and sure enough the Avisynth colorbars dont show up inside the boxes. The pic below is the scopes side by side with PP on the left and Avisynth on the right. This is quite a bummer.

    Click image for larger version

Name:	Scratch.png
Views:	303
Size:	137.9 KB
ID:	35766
    Quote Quote  
  27. If you want standard RGB colorbars use

    Code:
    ColorBars(pixel_type="YV24")
    ConvertToRGB()
    Quote Quote  
  28. 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
    Quote Quote  
  29. 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:

    Code:
    ColorBars(1920,1080,pixel_type="YV24")
    Trim(0,149)
    Everything perfectly matches Adobe's bars except for Y-IQ and -4 pluge, which gets zeroed. But after reading through this thread, it is clear that jman98 and others thought hard about this 10 years ago. "Correct" Y-IQ values aren't possible in YUV space, and the -I and Q values in Avisynth are some sort of hack into YUV space. Doesn't really matter. I can live without these colors lining up with the -I and Q lines on the graticule. Here is a screen shot of the YUV444 bars scoped up in a more "pro" program, if you will.

    Click image for larger version

Name:	YUV444.png
Views:	977
Size:	46.9 KB
ID:	35785

    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:

    Code:
    ColorBars(1920,1080,pixel_type="YV24")
    ConvertToYV12(chromaresample="point")
    Trim(0,149)
    Technically, that should generate clean borders in 4:2:2 subsampling. Of course, my efforts to confirm this are stymied by the fact that Adobe and other programs seem to scope up scaled up RGB32 display. Here is what the above looks like scoped:

    Click image for larger version

Name:	YUV422.png
Views:	999
Size:	48.0 KB
ID:	35786

    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.

    Click image for larger version

Name:	GenAll.png
Views:	478
Size:	17.7 KB
ID:	35788

    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?
    Quote Quote  
  30. Originally Posted by poisondeathray View Post
    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
    I am not sure I completely follow. Are you saying there is a lossless pathway through PP? Please see my last post. I doubt the behavior has changed significantly since CS6.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!