1080p 4:2:0 to 540p 4:4:4 without resizing chroma?

[Dogway]

Yes, I tested yesterday and found out, also tested Dither_resize16() and luckily cretindesalpes got that covered (matches results from Resize8() ), so my panic level decreased.

It just feels odd that a "restoration" program degrades an image in some form, and nobody cares. Same with nnedi

Originally Posted by colours

I meant 0.5 luma output sample, which equals to 0.25 chroma output sample. But our input chroma is not subsampled, so shifting it by x luma input samples (in this case x = 0.5·output_width/input_width) is the same as shifting it by x chroma input samples. There's no need to divide by two.

I still need to wrap up my mind on all this, but I had this stuck on my mind:

Originally Posted by Gavino

The resizer core is designed to preserve the position of the image centre, and it does this for both luma and chroma independently.

That means MPEG1 placement which has an offset of (this is the tricky part) one quarter of a chroma pixel in relation to luma for a MPEG2 siting. image This is subsampled, as the output of the example we are talking 4:4:4->4:2:0

Not saying it's wrong just that it feels I'm missing something. I will look onto this better tomorrow. edit: I think I got it, src_left is not applied before or after, just at the same time as the resizing, it's hard to grasp but I think I figured it out.

[TheSkiller]

Originally Posted by Dogway

Yes, I tested yesterday and found out, also tested Dither_resize16() and luckily cretindesalpes got that covered

Didn't know that. Indeed, Dither_Resize16 is correct. Nice!

ImageSource("PM5544_with_non-PAL_signals.png")
ConvertToYV16()
Dither_convert_8_to_16()
Dither_Resize16(Width*32, 576, kernel="Spline36")
Ditherpost(mode=-1)
ConvertToRGB()
Spline36Resize(Width/32, height)
Crop(240,460,-240,-30)
PointResize(Width*2, Height*2) #for better visibility
Subtitle("Dither_Resize16")

[feisty2]

Those two are the same expression...
Do the 10 years old kid math urself
Edit: 0.25-0.25/(out/in)=0.25(1-1/(out/in))=0.25(1-in/out)

[Dogway]

Originally Posted by feisty2

Those two are the same expression...
Do the 10 years old kid math urself
Edit: 0.25-0.25/(out/in)=0.25(1-1/(out/in))=0.25(1-in/out)

How old are you?

[jpsdr]

Originally Posted by Dogway

feisty2: wrong thread. But if you are in a hurry, go fix nnedi3.

I've tried.

Any test, feedback, comment on the formula used in the code are welcomed .

You can find informations here.

[kuchikirukia]

About the resize chroma problem, is there a way to write a script to get Resize8 to catch all calls to Spline36resize? Since I have tons of scripts that use Spline36resize.

And is the replacement of Lanczos with Spline36 here:

    kernel   = Default(kernel,   yup ? "Lanczos4" : "Spline36")
    kernel_c = Default(kernel_c, cup ? "Lanczos"  : "Spline36")

... all I need to change for my Resize8 to use Spline36 for everything as default?

[luquinhas0021]

My dear friend, how are you thinking about convert YCbCr 4:2:0 to YCbCr 4:4:4? As I know, YCbCr subsampling makes a lot of pixels have only Y value. So how recover the miss information?

[Wilbert]

Did you even bother to read the thread? They scale the luma plane by a factor of two (guess some prefer to use Spline36Resize for that) and they adjust the offset of the chroma with respect to the luma.

Nb, when there is subsampling it means that several pixels share the same chroma, and not that some don't have chroma.

[luquinhas0021]

Wilbert, thank you so much for you correct me about subsampling, but I guess you didn't get me completely! if I subsample from YUV 444 to YUV 420, for example, I will lost so much chroma information, so will be praticaly impossible I recover that. Considering that subsample generates artifacts, in better case, the interpolation to YUV 444 will maintain that, without creates more (What didn't occur with Spline36). So, even you try convert to YUV 444, probably you will never have a true 444.

[poisondeathray]

Originally Posted by luquinhas0021

Wilbert, thank you so much for you correct me about subsampling, but I guess you didn't get me completely! if I subsample from YUV 444 to YUV 420, for example, I will lost so much chroma information, so will be praticaly impossible I recover that. Considering that subsample generates artifacts, in better case, the interpolation to YUV 444 will maintain that, without creates more (What didn't occur with Spline36). So, even you try convert to YUV 444, probably you will never have a true 444.

That is not what the topic is about - you are not "recovering" information, you are downscaling the Y' channel



YUV 420 at 1920x1080 means Y is 1920x1080, but U,V are 960x540. You are downscaling Y to match U, V

Y - 960x540
U - 960x540
V - 960x540

That is 4:4:4

Similarly , if you had UHD 4:2:0, you can downscale to 1080 4:4:4

Nothing is "true 4:4:4" unless it's CG , or oversampled by a large margin. Even high end expensive cameras that shoot 4:4:4 don't really have 4:4:4 resolution when measured on zone plates. Effective resolution is lost due to processing, debayering. Only if you oversample and downscale, can you get true 4:4:4

[feisty2]

Originally Posted by poisondeathray

Nothing is "true 4:4:4" unless it's CG , or oversampled by a large margin. Even high end expensive cameras that shoot 4:4:4 don't really have 4:4:4 resolution when measured on zone plates. Effective resolution is lost due to processing, debayering. Only if you oversample and downscale, can you get true 4:4:4

