z.lib resizers for AviSynth+

[Boulder]

It depends. If your source is 10-bit (it will be valid for any bit depth < 16-bit):
a) if denoise in source bit depth (10-bit), downscale w/o bit depth change (10-bit->16-bit->10-bit - how internally avsresize will scale), deband w/o bit depth change (assume f3kdb: 10->16-bit->10-bit - how internally f3kdb will deband)
b) convert to 16-bit, denoise, downscale, deband, convert to source bit depth (10-bit)

For a) it's better to apply dither after the downscaling.
For b) 16-bit->10-bit is done only once at the end - dither.

If the speed penalty of b) isn't the bottleneck, it should be always the preferred option imo.
For 8- or 10-bit sources, I do the denoising part in 16 bits. Then that is fed to the downscaling part, where it's converted to linear RGBPS, downscaled and converted to YUV420P16. Then debanding without any bitdepth change, fed to the encoder (x265) as 16-bit and the internal dithering is enabled to get the final 10-bit output. So based on your answer, I think it's best that dithering is disabled wherever possible and allow it only at the encoder phase.

By the way, what is the difference between converting the format and resizing in the same z_ConvertFormat call and doing it in two different calls (resizing first, then converting to the final format)? I tested it yesterday and there seems to be a rather noticable performance drop if you use two calls.

[FranceBB]

[...] fed to the encoder (x265) as 16-bit and the internal dithering is enabled to get the final 10-bit output.

I do exactly the same.
No matter if the source is 8bit, 10bit or 12bit planar, I always bring everything to 16bit planar, filter everything out and feed the encoder with the 16bit input.

My outputs are always 10bit, so x264 will dither it down using the Sierra-2-4A algorithm, while x265 will use... something else.

Speaking of which, what will x265 use with --dither? I mean, which algorithm?
I know we've been having this conversation before but I forgot xD

[Reel.Deel]

I try to do everything in one go (if possible). Sometimes doing 2 steps can be detrimental. For example, I saw this script in another thread:


LWLibavVideoSource("video.uhd.rmx.mkv",cachefile="video.lwi",format="YUV420P16",decoder="hevc_qsv",prefer_hw=2) # hw

# (avsresize.dll)
z_Spline36Resize(1920,1080) # FHD

# Converting format (avsresize.dll)
z_ConvertFormat(pixel_type="RGBP16",colorspace_op="2020:st2084:2020:l=>rgb:st2084:2020:f",dither_type="none")

# Apply LUT (vscube.dll) input full / output full HLG
Cube("hlg-tools65.cube",fullrange=true) # max-cll 1000

# Converting format (avsresize.dll)
z_ConvertFormat(pixel_type="YUV420P16",colorspace_op="rgb:std-b67:2020:f=>2020ncl:std-b67:2020:l",dither_type="error_diffusion")



The source is 4k and it's getting resized down to 1920x1080 YUV420 and then converted to RGB16. Here the chroma is going from 1920x1080 down to 960x540 and then scaled back up to 1080p when converted to RGB. Sure, after applying the LUT it is converted back to YUV420 and the chroma size is back again down to 960x540. Most wont even be able to tell the difference but it still does unnecessary processing. source.z_ConvertFormat(1920,1080, pixel_type="RGBP16",...) would be higher fidelity. At least that is how dither works when you resize and change format at the same time. In this scenario you can even go from UHD YUV4:2:0 down to FHD YUV4:4:4 without even resizing the chroma planes. Provided that the luma channel gets independently resized with src_left=-0.50, src_top=-0.50 to account for the chroma placement shift (top left in this case, assuming source is uhd bluray). After that, merge the luma with the original chroma planes, convert to RGB and proceed :).

Edit: re-reading the last few post, seems my comment is somewhat not related to the discussion. But, I'll leave it here since it's still relevant to the thread. I should be asleep lol.

[Boulder]

I do exactly the same.
No matter if the source is 8bit, 10bit or 12bit planar, I always bring everything to 16bit planar, filter everything out and feed the encoder with the 16bit input.

My outputs are always 10bit, so x264 will dither it down using the Sierra-2-4A algorithm, while x265 will use... something else.

Speaking of which, what will x265 use with --dither? I mean, which algorithm?
I know we've been having this conversation before but I forgot xD
From api.cpp: "The dithering algorithm is based on Sierra-2-4A error diffusion." It's probably identical to x264, why re-invent the wheel since they ported other stuff as well.

