Converting Blu-Ray YUV to RGB and back to YUV?

[killerteengohan]

I want to adjust the overall brightness of a video of mine and I am using this to do it.

converttorgb32(matrix="Rec709")
RGBAdjust(rg=1.2, gg=1.2, bg=1.2, rb=-4, gb=-4, bb=-4, r=1.1, g=1.1, b=1.1)

I originally did not want to convert to RGB, but it works perfectly and gives result much better than I could achieve with tweak, smoothtweak, coloryuv or a combination of those 3. In fact, it was suggested to me on here long ago.


I am using convertorgb which should be 100% identical with the colors, and just like the source until I changed it some with with RGBAdjust. The problem is, I need to put it back into YUV like the source video. To my understanding converting to YUV from RGB will distort the colors some or change something.

What is the best way to convert back from RGB into YUV and get as little distortion or change as possible?

[killerteengohan]

The source says YUV 4:2:0 but the RGB I converted to is 4:4:4:4 isn't it?

Would ConvertToVY12(matrix="Rec709") or ConvertToYV24(matrix="Rec709") be better in this case?

coloryuv(analyze=true) is showing me slightly different U and V numbers and I'm not sure which would be more accurate.

[jagabo]

ConvertToYV24(matrix="rec709") would be more accurate but YV24 isn't supported by much of anything. You're going to have to accept the losses of ConvertToYV12(matrix="rec709") if you want compatibility with anything else in the world.

By the way, this will be pretty close to your RGB adjustments:

ColorYUV(levels="TV->PC")
ColorYUV(gain_y=26, off_y=-4, gamma_y=51, cont_u=26, cont_v=26)
ColorYUV(levels="PC->TV")

without the chroma blurring incurred by YV12 to RGB to YV12 conversion.

[SD70ACEJM]

ConvertToYV24(matrix="rec709") would be more accurate but YV24 isn't supported by much of anything. You're going to have to accept the losses of ConvertToYV12(matrix="rec709") if you want compatibility with anything else in the world.

By the way, this will be pretty close to your RGB adjustments:

ColorYUV(levels="TV->PC")
ColorYUV(autogain=true, autowhite=true)
ColorYUV(levels="PC->TV")

without the chroma blurring incurred by YV12 to RGB to YV12 conversion.

jagabo is there a way I can adjust ColorYUV(gain_y=26, off_y=-4, gamma_y=51, cont_u=26, cont_v=26) so where it doesn't affect the red color so much?

[jagabo]

I was looking at a video with mostly dark colors when I worked that out. I didn't notice at the time, but It does lead to over-saturation of brighter areas. The general issue is that when you increase Y you also need to increase the saturation (cont_u, cont_v) to retain the color. But with a gamma adjustment lower Y values increase by more the higher Y values. So you need to increase the saturation more in the darker areas, less in the higher areas. You might try setting cont_u and cont_v to lower values. Or you can mix two videos with Overlay(), one with the increased saturation, one without, and a brightness mask to control it.

[SD70ACEJM]

I was running a test encode while I was asking, however, using StaxRip 2.0.6.0 the encode came out all black. Today has been a crappy encoding day.

[killerteengohan]

Jagabo, what would you say is close to my RGB adjustments if this was the settings I chose to go with, and I was going to use ColorYUV.
RGBAdjust(rg=1.23, gg=1.23, bg=1.23, rb=-2, gb=-2, bb=-2, r=1.03, g=1.03, b=1.03)

I changed to those settings because the older rgb ones were adding too much contrast for my liking, and rb, gb, and bb were crushing/removing some super dark things in really dark areas.

"without the chroma blurring incurred by YV12 to RGB to YV12 conversion."
Couldn't I just use a chroma sharpener to undo this?

[poisondeathray]

"without the chroma blurring incurred by YV12 to RGB to YV12 conversion."
Couldn't I just use a chroma sharpener to undo this?

No.

But you can avoid the chroma blurring by YUV 4:2:0 <=> RGB conversions in avisynth by either using avsresize(zimg) point resize, or shifting the chroma with the internal point resizer

Anything other than nearest neighbor ("pointresize" in avisynth) for the chroma resizing will blur the chroma. The default is bicubic

But avisynth's internal resizer has shifting because of it's chroma sample location interpretation is different than other programs. You can use use MergeChroma as a workaround to shift the chroma

