Dogway's Filters Packs - Page 100

DTL · 4th February 2023, 13:17

Quote:

Originally Posted by LeXXuz

I've uploaded two samples here, the noisy source with the luma flicker and the cleaned version with the wobble.
Just watch the left and upper side of the archway the actor is walking through and you can't miss it. Looks awful on a big screen TV.
Original:
https://send.cm/d/JxeF

It is spatial distortion in the source. To fix it some advanced 'area stabilization' processing required to keep real objects motion and to attempt to decrease this 'scale+translate' transform on more or less big ares of the frame. May be initial film frames were distorted so the filmscan already distorted too.

poisondeathray · 4th February 2023, 16:20

Quote:

Originally Posted by simple_simon

I noticed that deep_resize is changing the colors slightly. Is that intentional for some reason?

In what situation ? What are the details of videos and script ? It does not change the colors here:

eg.

Code:

colorbarshd(1920,1080)

vs

Code:

colorbarshd(1920,1080)
deep_resize(1280,720, grain=0)

Dogway · 4th February 2023, 18:46

Quote:

Originally Posted by LeXXuz

As general noise filter or as a prefilter? Any suggestions which ones to give a try maybe?

As a general noise with good temporal prefilter (BM3D), because the luma flicker is not homogeneous so the ex_autolevels() is never going to fix it completely.

The update to SceneStats with IQM is finished except for an issue on the accumulator that I have to fix, it's challenging me.

Quote:

Originally Posted by Boulder

If you remove most or all the noise from the prefilter clip, you are also bound to remove plenty of fine details as well. Is this not a problem when trying to keep the details but remove the noise with MDegrain?

The real case scenario for prefiltering is one where you use masks and smart filtering. The built-in prefilters are only a convenience for not advanced users. In any case the prefiltering is not the real output, it can be a bit more blurry than expected since you only need the structure for the motion vectors. Motion vectors from MVTools itself are neither as fine detailed as you think (blocks of 4x4 for refinemotion like a 480x270 clip for a 1080p source with blksize=8) so if there are finer elements you want to recover you will need to add them back later with custom masks (corner masks, detail masks, luma masks...). I chose to keep SMDegrain "simple", which suits all kind of sources, like an interface or agnostic extension of MVTools.

EDIT: ScenesPack updated, ex_autolevels() in GradePack also updated.

simple_simon · 4th February 2023, 21:53

Quote:

Originally Posted by poisondeathray

In what situation ? What are the details of videos and script ? It does not change the colors here:

eg.

Code:

colorbarshd(1920,1080)

vs

Code:

colorbarshd(1920,1080)
deep_resize(1280,720, grain=0)

Here's my sample.

Code:

https://send.cm/d/K1aD

Compare

spline36resize(960,720)

to

propSet("_FieldBased",0).deep_resize(960,720,grain=0,qual=2,gpuid=-1)

simple_simon · 4th February 2023, 22:01

Quote:

Originally Posted by Dogway

Works fine here, even clearing all frame props for under 480p clips.

Code:

spline16resize(320,240)
propClearAll()
deep_resize(960,720,grain=0,qual=2,gpuid=-1)

Here's one of the clips giving me the "ConvertYV24ToRGB: Unknown Matrix" error

Code:

https://send.cm/d/K1b5

propSet("_FieldBased",0).deep_resize(960,720,grain=0,qual=2,gpuid=-1)

poisondeathray · 4th February 2023, 22:12

Quote:

Originally Posted by simple_simon

Here's my sample.

Code:

https://send.cm/d/K1aD

Compare

spline36resize(960,720)

to

propSet("_FieldBased",0).deep_resize(960,720,grain=0,qual=2,gpuid=-1)

I don't see any color change, or it's negligible.

Also, you're upscaling "SD" to "HD", the usual convention is to apply colormatrix or similar transform from 601 to 709 , and flag the encode properly

"HD" material by default uses 709 , "SD" by default 601 (some rare exceptions) . Some players will use 709 to convert to RGB for display for HD (height > 576), so video colors will look shifted if it uses the wrong matrix

