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

[feisty2]

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]

feisty2: wrong thread. But if you are in a hurry, go fix nnedi3 (http://forum.doom9.org/showthread.php?p=1507235#post1507235).

Done this time !

[jpsdr]

@colours,feisty2,Gavino
If you have time, can you take a lool here (http://forum.doom9.org/showpost.php?p=1733626&postcount=157) ?
:thanks:

[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.php?p=1879189#post1879189 and https://forum.doom9.org/showthread.php?p=1879764#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

https://i.ibb.co/tD97BzC/01-Source.png https://i.ibb.co/87wYKbF/02-avsp-0-50.png https://i.ibb.co/qFwFKpz/03-avsp-0-25.png https://i.ibb.co/88xknjd/04-avsp-0-0.png

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