[StvG]

By the way, what is the difference between converting the format and resizing in the same z_ConvertFormat call and doing it in two different calls (resizing first, then converting to the final format)? I tested it yesterday and there seems to be a rather noticable performance drop if you use two calls.

If you mean something like this:z_ConvertFormat(pixel_type="rgbps", colorspace_op="709:709:709:l=>rgb:linear:709:f", chromaloc_op="left=>left")
z_BicubicResize(x, y)
z_ConvertFormat(pixel_type="yuv420p16", colorspace_op="rgb:linear:709:f=>709:709:709:l", chromaloc_op="left=>left")
z_ConvertFormat(pixel_type="rgbps", colorspace_op="709:709:709:l=>rgb:linear:709:f", chromaloc_op="left=>left")
z_ConvertFormat(x, y, pixel_type="yuv420p16", colorspace_op="rgb:linear:709:f=>709:709:709:l", chromaloc_op="left=>left")

These variants give identical results. The first one have some overhead that could have some penalty for the final speed. My quick test shows ~7% difference. If frame properties are involved I would say there is no speed difference.

[StvG]

avsresize_r13 (https://ppp.woelkli.com/s/F478Yf3WQkRtXqW) (pass: f0MNKlTxVxl5):
- zimg@dd4c4df;
- use_props= -1: If frame properties are supported - if every option of colorspace_op and chromaloc_op (for src/dst colorspace with subsampling w/h > 0) are specified and different than "auto", 0, otherwise 1.

[FranceBB]

ffms2_6ad7738 (https://ppp.woelkli.com/s/NMk6MyD6LZR7nYH) (pass: u7Uezbh3fTHM):
- ffms2@90975ec;
- ffmpeg n5.1@1764a6887b;
- zlib 1.2.12;
- dav1d 1.0.0;
- AviSynth: set Dolby Vision RPU data in frame props.

Thanks, works perfectly on Windows 11 x64 and Windows Server 2019 x64. :)

FFMpegSource2("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\test_PCM_DolbyE_PCM_PCM.mxf", atrack=-1)

propClearAll()

#From 4:2:0 16bit planar Narrow Range to RGB Planar 16bit Full Range
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="709:709:709:limited=>rgb:709:709:full", dither_type="error_diffusion")

#From BT709 SDR to BT2020 HDR HLG with 16bit precision
Cube("C:\Program Files (x86)\AviSynth+\LUTs\5a_BT709_HLG_UPCONVERT_DISPLAY_mode-nar_in-nar_out-nar_nocomp.cube", fullrange=true)

#From RGB 16bit planar Full Range to YUV422 10bit planar Narrow Range with dithering
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")


to deliver a cool nice 75% ref white HLG output. :)

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

Cheers,
Frank

[Boulder]

Using props=4 causes an access violation on my system. Tested with this:

z_ConvertFormat(pixel_type="RGBPS", chromaloc_op="auto=>same", colorspace_op="auto:auto:auto:auto=>rgb:linear:same:full", approximate_gamma=true, cpu_type="AVX2", use_props=3)
z_ConvertFormat(pixel_type="YUV420P16", chromaloc_op="auto=>same", resample_filter="Bicubic", resample_filter_uv="Bicubic", filter_param_a=0, filter_param_b=0.6, width=960, height=720, cpu_type="AVX2", dither_type="none", approximate_gamma=true, use_props=4)

[StvG]