Quote:

Originally Posted by simple_simon

Here's one of the clips giving me the "ConvertYV24ToRGB: Unknown Matrix" error

Code:

https://send.cm/d/K1b5

propSet("_FieldBased",0).deep_resize(960,720,grain=0,qual=2,gpuid=-1)

Works for me, no error messages with either LWLibavVideoSource, or FFVideoSource

Check your dependencies

Quote:

Color primaries : Display P3
Transfer characteristics : BT.709
Matrix coefficients : BT.709

The primaries are atypical

Maybe try setting the matrix property

propSet("_Matrix",1) #709

simple_simon · 5th February 2023, 00:17

Quote:

Originally Posted by poisondeathray

I don't see any color change, or it's negligible.

Also, you're upscaling "SD" to "HD", the usual convention is to apply colormatrix or similar transform from 601 to 709 , and flag the encode properly

Strange that you aren't seeing the color change. But I did wonder if deep_resize was converting the colorspace to HD also but I couldn't find anywhere where that was stated. So that's good to know so I can apply the encoding settings correctly in x264.

Here's screenshots of what I'm seeing.

Spline36Resize

Code:

https://send.cm/oo8tlpqk5ey7

deep_resize

Code:

https://send.cm/4izbhjbte3rw

Quote:

Originally Posted by poisondeathray

Works for me, no error messages with either LWLibavVideoSource, or FFVideoSource

Check your dependencies

The primaries are atypical

Maybe try setting the matrix property

propSet("_Matrix",1) #709

Well I'm stumped on this one. I doublechecked all dependencies and their dependencies and everthing is up to date as far as I can see.

I tried adding propSet("_Matrix",1) before deep_resize like you suggested and still get the error.

poisondeathray · 5th February 2023, 01:06

Quote:

Originally Posted by simple_simon

Here's screenshots of what I'm seeing.

Screenshots definitely show a 709 vs. 601 mismatch. But I cannot reproduce it with deep_resize and that script

How are you taking screenshots ? Is this a preview or encode ? How are you viewing it ? How is the RGB conversion being done ?

Quote:

Well I'm stumped on this one. I doublechecked all dependencies and their dependencies and everthing is up to date as far as I can see.

I tried adding propSet("_Matrix",1) before deep_resize like you suggested and still get the error.

What is the full error message for "ConvertYV24ToRGB: Unknown Matrix" ? Does it give a line number ?

What avs+ version ?

simple_simon · 5th February 2023, 02:03

Quote:

Originally Posted by poisondeathray

Screenshots definitely show a 709 vs. 601 mismatch. But I cannot reproduce it with deep_resize and that script

How are you taking screenshots ? Is this a preview or encode ? How are you viewing it ? How is the RGB conversion being done ?

Screenshots are window captures of the MeGUI Preview window using Greenshot. I'm not doing any RGB conversion.

Quote:

Originally Posted by poisondeathray

What is the full error message for "ConvertYV24ToRGB: Unknown Matrix" ? Does it give a line number ?

What avs+ version ?

Nope, no line number. I gave all the details that were provided. It doesn't even say what filter is throwing the error. Here's a screenshot of the actual error message in MeGUI.

Code:

https://send.cm/ifax6um50ces

And using AviSynthPlus-3.7.3_r3877, which is the very latest revision that I'm aware of.

poisondeathray · 5th February 2023, 02:30

Quote:

Originally Posted by simple_simon

Screenshots are window captures of the MeGUI Preview window using Greenshot. I'm not doing any RGB conversion.

MeGUI is doing the RGB conversion for the preview

