Resizing horizontally only

[kolak]

Can I scale interlaced (or hybrid nature interlaced+progressive) source from 1920x1080 to 1440x1080 using standard approach (like it would be progressive source)?

[Stereodude]

What do you mean by "standard approach"?

What's the pixel color format?

I think for 4:2:0, you can't (unless the resize filter has an interlaced option). For 4:2:2, maybe.

[scharfis_brain]

As long as you're doing horizontal-only operations you do not need to care about interlacing.

i.e. enlarging from 1440 to 1920 would be as simple as:

spline36resize(1920,last.height)

Resizers internally always do two operations: horizontal and vertical resizing.
If one dimension is kept, its scaling operation will be skipped.

[kolak]

As long as you're doing horizontal-only operations you do not need to care about interlacing.

i.e. enlarging from 1440 to 1920 would be as simple as:

spline36resize(1920,last.height)

Resizers internally always do two operations: horizontal and vertical resizing.
If one dimension is kept, its scaling operation will be skipped.

I assume the same- it should not cause any problems.

[kolak]

What do you mean by "standard approach"?

What's the pixel color format?

I think for 4:2:0, you can't (unless the resize filter has an interlaced option). For 4:2:2, maybe.

Source is 4:2:2. Standard means normal scale as for progressive source.

[johnmeyer]

Lots of scripts for interlaced footage which DO deinterlace (which you are not doing) perform the horizontal scaling before the deinterlacing, using the code scharfis_brain provided.

So yes, you can scale interlaced video horizontally without first deinterlacing.

[wonkey_monkey]

Resizers internally always do two operations: horizontal and vertical resizing.
If one dimension is kept, its scaling operation will be skipped.

Hmm... is that strictly the correct thing to do? I mean it's true that Avisynth does that, but should it?

Bicubicresize, with default parameters, actually blurs the image - even at the central point, the interpolation curve has some non-zero lobes. This means that a resize step should not be skipped, even if there is no change in scale or pixel offset along that dimension.

(I did once try to argue that the default parameters of bicubicresize should be changed because of this, but backwards compatability and all that...)

Edit: https://forum.doom9.org/showthread.php?p=1906481#post1906481

[real.finder]

Hmm... is that strictly the correct thing to do? I mean it's true that Avisynth does that, but should it?

Bicubicresize, with default parameters, actually blurs the image - even at the central point, the interpolation curve has some non-zero lobes. This means that a resize step should not be skipped, even if there is no change in scale or pixel offset along that dimension.

(I did once try to argue that the default parameters of bicubicresize should be changed because of this, but backwards compatability and all that...)

Edit: https://forum.doom9.org/showthread.php?p=1906481#post1906481

well, it should not do horizontal step when new width = original width (which used in bob)

so for what the OP ask, it's opposite, unless with http://avisynth.nl/index.php/TurnLeft

[wonkey_monkey]

well, it should not do horizontal step when new width = original width (which used in bob)

It should, to be consistent. If you add src_top = 0.00000001, you'll get a noticeably different result, which should not happen.

[real.finder]

It should, to be consistent. If you add src_top = 0.00000001, you'll get a noticeably different result, which should not happen.

z_bicubicresize (https://forum.doom9.org/showthread.php?t=173986) did same?

[wonkey_monkey]

z_bicubicresize (https://forum.doom9.org/showthread.php?t=173986) did same?

Yes, same problem. It shouldn't.

Not sure if that's z.lib's fault, or whether it calls the same problematic Avisynth+ code internally.

[real.finder]

Yes, same problem. It shouldn't.

Not sure if that's z.lib's fault, or whether it calls the same problematic Avisynth+ code internally.

z_bicubicresize is independent filter that use z.lib

that mean even the VS (which use z.lib) has the same problem

[kolak]

It's actually going to be done in ffmpeg.

[poisondeathray]

It's actually going to be done in ffmpeg.

?? what does ffmpeg have anything to do with this ?

If you were referring to ffmpeg zscale, it's based on zimg (as are vapoursynth internal resizer, and avsresize)

https://github.com/sekrit-twc/zimg

[poisondeathray]

z_bicubicresize is independent filter that use z.lib

that mean even the VS (which use z.lib) has the same problem

This is generally true, but there can be differences in the snapshot of the zimg library, and when it was compiled

=> VS version does not have that behaviour as of R48 (dated Oct 31,2019) ie. no diff when adding src_top = 0.00000001 , but z_BicubicResize does . The avsresize version is r1d, dated 2018-03-21

I test avs version with this

a=colorbars()
b=a.bicubicresize(640, 480, src_top = 0.00000001)
c=a.ConvertToPlanarRGB().z_BicubicResize(640, 480, src_top = 0.00000001)

Overlay(a,b , mode="Difference", pc_range=true)
#Overlay(a,c , mode="Difference", pc_range=true)
Levels(127, 1, 129, 0, 255, false)



I test vpy version, but I'm using older R48 version. I'm using the colorbars generated with avisynth colorbars() only (you can load avisynth script into vapoursynth with avisource)



import vapoursynth as vs
core = vs.get_core()
c = core.avisource.AVISource(r'colorbars.avs')
r = core.resize.Bicubic(c, width=640,height=480, src_top = 0.00000001)

d = core.std.MakeDiff(c,r, planes=[0,1,2])
da = core.std.Levels(d, min_in=127, max_in=129, gamma=1, min_out=0, max_out=255, planes=[0,1,2])
da.set_output()

[real.finder]

then avsresize need to update to last zimg

[StvG]

https://github.com/sekrit-twc/zimg/commit/5841b66c2e9ee12d29cf19723e9be44234e19eae

Use bicubic a=0, b=0.5 for z_... and you will get the same result as vs.

[wonkey_monkey]

https://github.com/sekrit-twc/zimg/commit/5841b66c2e9ee12d29cf19723e9be44234e19eae

Use bicubic a=0, b=0.5 for z_... and you will get the same result as vs.

Common sense prevails! :D

(any premature skipping should still be fixed though)

[kolak]

?? what does ffmpeg have anything to do with this ?

If you were referring to ffmpeg zscale, it's based on zimg (as are vapoursynth internal resizer, and avsresize)

https://github.com/sekrit-twc/zimg

It's part of the original question. I never mentioned, that I will be using ffmpeg. Maybe I should.
I would still assume results should be the same.