VideoHelp Forum
+ Reply to Thread
Results 1 to 11 of 11
Thread
  1. Lagarith supports YV12, YUY2, RGB, and RGBA colorspaces, so that we can avoid colorspace conversion and maintain lossless intermediate files.

    Media Info reports that my footage has YUV color space. This is confusing for me, because I don't know what type of conversion to use in order to avoid color space conversion: YUV->YV12, or YUV->YUY2, or YV12->RGB.

    How can I avoid colorspace conversion when rendering the premiere sequence to avi lagarith ? Just by choosing RGB in lagarith ? This RGB avi will need a colorspace conversion in avisynth before encoding it with x264 ? If yes, then the superwhites and the superblacks will be clipped ? Or the contrast will change ?
    Last edited by codemaster; 1st May 2012 at 09:27.
    Quote Quote  
  2. Originally Posted by codemaster View Post
    Lagarith supports YV12, YUY2, RGB, and RGBA colorspaces, so that we can avoid colorspace conversion and maintain lossless intermediate files.

    Media Info reports that my footage has YUV color space. This is confusing for me, because I don't know what type of conversion to use in order to avoid color space conversion: YUV->YV12, or YUV->YUY2, or YV12->RGB.

    How can I avoid colorspace conversion when rendering the premiere sequence to avi lagarith ? Just by choosing RGB in lagarith ? This RGB avi will need a colorspace conversion in avisynth before encoding it with x264 ? If yes, then the superwhites and the superblacks will be clipped ? Or the contrast will change ?

    Not possible with YV12 source, lagarith and premiere

    If you force RGB, or convert with avisynth, that is a YV12=>RGB conversion

    There is no contrast change, only if you have superdark and superwhite data will it be clipped. Also you will lose some color accuracy (You are upscaling then downscaling the color information, and depending on the method you chose, you will either get slightly blurred edges , or aliasing - it's normally barely noticable unless you zoom in and go frame by frame)

    Unavoidable if you use premiere, unless you don't do any color correction, or use any filters (as soon as you use most filters, you incur RGB conversion anyway)
    Quote Quote  
  3. ok, there will be a YV12 to RGB conversion in premiere pro, because I use tonality and color correction filters

    but before I import my footage in premiere pro, I have to crop, deinterlace, resize and denoise my mpg clips, and convert them to YV12 Lagarith. YUV to YV12 represents a color space conversion ? Or YUV and YV12 are the same thing ?

    and, after I export the sequence to RGB Lagarith, I have to do a RGB to YV12 color space conversion before encoding with x264; RGB to YV12 involves clipping ? Or other problems ?
    Last edited by codemaster; 1st May 2012 at 10:31.
    Quote Quote  
  4. Originally Posted by codemaster View Post
    ok, there will be a YV12 to RGB conversion in premiere pro, because I use tonality and color correction filters

    but before I import my footage in premiere pro, I have to crop, deinterlace, resize and denoise my mpg clips, and convert them to YV12 Lagarith. YUV to YV12 represents a color space conversion ? Or YUV and YV12 are the same thing ?
    YV12 is part of Y'CbCr color model (YUV is analog term for Y'CbCr)
    YV12 is 4:2:0 planar subsampled Y'CbCr

    and, after I export the sequence to RGB Lagarith, I have to do a RGB to YV12 color space conversion before encoding with x264; RGB to YV12 involves clipping ? Or other problems ?
    Clipping would occur if you have superbright/dark data and you did YCbCr=>RGB conversion with a Rec matrix. I described how to work around this in one of your other threads (either color correct or fix levels in YCbCr before converting to RGB, or use full range RGB matrix, or use native MPEG2 in premiere (recall it treats most native camera formats as YCbCr), then do your deinterlace,crop or other adjustments later). Go back and read those threads, because I'm just repeating myself here
    Quote Quote  
  5. ok, I can fix the levels of YV12 footage, in premiere, so that at least no visible details are clipped after conversion to RGB, but after the conversion to RGB, there will be another colorspace conversion: RGB to YV12 with ConvertToYV12() in avisynth, just before frameserving to x264. In this last RGB to YV12 conversion, what kind of modifications will occur, and are they noticeable ?
    Quote Quote  
  6. Originally Posted by codemaster View Post
    ok, I can fix the levels of YV12 footage, in premiere, so that at least no visible details are clipped after conversion to RGB, but after the conversion to RGB, there will be another colorspace conversion: RGB to YV12 with ConvertToYV12() in avisynth, just before frameserving to x264. In this last RGB to YV12 conversion, what kind of modifications will occur, and are they noticeable ?

    Or you can fix them before, or use full range matrix - your options were listed earlier

    If it's interlaced RGB you are frameserving or exporting lossless intermediate, you have to specify ConvertToYV12(interlaced=true) in avisynth

    There is quality loss everytime you do colorspace conversion, but it's usually not noticable (you have to zoom in). On some types of content, it's more noticable (e.g. animation with clear color borders, thin text), on other types it's not notciable at all
    Quote Quote  
  7. Code:
    Levels(0, 1, 255, 0, 255)
    is this a correct method to correct levels, so that nothing gets clipped when the conversion from YV12 to RGB occurs ?
    Quote Quote  
  8. Originally Posted by codemaster View Post
    Code:
    Levels(0, 1, 255, 0, 255)
    is this a correct method to correct levels, so that nothing gets clipped when the conversion from YV12 to RGB occurs ?
    This is one way of doing it - this will clamp (not clip) on a full range YCbCr clip (one that has superbrights/darks) because coring=true by default. It does nothing on a legal range video. If you put coring=false, the limiter (clamp) is disabled

    But when you are grading, you usually want access to all the data, but more spread out. When it's clamped (not clipped), it's harder to make fine adjustments (it's all squished together). Think of it as being spread out more. If you clip (its gone, cut off); if you clamp, its squeezed to Y16-235, CbCr 16-240. This when the RGB Rec conversion comes along 16-235 is mapped to RGB 0,0,0-255,255,255 . Nothing is cut off because it's all in "legal range" before the RGB conversion

    ConvertToRGB(matrix="pc.601", interlaced=true) #(or false if progressive) will stretch the contrast because YCbCr 0-255 will get mapped to RGB 0,0,0 - 255,255,255 , but the full range will be preserved

    You decide what method is better for you
    Quote Quote  
  9. If I were doing this, I would edit the mpeg natively

    This gives you more options later on. For example, if you decide to go to DVD-video, or SD blu-ray sometime later you have those options. If you decide to go to flash, deinterlace etc... you have that option from the same saved project. You have the option to reuse elements in other projects. If you've already deinterlaced, resized it, you have fewer options in the future, you might have to redo a lot of things
    Quote Quote  
  10. So if I convert the mpeg2 clips to avi lagarith, using this function in the avisynth script:
    Code:
    ConvertToRGB(matrix="pc.601", interlaced=true) # assuming I didn't deinterlace
    then nothing gets squished, but everything gets streched, but it's better for grading, then I export the sequence to avi lagarith rgb, and before I frameserve this avi to x264, I'll have to convert to YV12... I wonder if this will either strech or clip something...

    Ok, so you are saying that it's far better to work with the camcorder's original mpeg2 clips, natively, in premiere pro, in a timeline that matches the specifications of the original clips. That way, levels won't get squished or streched, I can do color correction on the original information, if I find illegal levels I can adjust them to legal levels, and I can render to any format (dvd, web, etc). I totally agree, but I have two questions:

    1. Let's say the premiere sequence has 20 clips, and you are rendering it to an intermediate, an then to H.264 progressive with x264; how would you apply minimal denoise to 17 clips, and heavy denoise to 3 clips ?

    2. Let's say you want to render the sequence to an intermediate avi file, using the lagarith codec, because you want to bypass adobe media encoder and use your favorite encoding tools; sequence is RGB, intermediate file is RGB, so there is no conversion; but when you encode the intermediate with x264, you have to convert from RGB to YV12; is 0-255 going to be mapped to 16-240 after this conversion, and levels will get squished, decreasing the contrast? or the levels won't get squished, nor streched, and only illegal levels will get clipped ?
    Last edited by codemaster; 1st May 2012 at 13:28.
    Quote Quote  
  11. Originally Posted by codemaster View Post
    So if I convert the mpeg2 clips to avi lagarith, using this function in the avisynth script:
    Code:
    ConvertToRGB(matrix="pc.601", interlaced=true) # assuming I didn't deinterlace
    then nothing gets squished, but everything gets streched, but it's better for grading, then I export the sequence to avi lagarith rgb, and before I frameserve this avi to x264, I'll have to convert to YV12... I wonder if this will either strech or clip something...
    It's pros/cons. It's not all good. When you are dealing with 8bit format, the more changes you do when grading, the more quantization and banding occur. So if you use full range, but then have to make larger adjustment to compensate, it's not necessarily better - it depends how much you have to push/pull stuff

    If you are in RGB, color correct in premiere, export RGB (or frameserve RGB), then ConvertToYV12 with Rec matrix will do the exact opposite: RGB 0,0,0-255,255,255 gets mapped to Y' 16 CbCr16-240 . This is what you want to do in most cases

    Ok, so you are saying that it's far better to work with the camcorder's original mpeg2 clips, natively, in premiere pro, in a timeline that matches the specifications of the original clips. That way, levels won't get squished or streched, I can grade the original information, if I find illegal levels I can adjust them to legal levels, and I can render to any format (dvd, web, etc). I totally agree, but I have two questions:
    Yes, but more for future considerations (options) reasons than quality issues . If you've already deinterlaced, resized etc.... you limit your options

    Another reason is why waste processing on stuff you're going to cut out anyway? Presumably you are editing this footage... (QTGMC, temporal denoisers are fricking slow!!!) So you save lots of time

    1. Let's say the premiere sequence has 20 clips, and you are rendering it to H.264 progressive with x264; how would you apply minimal denoise to 17 clips, and heavy denoise to 3 clips ?
    Export your composition out of premiere, and use Trim() , ApplyRange() or one of the other techniques explained in your other thread

    (you already asked this question, it was already answered with several options)

    I wouldn't denoise it before, because often when you grade, you reveal noise in shadows, that you missed with the denoiser the 1st time. You end up going back & forth & wasting time. Also you waste time denoising, deinterlacing stuff you're going to cut out anyway.

    If they are separate clips that you are exporting, then apply the denoise with different settings to each clip separately



    2. Let's say you want to render the sequence to an intermediate avi file, using the lagarith codec, because you want to bypass adobe media encoder and use your favorite encoding tools; sequence is RGB, intermediate file is RGB, so there is no conversion; but when you encode the intermediate with x264, you have to convert from RGB to YV12; is 0-255 going to be mapped to 16-240 after this conversion, and levels will get squished, decreasing the contrast? or the levels won't get squished, nor streched, and only illegal levels will get clipped ?
    See above for the Rec conversion. Presumably you already corrected for superbrights/darks

    When you view a video, you are viewing RGB, not YCbCr. Most displays will use Rec709 or 601 for that conversion YCbCr=>RGB. So everything will look right in terms of levels (it's just doing the reverse of what you did), it will look as you had it in premiere's program monitor . Illegal levels (superbrights/darks) are usually not seen by displays - because they use Rec conversion (it will look like 1 black bar, or 1 white bar instead of detail) - ie. they are clipped on display. But since you already fixed levels in premiere, no problem.
    Last edited by poisondeathray; 1st May 2012 at 13:42.
    Quote Quote  



Similar Threads

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