avsresize_r14 (https://ppp.woelkli.com/s/bD6xpSyDgdZjW9a) (pass: QOvyNpMf5TyF) - fixed regression (r12) when reading frame properties (use_props=3/4).

[Boulder]

avsresize_r14 (https://ppp.woelkli.com/s/bD6xpSyDgdZjW9a) (pass: QOvyNpMf5TyF) - fixed regression (r12) when reading frame properties (use_props=3/4).

Still the same problem with this one.

[StvG]

Still the same problem with this one.

Download again the r14. You will see error that chromaloc_op (colospace_op too) must be not specified when use_props=4.

[Boulder]

Download again the r14. You will see error that chromaloc_op (colospace_op too) must be not specified when use_props=4.

Thanks, works now :)

[Stephen R. Savage]

Released r2:


Update to z.lib 3.0
Enable 64-byte alignment
Support real Spline64Resize
Support alpha-aware resizing
Implement multi-threading

[kedautinh12]

Hmm, 2 version?

[FranceBB]

What do you mean by "real" Spline64Resize?

[Reel.Deel]

What do you mean by "real" Spline64Resize?

Up until 2 years ago or so, Spline64Resize was just an alias for Spline32Resize. z.lib added the spline64 filter in v2.9.3.

[tormento]

Hmm, 2 version?
First number major buiid, second number minor release? :confused:

[Reel.Deel]

First number major buiid, second number minor release? :confused:

Stephen R. Savage is the original author of avsresize (and z.lib). He released the first version of avsresize (r1) back in 2016 and then some periodic updates. The last update was r1d in March of 2018. StvG then continued updating the plugin ever since, up to r14 now.

[kedautinh12]

Stephen R. Savage is the original author of avsresize (and z.lib). He released the first version of avsresize (r1) back in 2016 and then some periodic updates. The last update was r1d in March of 2018. StvG then continued updating the plugin ever since, up to r14 now.

And r2 is continued update of r14??

[TomArrow]

I've a quick question about z_ConvertFormat. Does it write any usually not visible metadata to the clip that a software like ffmpeg can use? A friend reported that in conjunction with ffmpeg, using this filter (just doing a straight conversion to the same color space) can result in changes to the output file in terms of metadata, transfer characteristic specifically.

Of course this doesn't have to be a bad thing per se, but it would be good to know.

[FranceBB]

I think it does make use of frame properties, so if you're using a recent version of Avisynth and a frame properties enabled build of ffmpeg, it will read them.

This is just an example:


#Indexing ProRes HQ 4:2:2 23,976p 10bit planar HDR PQ source
video=LWLibavVideoSource("KFH00862.mov")
ch1=LWLibavAudioSource("KFH00862.mov", stream_index=1)
ch2=LWLibavAudioSource("KFH00862.mov", stream_index=2)
ch3=LWLibavAudioSource("KFH00862.mov", stream_index=3)
ch4=LWLibavAudioSource("KFH00862.mov", stream_index=4)
ch5=LWLibavAudioSource("KFH00862.mov", stream_index=5)
ch6=LWLibavAudioSource("KFH00862.mov", stream_index=6)
ch7=LWLibavAudioSource("KFH00862.mov", stream_index=7)
ch8=LWLibavAudioSource("KFH00862.mov", stream_index=8)
ch9=LWLibavAudioSource("KFH00862.mov", stream_index=9)
ch10=LWLibavAudioSource("KFH00862.mov", stream_index=10)
ch11=LWLibavAudioSource("KFH00862.mov", stream_index=11)
ch12=LWLibavAudioSource("KFH00862.mov", stream_index=12)
ch13=LWLibavAudioSource("KFH00862.mov", stream_index=13)
ch14=LWLibavAudioSource("KFH00862.mov", stream_index=14)
ch15=LWLibavAudioSource("KFH00862.mov", stream_index=15)
ch16=LWLibavAudioSource("KFH00862.mov", stream_index=16)
audio=MergeChannels(ch1, ch2, ch3, ch4, ch5, ch6, ch7, ch8, ch9, ch10, ch11, ch12, ch13, ch14, ch15, ch16)
AudioDub(video, audio)

#From 4:2:2 10bit to 4:2:2 16bit planar
ConvertBits(16)

#From 4:2:2 16bit planar Narrow Range to RGB Planar 16bit Narrow Range
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:2020:2020:limited=>rgb:2020:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

#From PQ to HLG with 16bit precision
Cube("WarnerBros_PQToHLG_MaxCLL_2752.cube", fullrange=true)

#From RGB 16bit planar Narrow Range to YUV422 16bit planar Narrow Range
z_ConvertFormat(pixel_type="YUV422P16", colorspace_op="rgb:2020:2020:limited=>2020:2020:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

#Filling the right frame properties with HLG
propset("_Transfer", 18)

#Speed-up + pitch adjustment
ResampleAudio(48000)
AssumeFPS(25, 1, false)
TimeStretch(tempo=100.0*25.0/(24000.0/1001.0))
ResampleAudio(48000)

#Clipping
Limiter(min_luma=4096, max_luma=60160, min_chroma=4096, max_chroma=60160)


as you can see here I'm populating the transfer characteristics value with the right one, in fact this is the important bit:

#Filling the right frame properties with HLG
propset("_Transfer", 18)

which will set the arib-std-b67 transfer, so HLG, so that when FFMpeg is gonna read the script with -i "AVS Script.avs" it will read them correctly.
If you wanna be absolutely sure that frame properties are set correctly, you can check them with AVSPmod and eventually populate them accordingly yourself, otherwise you can always use propClearAll() right after indexing and everything will be business as usual (I generally prefer the latter).

[StvG]

It's probably better that a moderator to move posts from #109 (https://forum.doom9.org/showthread.php?p=1906771#post1906771) to #213 (https://forum.doom9.org/showthread.php?p=1967712#post1967712) (including) in a separate thread to avoid confusions between the two builds.

At the moment the main diff between the builds(r2 (https://forum.doom9.org/showthread.php?p=1971316#post1971316) and r14 (https://forum.doom9.org/showthread.php?p=1967682#post1967682)):
- how alpha plane is treated: r2 - ZIMG_ALPHA_STRAIGHT; r14 - ZIMG_ALPHA_PREMULTIPLIED

- r14 has additional pixel types aliases - RGBP8, RGBAP8, YUV444, YUV444P8, YUVA444P8, YUV422, YUV422P8, YUVA422P8, YUV420, YUV420P8 , YUVA420P8, YUV411, YUV411P8

- r14 has additional chroma locations - TOP_LEFT, TOP, BOTTOM_LEFT, BOTTOM
- r2 has additional chroma location alias - dv (LEFT)

- r2 has additional resample aliases - gauss (BICUBIC), lanczos4 (LANCZOS), blackman (LANCZOS), sinc (LANCZOS), z_BlackmanResize (LANCZOS), z_GaussResize (BICUBIC), z_SincResize (LANCZOS)

- r14 has additional args: cpu_type, nominal_luminance, approximate_gamma, use_props

- r14 has support for frame properties

- r14 has additional args for the compatibility wrappers (z_xxResize) - chromaloc_op, dither

Btw r2 still has the parsing bug when colospace_op values with dash are used - for example std-b67/st431-2...

[DTL]

As the jpsdr post at https://forum.doom9.org/showthread.php?p=1970987#post1970987 -

I don't know what the others plugins output, neither what they expect in input. "linear", but wich one ? scene linear light and scaled by camera exposure or displayed linear ?

Can the z.lib switch between different 'linear' conversions from HDR formats ?

Following tests at https://forum.doom9.org/showthread.php?p=1970995#post1970995 shows that the OOTF on/off at the process of conversion system transfer to 'linear' looks like make the main difference. The difference is not great and may be too few persons now make processing in linear to detect this difference at real footage.

[StvG]

As the jpsdr post at https://forum.doom9.org/showthread.php?p=1970987#post1970987 -

I don't know what the others plugins output, neither what they expect in input. "linear", but wich one ? scene linear light and scaled by camera exposure or displayed linear ?

Can the z.lib switch between different 'linear' conversions from HDR formats ?

Following tests at https://forum.doom9.org/showthread.php?p=1970995#post1970995 shows that the OOTF on/off at the process of conversion system transfer to 'linear' looks like make the main difference. The difference is not great and may be too few persons now make processing in linear to detect this difference at real footage.

zimg itself can switch between scene-referred and display-referred case (here (https://github.com/sekrit-twc/zimg/blob/797024c67be7ffd959da381adf7b0164029ef3e5/src/zimg/colorspace/gamma.cpp#L342-L353)) but this option is not api exposed so the avs/vs plugin is using only the display-referred one.

[DTL]

Can the OOTF stage be simulated as some AVS scripting after 'first stage conversion to linear' with zimg-AVS plugin ? To get 'scene-referred' too if required ?

"but this option is not api exposed"

May be it can be feature-request and API supplement and finally go into next plugin version ?

So for sources 'conditioned' in 'scene-linear light' it can be used as a one-step conversion from HDR transfer encoded form into linear for scaling or other processing.

[TomArrow]

I think it does make use of frame properties, so if you're using a recent version of Avisynth and a frame properties enabled build of ffmpeg, it will read them.

This is just an example:


#Indexing ProRes HQ 4:2:2 23,976p 10bit planar HDR PQ source
video=LWLibavVideoSource("KFH00862.mov")
ch1=LWLibavAudioSource("KFH00862.mov", stream_index=1)
ch2=LWLibavAudioSource("KFH00862.mov", stream_index=2)
ch3=LWLibavAudioSource("KFH00862.mov", stream_index=3)
ch4=LWLibavAudioSource("KFH00862.mov", stream_index=4)
ch5=LWLibavAudioSource("KFH00862.mov", stream_index=5)
ch6=LWLibavAudioSource("KFH00862.mov", stream_index=6)
ch7=LWLibavAudioSource("KFH00862.mov", stream_index=7)
ch8=LWLibavAudioSource("KFH00862.mov", stream_index=8)
ch9=LWLibavAudioSource("KFH00862.mov", stream_index=9)
ch10=LWLibavAudioSource("KFH00862.mov", stream_index=10)
ch11=LWLibavAudioSource("KFH00862.mov", stream_index=11)
ch12=LWLibavAudioSource("KFH00862.mov", stream_index=12)
ch13=LWLibavAudioSource("KFH00862.mov", stream_index=13)
ch14=LWLibavAudioSource("KFH00862.mov", stream_index=14)
ch15=LWLibavAudioSource("KFH00862.mov", stream_index=15)
ch16=LWLibavAudioSource("KFH00862.mov", stream_index=16)
audio=MergeChannels(ch1, ch2, ch3, ch4, ch5, ch6, ch7, ch8, ch9, ch10, ch11, ch12, ch13, ch14, ch15, ch16)
AudioDub(video, audio)

#From 4:2:2 10bit to 4:2:2 16bit planar
ConvertBits(16)

#From 4:2:2 16bit planar Narrow Range to RGB Planar 16bit Narrow Range
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:2020:2020:limited=>rgb:2020:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

#From PQ to HLG with 16bit precision
Cube("WarnerBros_PQToHLG_MaxCLL_2752.cube", fullrange=true)

#From RGB 16bit planar Narrow Range to YUV422 16bit planar Narrow Range
z_ConvertFormat(pixel_type="YUV422P16", colorspace_op="rgb:2020:2020:limited=>2020:2020:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

#Filling the right frame properties with HLG
propset("_Transfer", 18)

#Speed-up + pitch adjustment
ResampleAudio(48000)
AssumeFPS(25, 1, false)
TimeStretch(tempo=100.0*25.0/(24000.0/1001.0))
ResampleAudio(48000)

#Clipping
Limiter(min_luma=4096, max_luma=60160, min_chroma=4096, max_chroma=60160)


as you can see here I'm populating the transfer characteristics value with the right one, in fact this is the important bit:

#Filling the right frame properties with HLG
propset("_Transfer", 18)

which will set the arib-std-b67 transfer, so HLG, so that when FFMpeg is gonna read the script with -i "AVS Script.avs" it will read them correctly.
If you wanna be absolutely sure that frame properties are set correctly, you can check them with AVSPmod and eventually populate them accordingly yourself, otherwise you can always use propClearAll() right after indexing and everything will be business as usual (I generally prefer the latter).

Thanks! That could explain it.

[StvG]

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

... otherwise you can always use propClearAll() right after indexing and everything will be business as usual (I generally prefer the latter).

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.

Can the OOTF stage be simulated as some AVS scripting after 'first stage conversion to linear' with zimg-AVS plugin ? To get 'scene-referred' too if required ?

"but this option is not api exposed"

May be it can be feature-request and API supplement and finally go into next plugin version ?

So for sources 'conditioned' in 'scene-linear light' it can be used as a one-step conversion from HDR transfer encoded form into linear for scaling or other processing.

Try the new scene_referred parameter.

[DTL]

Try the new scene_referred parameter.

It finally work about as expected https://forum.doom9.org/showthread.php?p=1972723#post1972723 but looks the float RGB values are very different for each plugin and require deep correction with 'magic numbers' like about 3.0 gain for one plugin and 0.157 for avsresize. But finally it can convert 10bit HLG YUV codevalues into rec709 via RGB-linear-float path with 'exact' precision in 8bit R'G'B' output. And the intermediate values forming transient looks about good too.

[FranceBB]

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.


Gotcha, will do! :)


#From 4:2:2 16bit planar Narrow Range to RGB Planar 16bit Narrow Range
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:2020:2020:limited=>rgb:2020:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion", use_props=0)

#From PQ to HLG with 16bit precision
Cube("\\myserver.local\avdb\Server\encoder\encoder\Processors\avs_plugins\LUTs\WarnerBros_PQToHLG_MaxCLL_2752.cube", fullrange=true)

#From RGB 16bit planar Narrow Range to YUV422 16bit planar Narrow Range
z_ConvertFormat(pixel_type="YUV422P16", colorspace_op="rgb:2020:2020:limited=>2020:2020:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion", use_props=0)

#Filling the right frame properties with HLG
propset("_Transfer", 18)

[StvG]

Gotcha, will do! :)


#From 4:2:2 16bit planar Narrow Range to RGB Planar 16bit Narrow Range
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:2020:2020:limited=>rgb:2020:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion", use_props=0)

#From PQ to HLG with 16bit precision
Cube("\\myserver.local\avdb\Server\encoder\encoder\Processors\avs_plugins\LUTs\WarnerBros_PQToHLG_MaxCLL_2752.cube", fullrange=true)

#From RGB 16bit planar Narrow Range to YUV422 16bit planar Narrow Range
z_ConvertFormat(pixel_type="YUV422P16", colorspace_op="rgb:2020:2020:limited=>2020:2020:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion", use_props=0)

#Filling the right frame properties with HLG
propset("_Transfer", 18)

The last line propset("_Transfer", 18) can be omitted by using z_ConvertFormat(pixel_type="YUV422P16", colorspace_op="rgb:std-b67:2020:limited=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion", use_props=0).

[FranceBB]

Thanks, I have updated my scripts! :)

I have another question, though.
I have a BT601 SD 25i TFF source that I want to convert to BT709 but I want to leave interlacing alone.
Of course I could just bob, use z_ConvertFormat() and then separatefields() etc, but I'd like to avoid that.
I noticed that in z_ConvertFormat() there's "interlaced" as a parameter that can be either true or false, however if I set it to "true", it says "Interlaced operation not supported":


video=FFVideoSource("G:\txmaster\sd\PRM7_0247234_SD_Remuxed_v2.mxf")
ch1=FFAudioSource("G:\txmaster\sd\PRM7_0247234_SD_Remuxed_v2.mxf", track=1)
ch2=FFAudioSource("G:\txmaster\sd\PRM7_0247234_SD_Remuxed_v2.mxf", track=2)
audio=MergeChannels(ch1, ch2)
AudioDub(video, audio)

propclearall()

z_ConvertFormat(colorspace_op="470bg:470bg:470bg:limited=>709:709:709:limited", pixel_type="YUV422P10", resample_filter="lanczos", dither_type="error_diffusion", interlaced=true, use_props=0)


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

why?

this works but I'd like to avoid it:


video=FFVideoSource("G:\txmaster\sd\PRM7_0247234_SD_Remuxed_v2.mxf")
ch1=FFAudioSource("G:\txmaster\sd\PRM7_0247234_SD_Remuxed_v2.mxf", track=1)
ch2=FFAudioSource("G:\txmaster\sd\PRM7_0247234_SD_Remuxed_v2.mxf", track=2)
audio=MergeChannels(ch1, ch2)
AudioDub(video, audio)

propclearall()

Bob()
z_ConvertFormat(colorspace_op="470bg:470bg:470bg:limited=>709:709:709:limited", pixel_type="YUV422P10", resample_filter="lanczos", dither_type="error_diffusion", interlaced=false, use_props=0)
assumeTFF()
separatefields()
selectevery(4,0,3)
weave()


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

[StvG]

The support for interlaced video isn't added. Btw why propclearall() when you have use_props=0?

[FranceBB]

I see...
Will it ever be added?
As to propclearall (), if I don't use it, even if avsresize won't use them with use_props=0, it won't nuke them, so they would still be there which is even worse 'cause at that point they would just be wrong and not updated.

EDIT: Actually, you're right, use_props=0 make it not read them but still set them, so they're gonna be correct, my bad. ;)

[StvG]

avsresize_r16 (https://ppp.woelkli.com/s/dMg9tfxFHRsQjaC) (pass: ZrDjU0BAGRha):
- improved use_props=-1;
- throw error when use_props=0 and _FieldBased/_Field > 0;
- added support for interlaced clips: when interlaced=true, always use_props=0.

[FranceBB]

What a lovely morning present.
Yesterday Donald gifted the community with a CUDA porting of Cube(), today you introduced interlaced = true support in avsresize.
I wonder what's gonna be next... :D

[kedautinh12]

What a lovely morning present.
Yesterday Donald gifted the community with a CUDA porting of Cube(), today you introduced interlaced = true support in avsresize.
I wonder what's gonna be next... :D

Thanks for info of CUDA ver of cube but where's the link?

[tormento]

Thanks for info of CUDA ver of cube but where's the link?
Here (https://www.rationalqm.us/board/viewtopic.php?f=14&t=1180)

[FranceBB]

ehehehe, you know, Tormento is my drug-deal--- ehm I mean DLL dealer too! Especially for GPU-related stuff eheheheh

[StvG]

avsresize_r17 (https://ppp.woelkli.com/s/q7RYetopF5ayjFq) (pass: OPtHxyD16GmI): use_props=-1 improved a bit more.

[StvG]

avsresize_r18 (https://ppp.woelkli.com/s/GecgF4CDQrjmKse) (pass: MzYJG3B0mt0M): fixed output frame properties when use_props=0 and colorspace_op/chromaloc_op not specified.

[FranceBB]

Thank you.
Tomorrow is bank holiday in Italy and this whole week I'm gonna be off, so I'll test it next week. :)

[kedautinh12]

Thank you.
Tomorrow is bank holiday in Italy and this whole week I'm gonna be off, so I'll test it next week. :)

I think you're French cause your name :D

[guest]

I think you're French cause your name :D

Wait, what, he said Italy !!! :confused:

[kedautinh12]

Wait, what, he said Italy !!! :confused:

That i was thought cause "France"BB :D

[FranceBB]

That's a common mistake eheheheh
FranceBB actually refers to my name "Francesco" and the first letter of my surname "Bucciantini".
Unfortunately, in 1999 when I had my first computer with Windows 98SE with a puny monocore, 40 GB Pata Hard Drive and 64MB of RAM and I started registering on forums across the web (mostly football related) the username "FranceB" was already taken, so... FranceBB was born. XD
So... Yep, I'm not French, I'm Italian and I also passed the British citizenship test in 2017 which makes me almost British. :P

[StvG]

avsresize_r19 (https://ppp.woelkli.com/s/48afszmo6k2ZaGd) (pass: wJCnTcLxAQT9):
- fixed the behavior when missing frame property;
- the matrix between yuv<->grey isn't silently changed anymore.

[guest]

What a lovely morning present.
Yesterday Donald gifted the community with a CUDA porting of Cube(), today you introduced interlaced = true support in avsresize.
I wonder what's gonna be next... :D

What needs to be done to this script, to use Donald's DGCube...

LoadPlugin("%AVISYNTHPLUGINS%\avscube\vscube.dll")
video=ConvertBits(video, 16)
video=ConvertToPlanarRGB(video)
video=Cube(video, "%AVISYNTHPLUGINS%\3D LUTs\6500.CUBE", cpu=2, fullrange=true)
video=Converttoyuv420(video)


I have tried a few "obvious" things, but couldn't get it to work.

TIA

[kedautinh12]

What needs to be done to this script, to use Donald's DGCube...

LoadPlugin("%AVISYNTHPLUGINS%\avscube\vscube.dll")
video=ConvertBits(video, 16)
video=ConvertToPlanarRGB(video)
video=Cube(video, "%AVISYNTHPLUGINS%\3D LUTs\6500.CUBE", cpu=2, fullrange=true)
video=Converttoyuv420(video)


I have tried a few "obvious" things, but couldn't get it to work.

TIA

Your scripts used for Cube-CPU not DGCube

[guest]

Your scripts used for Cube-CPU not DGCube

I am aware, that is why I have asked the question, as I can't find a definitive usable script.

There are some examples here :-

https://rationalqm.us/board/viewtopic.php?f=14&t=1180&hilit=DGCube&start=75

[tormento]

What needs to be done to this script, to use Donald's DGCube...
I am sometimes lazy but you could at least read the DG thread and the included txt file. :rolleyes: