z.lib resizers for AviSynth+

[guest]

I am sometimes lazy but you could at least read the DG thread and the included txt file. :rolleyes:

I am sometimes lazy too, and I have actually read both, but it still didn't really make too much sense to me...sorry.

Examples:

Apply 3D LUT to clip obtained from BlankClip:

loadplugin("...\dgcube.dll")
blankclip(pixel_type="RGBP16",color=$ff0000)
DGCube("...\test.cube")
converttoyuv420()

Apply 3D LUT to HDR10 PQ clip obtained from DGSource():

loadplugin("...\dgdecodenv.dll")
loadplugin("...\avsresize.dll")
loadplugin("...\dgcube.dll")
dgsource("THE GREAT WALL.dgi")
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:full", resample_filter_uv="spline64", dither_type="error_diffusion")
DGCube("PQ_to_BT709_slope.cube", fullrange=true, interp="tetrahedral")
z_ConvertFormat(pixel_type="YUV422P10", colorspace_op="rgb:std-b67:2020:full=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

I was hoping that someone might provide some helpful info.

What's "BlankClip" ??

[tormento]

I am sometimes lazy too
Now DGCube doesn't need AVSResize anymore. Just use

loadplugin("...\dgdecodenv.dll")
loadplugin("...\dgcube.dll")
dgsource("THE GREAT WALL.dgi")
DGCube("PQ_to_BT709_slope.cube", fullrange=false)

and you will have just to dither bitdepth down according to your chosen encoder (8 or 10 bit) or just leave as it is and the encoder will to its best.

[guest]

Now DGCube doesn't need AVSResize anymore. Just use

loadplugin("...\dgdecodenv.dll")
loadplugin("...\dgcube.dll")
dgsource("THE GREAT WALL.dgi")
DGCube("PQ_to_BT709_slope.cube", fullrange=false)

and you will have just to dither bitdepth down according to your chosen encoder (8 or 10 bit) or just leave as it is and the encoder will to its best.

Thankyou so much tormento..

However, it still doesn't work for me in RipBot264, when "testing" with AVSMeter, it doesn't Start...

Having said that, do I need to use a dgsource ".dgi" for this work ??

'Cause I don't use that.

Cheers

[DTL]

Wiki http://avisynth.nl/index.php/DGCube

lists first input argument as standard AVS clip - nothing any special (only limited to possible formats list) -
clip =
Input clip; the filter receives and delivers either RGBP16 or YUV420P16 color space.

So it should work with any AVS clip of the specified format. Not only loaded by dgsource() from .dgi file.

" it still doesn't work for me in RipBot264, when "testing" with AVSMeter, it doesn't Start..."

May be input format not as required. Try to add conversion before - like
ConvertBits(16)
ConvertToYUV420()

[guest]

Wiki http://avisynth.nl/index.php/DGCube

lists first input argument as standard AVS clip - nothing any special (only limited to possible formats list) -
clip =
Input clip; the filter receives and delivers either RGBP16 or YUV420P16 color space.

So it should work with any AVS clip of the specified format. Not only loaded by dgsource() from .dgi file.

" it still doesn't work for me in RipBot264, when "testing" with AVSMeter, it doesn't Start..."

May be input format not as required. Try to add conversion before - like
ConvertBits(16)
ConvertToYUV420()

Interesting that you suggest the conversions, 'cause in my first post about this

https://forum.doom9.org/showthread.php?p=1973391#post1973391

The avscube script has those calls.

So it might need a combination of that & the DGCube script that tormento suggested.

EDIT:

Maybe this :-

LoadPlugin("%AVISYNTHPLUGINS%\dgdecodenv\dgdecodenv.dll")
LoadPlugin("%AVISYNTHPLUGINS%\dgcube\dgcube.dll")
video=ConvertBits(video, 16)
video=ConvertToPlanarRGB(video)
video=Cube(video, "%AVISYNTHPLUGINS%\3D LUTs\6500.CUBE", fullrange=false)
video=Converttoyuv420(video)

[DTL]

If your source is not higher 4:2:0 sampling - it may be no reason to convert to RGBP16 to make LUT processing if plugin accept YUV420P16 (though it may be created inside plugin). So the YUV420P16 suggested as using less RAM and may be less distortive.
Script in that post uses conversion to RGBP16 before LUT.

So the script to try:

loadplugin("...\dgcube.dll")
__any_source_load__
ConvertBits(16)
ConvertToYUV420()
DGCube("PQ_to_BT709_slope.cube", fullrange=false)


Convert* are sort of fail-safe processing so if format is not as required it perform conversion or pass-through. So no need to remove if your source already in YUV420P16.

[guest]

If your source is not higher 4:2:0 sampling - it may be no reason to convert to RGBP16 to make LUT processing if plugin accept YUV420P16 (though it may be created inside plugin). So the YUV420P16 suggested as using less RAM and may be less distortive.
Script in that post uses conversion to RGBP16 before LUT.

So the script to try:

loadplugin("...\dgcube.dll")
__any_source_load__
ConvertBits(16)
ConvertToYUV420()
DGCube("PQ_to_BT709_slope.cube", fullrange=false)


Convert* are sort of fail-safe processing so if format is not as required it perform conversion or pass-through. So no need to remove if your source already in YUV420P16.

Thanks DTL, I have changed my script (has to slightly different for RipBot264, and will test it tomorrow, and will report back :)

EDIT:- OK, I'm not having any success with this, so I will stick with the avscube option, that works for me. Thanks for your help :)

[frank]

Latest dgCube (2022.09.02) has changed params:

# Apply LUT (dgcube.dll) input full / output full RGBP16
dgCube("1000nit.cube",in="full",out="full",lut="full",interp="tetrahedral")

[TomArrow]

avsresize_r15 (https://ppp.woelkli.com/s/QN4X5AjsKcbAnTj) (pass: gjFnhBCshVL3):
- relaxed restrictions for use_props=0;
- added scene_referred parameter (default false).



If you don't want the source frame properties to be read use "use_props=0". The performance would be better than propClearAll() and checking for source frame properties.



Try the new scene_referred parameter.

Hi, could you please explain how this was achieved? I am trying to compile the code myself while referencing zimg but it's telling me that it's trying to write scene_referred into zimg_graph_builder_params but that doesn't exist there. Did you simply add the parameter to the struct and then copied it over in import_graph_params()?

[TomArrow]

Btw, I made a fork of this plugin with added ProPhotoRGB support if anyone's interested: https://github.com/TomArrow/avsresize

Needed that for a project of mine. Just use "prophoto" for transfer and/or primaries.

(The AVX512 stuff is untested)

[FranceBB]

Thanks Tom, I'm sure StvG will eventually merge the changes. :)
Speaking of which, StvG, any chance to see the project on GitHub with builds there instead of ppp.woelkli.com links + password?

p.s I noticed that both x64 and x86 have been compiled through the avsresize.sln with v143, I'll try to compile them with v141_xp too next week 'cause current x86 builds don't work on XP

[kedautinh12]

Thanks Tom, I'm sure StvG will eventually merge the changes. :)
Speaking of which, StvG, any chance to see the project on GitHub with builds there instead of ppp.woelkli.com links + password?

p.s I noticed that both x64 and x86 have been compiled through the avsresize.sln with v143, I'll try to compile them with v141_xp too next week 'cause current x86 builds don't work on XP

I don't know if it's belong to StvG
https://github.com/sekrit-twc/zimg

[StvG]

Hi, could you please explain how this was achieved? I am trying to compile the code myself while referencing zimg but it's telling me that it's trying to write scene_referred into zimg_graph_builder_params but that doesn't exist there. Did you simply add the parameter to the struct and then copied it over in import_graph_params()?

Hi, here is the patch (https://pastebin.com/raw/199xgB7y) for zimg that I'm using. I will included it in the next versions.

Edit: the patch is for zimg branch v3.0.

Speaking of which, StvG, any chance to see the project on GitHub with builds there instead of ppp.woelkli.com links + password?

I'm sorry, at the moment I don't have intention to create a github repo. Anyone is free to upload it. Btw here there is one mirror (https://github.com/realfinder/avsresize-mirror)

I don't know if it's belong to StvG
https://github.com/sekrit-twc/zimg

No, it's not mine.

[TomArrow]

Hi, here is the patch (https://pastebin.com/raw/199xgB7y) for zimg that I'm using. I will included it in the next versions.

Edit: the patch is for zimg branch v3.0.


Cool, thanks! That's pretty much the same thing I added to make it work. Glad I'm sane. I personally just used the newest version of zimg and had no issues. Or is there any specific reason to use 3.0?

[StvG]

Cool, thanks! That's pretty much the same thing I added to make it work. Glad I'm sane. I personally just used the newest version of zimg and had no issues. Or is there any specific reason to use 3.0?

No specific reason for 3.0. I'm using the branch used for the latest release.

[Dogway]

I think I found a bug, correct me if I did something wrong:
YUV420P16 source
CCTF("1886",true) # to linear
z_ConvertFormat(2560,1120,pixel_type="RGBP16",colorspace_op ="709:linear:709:auto=>rgb:srgb:170m:l")

Basically the problem is going from YUV linear to RGB non-linear regardless of other settings.

EDIT: Also seems to happen with YUV420P16 as target.

[StvG]

I think I found a bug, correct me if I did something wrong:
YUV420P16 source
CCTF("1886",true) # to linear
z_ConvertFormat(2560,1120,pixel_type="RGBP16",colorspace_op ="709:linear:709:auto=>rgb:srgb:170m:l")

Basically the problem is going from YUV linear to RGB non-linear regardless of other settings.

EDIT: Also seems to happen with YUV420P16 as target.

What if you use:
YUV420P16 source
z_ConvertFormat(colorspace_op="auto:709=>same:linear")
z_ConvertFormat(2560,1120,pixel_type="RGBP16",colorspace_op ="709:linear:709:auto=>rgb:srgb:170m:l")

[Dogway]

An error dialog with:
Error requesting frame 184
no path between colorspaces

I'm using r19

[StvG]

An error dialog with:
Error requesting frame 184
no path between colorspaces

I'm using r19


It seems _Matrix is unspecified (2). Try:
YUV420P16 source
z_ConvertFormat(colorspace_op="709:709=>709:linear") # change to the correct matrix if needed
z_ConvertFormat(2560,1120,pixel_type="RGBP16",colorspace_op ="709:linear:709:auto=>rgb:srgb:170m:l")

[Dogway]

Thanks, yes it worked. So matrix has to be explicitly defined, because it didn't work with "auto" either.

[StvG]

Thanks, yes it worked. So matrix has to be explicitly defined, because it didn't work with "auto" either.

Here (https://forum.doom9.org/showthread.php?p=1925849#post1925849) is the info about the keywords "auto"/"same". That info is in the avs wiki too (http://avisynth.nl/index.php/Avsresize#Frame_Properties).

[StvG]

YUV420P16 source
z_ConvertFormat(colorspace_op="auto:709=>same:linear")

@Dogway, the above is a short cut of
YUV420P16 source
z_ConvertFormat(pixel_type="rgbps", colorspace_op="auto:709=>rgb:linear")
z_ConvertFormat(pixel_type="yuv420p16", colorspace_op="rgb=>same")

There is colorspace conversion that's the reason for the error (from the wiki "If you use "auto=>same" for matrix/transfer/primaries with frame property 2 (unspec) and you want to make colorspace conversion, error will be raised.").

[Dogway]

Thanks for the note, I was reporting a possible bug I found while debugging TransformsPack.
I myself don't use avsresize as it doesn't feel intuitive to me despite being super-fast.

[tormento]

Guys, where can I find the sources for avsresize r19?

There could be a good chance for it to be ported to CUDA.

[kedautinh12]

Guys, where can I find the sources for avsresize r19?

There could be a good chance for it to be ported to CUDA.

You can port to CUDA??

[tormento]

You can port to CUDA??
Not me, someone who lurks in forum shadow. :p

[kedautinh12]

Not me, someone who lurks in forum shadow. :p

Ok, waiting for StvG share source code :D

[Reel.Deel]

Guys, where can I find the sources for avsresize r19?

There could be a good chance for it to be ported to CUDA.

DG has seen the source (see your own post in that thread on Oct 10, 2022). Regardless, the source code for avsresize is included in the 7z file with every release. And here is the zimg repo: https://github.com/sekrit-twc/zimg

[FranceBB]

DG has seen the source (see your own post in that thread on Oct 10, 2022).


Yeah, but he also said that perhaps Sherman is able to port it to CUDA by himself for him, which would be absolutely welcomed.

I mean, when you encode a UHD at only 6fps on a 56c/112th pure CPU AVX512 Intel Xeon monster, burning a whole amazonian forest in electricity bills while you have an NVIDIA Quadro P5000 sitting idle (if it wasn't for the OpenCl acceleration of x264), you start wondering your life choices. :P

[Julek]

zimg is so fast on CPU (at least in vapoursynth) that I see no reason to use GPU resizer, it is more useful to leave it free for heavy denoise/eedi/nnedi.

[kedautinh12]

zimg is so fast on CPU (at least in vapoursynth) that I see no reason to use GPU resizer, it is more useful to leave it free for heavy denoise/eedi/nnedi.

eedi2 had cuda ver :D
https://github.com/kedaitinh12/VapourSynth-EEDI2CUDA/releases

[tormento]

zimg is so fast on CPU (at least in vapoursynth) that I see no reason to use GPU resizer,
Perhaps on newer systems. Not everybody has a brand new Sapphire Rapids processor :).

[kedautinh12]

Perhaps on newer systems. Not everybody has a brand new Sapphire Rapids processor :).

Don't need. With AMD r3 series and above, intel 8th and above. it's very fast

[tormento]

Don't need. In AMD r3 series and above, intel 8th and above. it's very fast
It was figurative.

[StvG]

avsresize_r20 (https://ppp.woelkli.com/s/cMwJgP83ebywkzj) (pass: iFmc8FTt1DsT):
- not read "_FieldBased" frame prop when use_props=0;
- added ProPhotoRGB (TomArrow).

[FranceBB]

Thanks for the new release, I'll test it when I get back to the office on February the 2nd! ;)

[StvG]

avsresize_r21 (https://ppp.woelkli.com/s/CrsC8rQmwNdApEg) (pass: 0RHxLfJy1t0C):
- throw error if IsFieldBased()=true and interlaced=false/use_props=1;
- resizer wrappers: added parameter interlaced;
- changed behavior of interlaced=true - previously it force use_props=0; now it doesn't have effect when use_props=1.

[FranceBB]

Ah, ok.
Upgrading now again, thanks. :)

[StvG]

Just to point out if it's not obvious already - after r19 you can process interlaced content without interlaced=true when use_props=0 and _FieldBased > 0 which will lead to wrong outputs. Before r20 there will be error raised that clip must be frame-based because frame prop was checked. Now (>= r20) when use_props=0, none frame prop is read. Be careful.

Again info about use_props=-1 (default value):

i. Auto use_props=0
1. Source and destination colorspace are same (source and destination are yuv/y, source and destination are rgb)
- colorspace_op is undefined and chromaloc_op is undefined or chromaloc_op src is not auto (chromaloc_op="left=>left")
2. colorspace_op is defined and every src value is not auto (x:x:x:x=>y:y:y:y), and chromaloc_op is undefined or chromaloc_op src is not auto (chromaloc_op="left=>left")
ii. Every other case - auto use_props=1

You can force to read frame props by set use_props=1, or force to not read frame prop by set use_prop=0.

[FranceBB]

Yep, that's good to know and that's exactly what a user would want: use_props=0 should avoid reading any property in any case and therefore speed things up.
By the way, I am beginning to slowly try frame properties for things I don't encode manually and go through automation.
Luckily, in my case, I should be ok 'cause indexers are reading frame_properties and if there are none, they're assumed and populated by my ClipPropertyParser() for all the automated supply chains in FFAStrans, so in theory it shouldn't matter, but yeah, thanks for the heads up. ;)

I'll come up with a report of how things went tomorrow.

EDIT: So far so good

https://i.imgur.com/k2IZ2vm.png

[ErazorTT]

Would it be possible to include the 2.6 gamma to the possible transfer function which is used in st431-2 and st432-1?

[StvG]

Can you ask the zimg author (https://github.com/sekrit-twc/zimg). If he wouldn't add it, I can take a look.

[FranceBB]

Hi there guys,
I tried to compile avsresize.dll using v141_xp:

https://i.imgur.com/ITRMv7E.png
https://i.imgur.com/GppJrWd.png

the build completed fine

https://i.imgur.com/EmdFgzm.png

and the produced dll shows no issues in Dependency Walker:

https://i.imgur.com/JO5MZ0Z.png


however it just won't work in Avisynth.
Is it because it's zlib being actually incompatible with XP even though it's not erroring during compilation?

Test build (link valid for 7 days only): https://we.tl/t-ZcUDEqFsZp

[real.finder]

seems _FieldBased frame property is not used to check whether the source is interlaced or not (I also tried with use_props=1 when convert from yv12 to yv24 but it kinda broken)

also can we have independent chroma subsampling parameter? for let say convert anything to 4:4:4 regardless of bitdepth to do some filtering then back to 4:2:0 or whatever original subsampling with another z_ConvertFormat() call and this is easy z_ConvertFormat(pixel_type=PixelType(orig))

[StvG]

seems _FieldBased frame property is not used to check whether the source is interlaced or not (I also tried with use_props=1 when convert from yv12 to yv24 but it kinda broken)

also can we have independent chroma subsampling parameter? for let say convert anything to 4:4:4 regardless of bitdepth to do some filtering then back to 4:2:0 or whatever original subsampling with another z_ConvertFormat() call and this is easy z_ConvertFormat(pixel_type=PixelType(orig))

About _FieldBased - did you read this post (https://forum.doom9.org/showthread.php?p=1983022#post1983022)?

I'm not sure what you exactly ask about "independent chroma subsampling parameter". Can you elaborate?

[real.finder]

About _FieldBased - did you read this post (https://forum.doom9.org/showthread.php?p=1983022#post1983022)?

didn't read it but still with use_props=1 seems not work (avspmod will show error about not frame base)

I'm not sure what you exactly ask about "independent chroma subsampling parameter". Can you elaborate?

like adding new parameter called chroma_subsampling (or any short name) that accept "444" or "422" and so as string or as int so (-1=same as input) and this will be default or (0=444) (1=422) and so on, and this parameter will be ignored if user set pixel_type

[StvG]

didn't read it but still with use_props=1 seems not work (avspmod will show error about not frame base)

Colorbars(pixel_type="yv12")
propset("_FieldBased", 1)
z_ConvertFormat(pixel_type="yv24", use_props=1)

Above code throw error - frame property is read.
Using use_props=0 doesn't throw error - frame property is not read.

[real.finder]

Colorbars(pixel_type="yv12")
propset("_FieldBased", 1)
z_ConvertFormat(pixel_type="yv24", use_props=1)

Above code throw error - frame property is read.
Using use_props=0 doesn't throw error - frame property is not read.

yes but with use_props=0 will treat the yv12 as progressive when convert it to yv24 which will cause chroma Field Blending

[StvG]

yes but with use_props=0 will treat the yv12 as progressive when convert it to yv24 which will cause chroma Field Blending

use_props=0 doesn't read frame properties. You have to take care if the video is interlaced or not. If the video is interlaced use interlaced=true.

If you want the frame properties to be read (including _FieldBased) use use_props=1.

[real.finder]

use_props=0 doesn't read frame properties. You have to take care if the video is interlaced or not. If the video is interlaced use interlaced=true.

If you want the frame properties to be read (including _FieldBased) use use_props=1.

I know but the problem is with use_props=1 it not same as interlaced=true
avspmod error
https://i.postimg.cc/qMxDzPgQ/Untitled.png (https://postimages.org/)

with interlaced=true it work fine but I need to put it inside avsi function that work with interlaced and progressive and since we got frame properties in avs+ we should rely on them especially if we have a source that got mixed interlaced and progressive frames/sections