#Progressive YV12 source

ConvertToYV24(matrix="rec709", chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1))
ConvertToRGB24()

#YOUR RGB24 filters here

ConvertToYV12(matrix="rec709", chromaresample="point")

[jagabo]

#Progressive YV12 source

ConvertToYV24(matrix="rec709", chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1))
ConvertToRGB24()

#YOUR RGB24 filters here

ConvertToYV12(matrix="rec709", chromaresample="point")

Nice "trick".

[killerteengohan]

I tried that poisondeathray and it looks like it altered the colors. Kinda like if I were to convert rec709 into rec.601.
https://slow.pics/c/ow6IkaRu

Not sure why its doing that though. Convert to RGB24() seems to be the cause of it though because taking it out fixes the colors again.

EDIT: I fixed it by simply adding in matrix="rec709" to the convertorgb24() line. Not sure how I didn't think of that right away.

This does indeed look better to me. I can see the blurring or alterations that were going on after trying this and comparing to the other. It's kind of minor, but everything is kept more in place with this method.


Would adding chromaresample="point" to the converttorgb24(matrix="rec709") be better as well? I noticed it's in the YV conversions but you did not put it in the RGB one for whatever reason.

[poisondeathray]

EDIT: I fixed it by simply adding in matrix="rec709" to the convertorgb24() line.

Yes it's supposed to be 709, for all of them sorry typo

This does indeed look better to me. I can see the blurring or alterations that were going on after trying this and comparing to the other. It's kind of minor, but everything is kept more in place with this method.

It's more dramatic if you do more than one YV12=>RGB=>YV12=>RGB...etc... conversion steps. But in reality you rarely need to go to RGB more than once.

Would adding chromaresample="point" to the converttorgb24(matrix="rec709") be better as well? I noticed it's in the YV conversions but you did not put it in the RGB one for whatever reason.

It's irrelevant at that stage, because you are in YV24 or YUV4:4:4 now . The Y,U,V planes are all the same size now, just like R,G,B. So chroma resampling is not applicable . chromaresample="blah" just controls how the U,V planes get scaled . But nothing is scaled from YUV4:4:4 to RGB

[killerteengohan]

It's irrelevant at that stage, because you are in YV24 or YUV4:4:4 now . The Y,U,V planes are all the same size now, just like R,G,B. So chroma resampling is not applicable . chromaresample="blah" just controls how the U,V planes get scaled . But nothing is scaled from YUV4:4:4 to RGB

After examining close up, it didn't do anything but make the overall image appear minimally sharper. With it makes it sharper than the source, without it makes it about the same as the source sharpness wise. I actually prefer it without it.

Thanks, that tip made this look quite a bit better, and it was indeed more accurate of a conversion.

[poisondeathray]

It's irrelevant at that stage, because you are in YV24 or YUV4:4:4 now . The Y,U,V planes are all the same size now, just like R,G,B. So chroma resampling is not applicable . chromaresample="blah" just controls how the U,V planes get scaled . But nothing is scaled from YUV4:4:4 to RGB

After examining close up, it didn't do anything but make the overall image appear minimally sharper. With it makes it sharper than the source, without it makes it about the same as the source sharpness wise. I actually prefer it without it.

Thanks, that tip made this look quite a bit better, and it was indeed more accurate of a conversion.

It doesn't do anything except a proper point resize for the chroma.

The same pixels that you duplicated to get YUV 4:4:4 are dropped when you go back to YUV 4:2:0. So you're left with what you started with.

It does not make it any "sharper" for the chroma. It's the same as the source.