or high budget movies shot on film and scanned to digital and that would be native 444

[jpsdr]

Originally Posted by Dogway

feisty2: wrong thread. But if you are in a hurry, go fix nnedi3.

Done this time !

[jpsdr]

@colours,feisty2,Gavino
If you have time, can you take a lool here ?

[jpsdr]

This very simple script :

r = blankclip(width=8,height=8,pixel_type="YV24",color_yuv=$FF0000).ConvertToYV12(ChromaOutPlacement="MPEG2")
g = blankclip(width=8,height=8,pixel_type="YV24",color_yuv=$00FF00).ConvertToYV12(ChromaOutPlacement="MPEG2")

stackhorizontal(r,g)
o=stackvertical(last,last.fliphorizontal())
X0=Width(o)
Y0=Height(o)

a=nnedi3_rpow2(o,rfactor=32,cshift="spline36resize",csresize=false)

X1=Width(a)
Y1=Height(a)

shift=0.25*(1.0-(Float(X0)/Float(X1)))
Y = ConvertToY8(o).Spline36Resize(X1, Y1)
U = UToY8(o).Spline36Resize(X1/2,Y1/2, src_left=shift)
V = VToY8(o).Spline36Resize(X1/2,Y1/2, src_left=shift)
b = YToUV(U, V, Y)

c=Spline36Resize(o,X1,Y1)

interleave(b,c,a)

shows obviously for me that something is wrong with the actual formula. You can add a Resize8 also if you want, you'll have the same result.

I've tried to imagine the resizing somehow a resampling, i've the following guess.
If Out>In and Out/In is an integer n, you'll have each n pixels of the output identical to the input, and so finaly everythings ends up again in the good place.
If In>Out and In/Out is an integer n, you'll have each n pixel of the input wich is the ouput, and so finaly everythings ends up again in the good place.

So, my guess is :
If the ration Out/In (or In/Out) is an integer, the adjustment is 0.
If f(x) is the value of the chroma adjustement, i think we have a periodic function with a period of 1, with f(n)=0 if n is integer, with probably its peak value at f(0.5).
I think the formula is not so obvious as it's been described.

Edit :
You can also see the issue with decreasing :

r = blankclip(width=128,height=128,pixel_type="YV24",color_yuv=$FF0000).ConvertToYV12(ChromaOutPlacement="MPEG2")
g = blankclip(width=128,height=128,pixel_type="YV24",color_yuv=$00FF00).ConvertToYV12(ChromaOutPlacement="MPEG2")

stackhorizontal(r,g)
o=stackvertical(last,last.fliphorizontal())
X0=Width(o)
Y0=Height(o)

a=Spline36Resize(o,16,16)

X1=Width(a)
Y1=Height(a)

shift=0.25*(1.0-(Float(X0)/Float(X1)))
Y = ConvertToY8(o).Spline36Resize(X1, Y1)
U = UToY8(o).Spline36Resize(X1/2,Y1/2, src_left=shift)
V = VToY8(o).Spline36Resize(X1/2,Y1/2, src_left=shift)
b = YToUV(U, V, Y)

c=PointResize(o,16,16)

interleave(b,a,c)

PointResize(512,512)

EDIT :
I was often saying unless i'm doing something wrond, and i was.
My mistake was this :

r = blankclip(width=128,height=128,pixel_type="YV24",color_yuv=$FF0000).ConvertToYV12(ChromaOutPlacement="MPEG2")
g = blankclip(width=128,height=128,pixel_type="YV24",color_yuv=$00FF00).ConvertToYV12(ChromaOutPlacement="MPEG2")

stackhorizontal(r,g)
o=stackvertical(last,last.fliphorizontal())

when it should have done

r = blankclip(width=128,height=128,pixel_type="YV24",color_yuv=$FF0000)
g = blankclip(width=128,height=128,pixel_type="YV24",color_yuv=$00FF00)

stackhorizontal(r,g)
o=stackvertical(last,last.fliphorizontal()).ConvertToYV12(ChromaOutPlacement="MPEG2")

with this last made properly, i've been able to verify the rightness if the formula.

All my applogies, and thanks for all the informations on this thread.

[dREV]

Sorry for reviving a old thread.

Hello, I wanted to simply ask if this is still the route to use for a similar script but with changes as the script I use can't use ConvertToY8, results are to be encoded to HEVC 10 bit and 12 bit.

Avisynth+ x86
ly = GradFun3mod(thr=0.35, yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)

AviSynth+ x64
ly = GradFun3mod(thr=0.35, yuv444=true, resizer="DebilinearMTM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)

Sorry for writing it twice for both versions but I want to archive in case I ever lose my scripts and also I'm still using x86 transitioning to x64 bit version.

I've posted elsewhere with these examples including to the above person (jpsdr and real.finder) and no correction was given concerning the script.
For the curious they were at https://forum.doom9.org/showthread.p...89#post1879189 and https://forum.doom9.org/showthread.p...64#post1879764

Just want to be certain as I maybe mistaking it for another resizer that said something that shifting was no longer necessary to do. Uncertain if it was speaking on just a simple resize without the above luma+chroma.

Examples from using the above script (x86 version) - Progressive 23.976 fps. Order left to right: source | 0.50 | 0.25 | 0.0



And any other information that may help me understand would be appreciate if you don't mind.