If you don't know what it's doing for the preview, you can explicitly control the conversion by addding ConvertToRGB(matrix="rec709"), or ConvertToRGB(matrix="rec601") (just don't forget to remove them when encoding)

Quote:

Nope, no line number. I gave all the details that were provided. It doesn't even say what filter is throwing the error. Here's a screenshot of the actual error message in MeGUI.

Code:

https://send.cm/ifax6um50ces

And using AviSynthPlus-3.7.3_r3877, which is the very latest revision that I'm aware of.

Maybe an issue with that version ? I was using r3835 . But I checked with r3877 - no problems either, I cannot reproduce either of your issues

Did you check the script in another application, such as mpchc, avspmod ? Maybe some specific issue with megui ?

simple_simon · 5th February 2023, 06:06

Quote:

Originally Posted by poisondeathray

MeGUI is doing the RGB conversion for the preview

If you don't know what it's doing for the preview, you can explicitly control the conversion by addding ConvertToRGB(matrix="rec709"), or ConvertToRGB(matrix="rec601") (just don't forget to remove them when encoding)

I checked the script in AvsPmod and didn't see the change in color when applying deep_resize. However AvsPmod has a setting to explicitly select which color matrix to use when previewing so that's probably why. What program did you use to preview?

I did use the Frame Properties tool in AvsPmod and the color primaries/matrix/tranfer are read as undefined until deep_resize is applied. Then they change to Rec.709. So I think what's happening in MeGUI is since the matrix properties are undefined it's just making an assumption based on frame size that the matrix is Rec.601 and using that to preview. But deep_resize explicitly sets the matrix properties to Rec.709 so when I apply that filter MeGUI changes it's preview matrix to match and that's why I'm seeing the difference.

Now I'm wondering, is deep_resize actually converting the color primaries/matrixes/transfers to Rec.709 or is it just flagging it as that in the frame properties. If it's just flagging it wouldn't that lead to improper color display at playback. But also if it's actually converting it, I noticed that it still changes it to Rec.709 if downsizing 480p video. Wouldn't that be incorrect? Shouldn't it stay at Rec.601 in that case?

Quote:

Originally Posted by poisondeathray

Maybe an issue with that version ? I was using r3835 . But I checked with r3877 - no problems either, I cannot reproduce either of your issues

Did you check the script in another application, such as mpchc, avspmod ? Maybe some specific issue with megui ?

I also checked this script in AvsPmod. It didn't have any issues running it. No errors. According to the frame properties though, deep_resize is changing the matrix from (1 [709]) to (12 [Chroma ncl]). Like you noted earlier the source video has odd color primaries, (12 [ST 432-1]). Since the code numbers are the same I'm guessing deep_resize is changing the matrix to match the primaries. And I'm assuming MeGui doesn't recognize the nonstandard matrix so throws back the error I've been getting when trying to preview. So how do I convert the color primary for this video? Or force deep_resize to use 709 instead of Chroma ncl?

But it seems both problems were in the MeGui previewer, not deep_resize. Although in the first instance I think MeGui handled the matrix display correctly, make an assumption about matrix based on source frame dimensions until matrix is specified. I prefer that to the way AvsPmod does it.

poisondeathray · 5th February 2023, 07:32

Quote:

Originally Posted by simple_simon

However AvsPmod has a setting to explicitly select which color matrix to use when previewing so that's probably why. What program did you use to preview?

avspmod, I have it set not to read from source, and resolution based . You can also explictly control the RGB conversion as mentioned earlier. It doesn't matter, as long as you keep in the back of your mind how it's being done

Quote:

Now I'm wondering, is deep_resize actually converting the color primaries/matrixes/transfers to Rec.709 or is it just flagging it as that in the frame properties.

You can insert a propshow() any point to determine if a filter is changing frame properties. If you set up avspmod correctly, you can view the actual YUV values with the color picker to see if any actual pixel value changes are occurring due to a filter. For colors, you can also test colorbars (and colorbars videos with tags) to easily see what's happening

Avisynth can pass frame properties to some programs -e.g. ffmpeg - so it actually can affect the end result and tagging and other program behaviour. Beware of or learn the new behaviour. Some people like to clear the props before encoding, and/or after loading video - so one option is to clear some or all of the properties after the source filter, or set some or all of them specifically .

Props are good and bad - but in some cases they can screw up the results if you're not careful - if a filter makes assumptions or uses values based on props. Sometimes videos are tagged incorrectly . A common one is "PAL" area distribution e.g. progressive content DVD's or BD's , that are encoded interlaced. Vapoursynth users are used to these "props" problems (props have been there a few years longer) but it has invaded avisynth now. Beware and there will be growing pains

You should notify megui developers about the preview issue

LeXXuz · 5th February 2023, 10:36

Quote:

Originally Posted by Dogway

EDIT: ScenesPack updated, ex_autolevels() in GradePack also updated.

Should I give that a try? If so, where to put it best and what settings to start from? I don't expect to get rid of that wobble, but I take anything that helps to reduce it.

Also right now I'm trying with much smaller temporal radii which seems to reduce the effect, as expected, but at the cost of losing precision. Maybe a mix of denoising and leaving some residual noise is best here. It still beats that clean but wobbly look.

DTL · 5th February 2023, 12:15

Quote:

Originally Posted by LeXXuz

I don't expect to get rid of that wobble, but I take anything that helps to reduce it.

As a starting solution you can try 'blind fix' - cut frame to a sub-clips with a fixed grid like 2x2 or 3x3 or more and apply stabilization to each sub-clip and stack subclips back. But it will produce more or less visible issues at the stacking borders looking like a fixed grid.

Second part of solution may be combining first and second (shifted to half of grid step diagonally) clips with same method as overlapping blocks for denoise - you can use BlockOverlap plugin or Overlay with manually painted mixing mask (or may be masktools can help).

But shifting diagonally 1/2 grid step for very dense grids for small blocks of denoise work good - leaving only 1/2 of blocksize uncovered regions near the very edges of frame. And shifting very large 'blocks' of stabilization with only something like 3x3 cutting grid may still leave large enough unfixed lines at the edges of the frame and may need more edges of frame workarounds.

Next step may be pad original frame with 'stab blocksize/2' borders and so you can provide 2 sets of the stabilized clips to BlockOverlap covering all parts of original frame.

BlockOverlap is https://forum.doom9.org/showthread.php?t=101307 and https://github.com/DTL2020/BlockOver...s/tag/v0.2-x64 x64 build.

Dogway · 5th February 2023, 15:56

Quote:

Originally Posted by LeXXuz

Should I give that a try? If so, where to put it best and what settings to start from? I don't expect to get rid of that wobble, but I take anything that helps to reduce it.

Yes, you can play with it, it will reduce the luma flicker. I just updated ScenesPack with a small fix to switch to plain mean metric when samples are too low.

Right now I'm playing with some ideas from Stab() using TemporalSoften to reduce the flicker further.

An example:

Code:

ffvideosource("noisy_original.mkv")

propSet("_FieldBased",0)
Stab()
SceneStats("Range+Stats")
pref = ex_autolevels()
temp =             Pref.TemporalSoften(5,255,0,25,2)   # SC thr to 25 otherwise pans will stutter
rep  = temp.Repair(Pref.TemporalSoften(1, 255,0,25,2))

pref=ex_merge(rep, pref,MotionMask(rep,scale=10,sharpness=5))
SMDegrain(6, 1000, mode="TemporalSoften",prefilter=pref,LFR=false,RefineMotion=true)

ex_unsharp(0.3)
gr = 1
size = (720/2133.) * 3.3
GrainFactory3mod(g1str=7*gr,g2str=9*gr,g3str=7*gr,g1size=1.7*size,g2size=1.4*size,g3size=1.4*size,g1cstr=0.5*gr,g2cstr=0.3*gr,g3cstr=0.1*gr,temp_avg=1,tv_range=true)

Result not perfect but hopefully an improvement: link

LeXXuz · 5th February 2023, 18:56

Thanks DTL and Dogway for your input. Really appreciate it.

Something new to fiddle around with the next couple of days.

simple_simon · 5th February 2023, 19:06

Quote:

Originally Posted by poisondeathray

avspmod, I have it set not to read from source, and resolution based . You can also explictly control the RGB conversion as mentioned earlier. It doesn't matter, as long as you keep in the back of your mind how it's being done

I don't really care if the colorspace isn't displayed correctly in the temporary preview. I just want it to be correct in the final playback file.

Quote:

Originally Posted by poisondeathray

You can insert a propshow() any point to determine if a filter is changing frame properties. If you set up avspmod correctly, you can view the actual YUV values with the color picker to see if any actual pixel value changes are occurring due to a filter. For colors, you can also test colorbars (and colorbars videos with tags) to easily see what's happening

propshow() is just going to tell me if the frame properties tags have changed. That still doesn't give me an answer about whether deep_resize is actually doing the colorspace conversion to go from SD --> HD colorspace when upsizing. Or just adding HD colorspace frame property tags. Maybe Dogway can chime in and specify what's actually going on behind the scenes.

Quote:

Originally Posted by poisondeathray

You should notify megui developers about the preview issue

The developer of megui hasn't been very active for a number of years now, unfortunately. It's still possible to update the various external supporting tools but the actual framework gui pretty much is what it is.

poisondeathray · 5th February 2023, 19:14

Quote:

Originally Posted by simple_simon

That still doesn't give me an answer about whether deep_resize is actually doing the colorspace conversion to go from SD --> HD colorspace when upsizing.

It's not currently. You get (essentially) the same results as Spline36Resize in terms of YUV values - Those are the actual values that get encoded

simple_simon · 5th February 2023, 20:44

Quote:

Originally Posted by poisondeathray

It's not currently. You get (essentially) the same results as Spline36Resize in terms of YUV values - Those are the actual values that get encoded

Well that really doesn't make sense for deep_resize to be changing the frame properties to 709 colorspace when it isn't. It should either assume the colorspace by the input frame resolution or leave it unspecified. Or require the user to explicitly state the input colorspace so it knows what frame property to output.

So what's the best way to handle this? Should I clear props after deep_resize to not confuse anything further along in the chain? And just encode it as 601? Or since deep_resize is flagging the video as 709 and since most playback software/hardware will assume 709 based on the HD frame resolution, should I already be converting the colorspace & range myself when upscaling to 720p or higher? Adding this before deep_resize:

Code:

ColorMatrix(mode="Rec.601->Rec.709",outputfr=true)

Or whatever the equivalent is in fmtconv. It's probably better but I haven't been able to decipher how to use it yet.

poisondeathray · 5th February 2023, 21:13

Quote:

Originally Posted by simple_simon

Well that really doesn't make sense for deep_resize to be changing the frame properties to 709 colorspace when it isn't. It should either assume the colorspace by the input frame resolution or leave it unspecified. Or require the user to explicitly state the input colorspace so it knows what frame property to output.

Many growing pains in avs-land for props

Quote:

So what's the best way to handle this? Should I clear props after deep_resize to not confuse anything further along in the chain? And just encode it as 601? Or since deep_resize is flagging the video as 709 and since most playback software/hardware will assume 709 based on the HD frame resolution, should I already be converting the colorspace & range myself when upscaling to 720p or higher? Adding this before deep_resize:

Code:

ColorMatrix(mode="Rec.601->Rec.709",outputfr=true)

Or whatever the equivalent is in fmtconv. It's probably better but I haven't been able to decipher how to use it yet.

I definitely would not encode and tag as 601. You have the highest chance of it playing correctly everywhere with the 601=>709 shift when going SD=>HD , and tagged as 709 in the encoder

Personally , I clear and do everything manually , because there are many "growing pains" with avisynth frame props right now. I also clear before the pipe out, because some filters screw up the props right now. I flag in the encoder instead of relying if avisynth will pass props correctly . (Some encoders do not accept, so do). You decide what works "best" for you

Yes, colormatrix, or zimg, or fmtc, or avisynthshader

avsresize would look like

Code:

z_convertformat(pixel_type=last.pixeltype,  colorspace_op="170m:709:709:l=>709:709:709:l")

5th February 2023, 18:56	#1996 \| Link
LeXXuz 21 years and counting... Join Date: Oct 2002 Location: Germany Posts: 716	Thanks DTL and Dogway for your input. Really appreciate it. Something new to fiddle around with the next couple of days.