The only loss is from the rounding differences and 8bit YUV=>RGB=> conversion, and whatever your RGB filters did.
(Some RGB filters or operations might accentuate existing problems in the source, or cause new problems - Then blurring the chroma actually might be preferrable in those cases. For example if you add RGB text or graphics, then point sample back to YV12 isn't pretty)

But the default avisynth ConvertToRGB(matrix="rec709"), then ConvertToYV12(Matrix="rec709") 100% definitely makes the chroma more blurry. It uses either bilinear or bicubic for the UV scaling (I don't recall which one). So it's impossible not to lose quality and become more blurry because it samples a radius of pixels. Whereas point resize is pixel perfect duplication, pixel perfect discarding the ones you just duplicated.

You should notice it more on fine colored text, and actually, some types animation and cartoons . 1 conversion usually isn't that bad , but after a few, it becomes bad quickly

[jagabo]

The ConvertToRGB24() on line 5 of pdr's script fragment should be ConvertToRGB(matrix="rec709").

[killerteengohan]

But the default avisynth ConvertToRGB(matrix="rec709"), then ConvertToYV12(Matrix="rec709") 100% definitely makes the chroma more blurry. It uses either bilinear or bicubic for the UV scaling (I don't recall which one). So it's impossible not to lose quality and become more blurry because it samples a radius of pixels. Whereas point resize is pixel perfect duplication, pixel perfect discarding the ones you just duplicated.

You should notice it more on fine colored text, and actually, some types animation and cartoons . 1 conversion usually isn't that bad , but after a few, it becomes bad quickly

I don't really need to do multiple conversions. I have a good eye and can see plain as day the differences between the two with the one conversion. It's even easier when you screenshot and zoom in, then flip back and forth between zoomed images. Red areas are the easiest to notice.

It's not a big deal that I am using RGB32 instead of RGB24 is it? I heard that is supposedly faster.

"Using the RGB32 video format provides in modern processors faster access to video data because the data is aligned to machine's word boundaries. For this reason many applications use it instead of RGB24 even when there is no transparency mask information in the fourth (A) byte, since in general the improved processing speed outweighs the memory overhead introduced by the unused A byte per pixel."

I'm not 100% sure what memory overhead means in this case, but it sounds okay to use?

[poisondeathray]

It's not a big deal that I am using RGB32 instead of RGB24 is it? I heard that is supposedly faster.

"Using the RGB32 video format provides in modern processors faster access to video data because the data is aligned to machine's word boundaries. For this reason many applications use it instead of RGB24 even when there is no transparency mask information in the fourth (A) byte, since in general the improved processing speed outweighs the memory overhead introduced by the unused A byte per pixel."

I'm not 100% sure what memory overhead means in this case, but it sounds okay to use?

It's not a big deal to use either.

You can measure the speed and memory usage with avsmeter to see which is faster

[_Al_]

Never mind, I said what was actually quoted within post above. Interleaved vs. planar. RGB adjust creates a new values for each plane separately.

[_Al_]

An example for rough translation of RGBadjust to Vapoursynth.
Any RGB bitdepth, including float, can be used.
I hope that that sequence, multiple, bias, gamma is what it suppose to be

import vapoursynth as vs
core = vs.core
yuv = core.lsmas.LibavSMASHSource('video.mp4')
#format could be RGB24 (8bit) to RGB48 (16bit) or RGBS (floating point)
rgb = core.resize.Point(yuv, format = vs.RGBS, matrix_in_s = '709')

def RGBadjust(rgb, r = 1, g = 1, b = 1, rb = 0, gb = 0, bb = 0, rg = 1.0, gg = 1.0, bg = 1.0):
    type = rgb.format.sample_type
    size = 2**rgb.format.bits_per_sample
    #adjusting bias values rb,gb,bb for any RGB bit depth
    rb,gb,bb = map(lambda b: b if size==256 else size/256*b if type==vs.INTEGER else b/255.0, [rb,gb,bb])

    #x*r + rb , x*g + gb , x*b + bb
    rgb_adjusted = core.std.Expr(rgb, [f"x {r} * {rb} +", f"x {g} * {gb} +", f"x {b} * {bb} +"])

    #gamma per channel
    planes = [core.std.ShufflePlanes(rgb_adjusted, planes=p,  colorfamily=vs.GRAY)  for p in [0,1,2]]
    planes = [core.std.Levels(planes[p], gamma=g) if not g==1 else planes[p] for p, g in enumerate([rg, gg, bg])]
    rgb_adjusted = core.std.ShufflePlanes(planes, planes=[0,0,0], colorfamily = vs.RGB)
    return rgb_adjusted

rgb_adjusted = RGBadjust(rgb, r = 1.03, g  = 1.03, b = 1.03,
                             rb = -2.0, gb = -2.0, bb= -2.0,
                             rg = 1.25, gg = 1.2,  bg=1.5)

yuv_adjusted = core.resize.Point(rgb_adjusted, format = vs.YUV420P8, matrix_s ='709')
yuv_adjusted.set_output()