Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 19th August 2011, 05:14   #261  |  Link
atra dies
Registered User
 
Join Date: Jul 2011
Posts: 32
How do you do the pfclip? I want to use blur() but any other examples are welcome. I finally saw this in the dither doc and it looks pretty good. It says invalid arguments to function blur. I also tried it x 4 and as a variable.

Code:
o = last
Dither2Pre ("TTempSmoothf(maxr=2,lthresh=40,cthresh=40,strength=2,scthresh=32,pfclip=last.blur())",
overlap=0, tvopt=true)

Last edited by atra dies; 19th August 2011 at 05:16.
atra dies is offline   Reply With Quote
Old 19th August 2011, 05:41   #262  |  Link
MADAJ
Registered User
 
Join Date: Nov 2007
Posts: 54
Quote:
Originally Posted by cretindesalpes View Post
Is this related with this issue? But the difference should be hardly noticeable. If you really have a green tint, first check your masktools version (must be alpha 48 or later), then post your script and encoding command.
Yeah, that issue. I have the mentioned masktools version.

Script
Code:
gradfun3 #modified version where (result = last) instead of DitherPost()

Interleave (Dither_get_lsb (), Dither_get_msb ())
TurnRight ()
AssumeFieldBased ().AssumeTFF ()
Weave ()
TurnLeft ()
encoding command
Quote:
avs2yuv -raw "script.avs" -o - | x264-10bit --OTHER_SETTINGS --demuxer raw --input-depth 16 --input-res 1280x720 --fps 24000/1001 --output "out.mkv" -
I just wanted to compare the two scenarios (8bit-10bit and 8bit->16bit-10bit) and see which one gives better result, but I can't judge because of the green tint in the second case.
Theoretically, which one do you think is better?

I hope the bug get solved soon.
MADAJ is offline   Reply With Quote
Old 19th August 2011, 08:55   #263  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 610
Quote:
Originally Posted by atra dies View Post
How do you do the pfclip? I want to use blur() but any other examples are welcome.
Technically, it's possible to use a wrapper function around TTempSmooth and Blur, but I tried and it gave massive artifacts. This is one of the Dither1/2Pre() limitations.

Quote:
Originally Posted by MADAJ View Post
but I can't judge because of the green tint in the second case.
Theoretically, which one do you think is better?
If your 8-bit source is untouched (no use of GradFun3), both methods are (should be) equivalent. If you use GradFun3, direct 16->10 bits encoding should give better results than 16->8->10 via DitherPost().
__________________
dither 1.27.2 for AviSynth | avstp 1.0.3 for AviSynth development | fmtconv r19 for Vapoursynth | trimx264opt segmented encoding
cretindesalpes is offline   Reply With Quote
Old 22nd August 2011, 03:28   #264  |  Link
atra dies
Registered User
 
Join Date: Jul 2011
Posts: 32
Nevermind, I'm going with mdegrain sharp=2 if anything (and maybe pel=4).

I assume the output of dither 8 to 16 is supposed to have a plain green LSB(should be black?)?

Can 8 bit filters be used on msb and lsb separately (I remember you said something about processing luma separately) or is the lsb too sensitive (you mentioned protecting it with unsharp mask)? Or is it better to sharpen outside in 8 bit cause of artifacts. I'm thinking of limitedsharpenfaster here.


By the way for anyone wandering in and you don't know like me a few seconds ago, this is how you generate 16 bit with mdegrain, add lsb=true at the end. Does this process it in 16 bits or just output 16 bits? <-May be a stupid question like most of them.

Code:
super = MSuper(pel=4, sharp=2)
backward_vec2 = MAnalyse(super, blksize=4,isb = true, delta = 1, overlap=0,temporal=true)
forward_vec2 = MAnalyse(super, blksize=4,isb = false, delta = 1, overlap=0,temporal=true)
MDegrain1(super, backward_vec2,forward_vec2,thSAD=400,lsb=true)

or 

super = MSuper(pel=4, sharp=2)
backward_vec2 = MAnalyse(super, isb = true,  blksize=4,delta = 2, overlap=0,temporal=true)
backward_vec1 = MAnalyse(super, isb = true,  blksize=4,delta = 1, overlap=0,temporal=true)
forward_vec1 = MAnalyse(super, isb = false,  blksize=4,delta = 1, overlap=0,temporal=true)
forward_vec2 = MAnalyse(super, isb = false,  blksize=4,delta = 2, overlap=0,temporal=true)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400,lsb=true)
I tried all the block sizes and overlaps and temporal = true. This filter is driving me nuts but removes a lot of noise without blurring it like FFT. Still seems soft and motion looks a little blurred but not as bad as ttempsmooth. Still high thSAD settings only cause artifacts beyond 400 instead of removing more noise.

Can ditherpost or some other step convert to yuy2 or is it fine for avisynth to do that. I thought I saw that there was a bug with that command or was that just for interlaced true?

Also I'm seeking opinions on whether users remove 16mm grain mpeg2 blocking or leave as is since it is considered resolution by some.

Last edited by atra dies; 23rd August 2011 at 05:08.
atra dies is offline   Reply With Quote
Old 24th August 2011, 00:24   #265  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 610
Quote:
Originally Posted by atra dies View Post
I assume the output of dither 8 to 16 is supposed to have a plain green LSB(should be black?)?
Exactly.

Quote:
Can 8 bit filters be used on msb and lsb separately (I remember you said something about processing luma separately) or is the lsb too sensitive (you mentioned protecting it with unsharp mask)?
It's possible in some cases but not recommended. If you want to mix 8 and 16 bit processing, see post #250.

Quote:
this is how you generate 16 bit with mdegrain, add lsb=true at the end. Does this process it in 16 bits or just output 16 bits?
Input is 8 bits, output 16 bits and the internal processing is done in 32 bits.

Quote:
Can ditherpost or some other step convert to yuy2 or is it fine for avisynth to do that.
You can do it with ConvertToYUY2(), but the conversion will probably cancel the dithering benefits on the chroma plane (luma will stay fine).[/QUOTE]


・ ・ ・ ・・・◇◆◇・・・ ・ ・ ・

Dither 1.10.0 released:
  • Added Dither_addborders16.
  • Added the BT 709 curve to Dither_y_gamma_to_linear and Dither_y_linear_to_gamma, as well as the plane selectors.
  • Added the possibility to have static noise in DitherPost.
  • Added Dither_add_grain16, generating stabilized noise.
  • Added a dif parameter to Dither_add16.
  • Added the lsb and lsb_in parameters to GradFun3 to deal with 16-bit data. The function also accepts smaller radii than before.
__________________
dither 1.27.2 for AviSynth | avstp 1.0.3 for AviSynth development | fmtconv r19 for Vapoursynth | trimx264opt segmented encoding
cretindesalpes is offline   Reply With Quote
Old 24th August 2011, 22:54   #266  |  Link
Yellow_
Registered User
 
Join Date: Sep 2009
Posts: 378
cretindesalpes, excellent update. :-)

I have a bit of a query regarding spiking luma using Dither_y_gamma_to_linear function and conversion to RGB. :-)

I have two test video's, ones a h264 AVC off a Canon HDSLR and the other off a HDV camera both sources converted with Dither 1.10 and piped through avs2yuv to ImageMagick Q16 hdri build. Writing 16bit tifs & exr's.

Using a 709 curve with the h264AVC (BT601 Color Matrix, full range luma, 709 transfer curve) gives me spiked luma histogram, using the srgb curve doesn't.

But with the HDV video source (BT709 Color Matrix, full range luma, BT709 transfer curve) whether I use srgb or 709 curve both give smooth luma histogram and definite variation in 'exposure' which I anticipated.

The basis of the scripts is:

Quote:
Dither_convert_8_to_16 ()

Dither_convert_yuv_to_rgb(matrix="709", tv_range=false, cplace="MPEG2", chromak="bicubic", lsb_in=true, output="rgb48y")

Dither_y_gamma_to_linear (tv_range_in=false, tv_range_out=false, curve="srgb")

Dither_convey_rgb48_on_yv12 (SelectEvery (3, 0),SelectEvery (3, 1),SelectEvery (3, 2) )
Obviously I'm changing the matrix="" to suit colour matrix of source and adjusting pixel dims to avoid any scaling ie: 1920x1088 and 1440x1080.

What could be causing the spiking luma with the h264? I thought the problem lay with Imagemagick colorspace handling but that appears to be ok, considering HDV source works fine.

Thanks again for a great update.

Last edited by Yellow_; 24th August 2011 at 22:57.
Yellow_ is offline   Reply With Quote
Old 25th August 2011, 10:41   #267  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 610
Quote:
Originally Posted by Yellow_ View Post
Using a 709 curve with the h264AVC (BT601 Color Matrix, full range luma, 709 transfer curve) gives me spiked luma histogram, using the srgb curve doesn't.

But with the HDV video source (BT709 Color Matrix, full range luma, BT709 transfer curve) whether I use srgb or 709 curve both give smooth luma histogram and definite variation in 'exposure' which I anticipated.
Do you have source samples showing these spiked histograms? How does look the spikes? 8 to 16 bit conversions always give large histogram holes, just because we spread only 256 discrete values into 65536 slots. Some additional slots are filled with overshoot, ringing, bluring or other artifacts caused by the chroma resampling, but probably not enough to cover the whole 16-bit histogram continuously.
__________________
dither 1.27.2 for AviSynth | avstp 1.0.3 for AviSynth development | fmtconv r19 for Vapoursynth | trimx264opt segmented encoding
cretindesalpes is offline   Reply With Quote
Old 25th August 2011, 13:34   #268  |  Link
Yellow_
Registered User
 
Join Date: Sep 2009
Posts: 378
Quote:
Originally Posted by cretindesalpes View Post
Do you have source samples showing these spiked histograms?
I'll post a link to some examples once I get back to my machine later.

I wonder why I'm seeing this spikes when using rec709 inverse curve with h264 but not HDV, could this be more to do with compression type HDV vs h264, I don't see spikes with HDV so could this be luma deadzone quantisation in the h264 maybe?

The h264 bitrate is about 44Mbps compared to 20Mbps for the HDV, both consumer 4:2:0.
Yellow_ is offline   Reply With Quote
Old 25th August 2011, 19:15   #269  |  Link
SSH4
Registered User
 
Join Date: Nov 2006
Posts: 87
Quote:
Originally Posted by cretindesalpes View Post
[*]Added the possibility to have static noise in DitherPost.
Great! But i think one thing missed - seed like in AddgrainC that really neded for static noise. (Imagine encoding per chapters...)
SSH4 is offline   Reply With Quote
Old 25th August 2011, 19:42   #270  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 610
In static mode, the noise will remain the same and depends only on the frame size. The seed of random number generator is reset at the same value at the beginning of each plane. Therefore setting the seed explicitly is not needed.
__________________
dither 1.27.2 for AviSynth | avstp 1.0.3 for AviSynth development | fmtconv r19 for Vapoursynth | trimx264opt segmented encoding
cretindesalpes is offline   Reply With Quote
Old 25th August 2011, 20:24   #271  |  Link
SilaSurfer
Registered User
 
SilaSurfer's Avatar
 
Join Date: Oct 2009
Posts: 212
Quote:
Originally Posted by cretindesalpes View Post
[*]Added Dither_add_grain16, generating stabilized noise.

Nice cretindesalpes to see you are working on your functions. Dither_add_Grain 16 - is that to be used for banding prevention or is it for usage to add grain to the whole frame?
SilaSurfer is offline   Reply With Quote
Old 25th August 2011, 20:28   #272  |  Link
Yellow_
Registered User
 
Join Date: Sep 2009
Posts: 378
Quote:
Originally Posted by Yellow_ View Post
I'll post a link to some examples once I get back to my machine later.

I wonder why I'm seeing this spikes when using rec709 inverse curve with h264 but not HDV, could this be more to do with compression type HDV vs h264, I don't see spikes with HDV so could this be luma deadzone quantisation in the h264 maybe?

The h264 bitrate is about 44Mbps compared to 20Mbps for the HDV, both consumer 4:2:0.
Scrub this, I see spiking in the HDV's as well at closer inspection.

Once I apply gamma correction (rec709 or srgb) after compositing (32bit float), histogram smooths again. :-)

I guess some sort of levels smoothing would happen using other Dither functions, a denoiser or such?
Yellow_ is offline   Reply With Quote
Old 26th August 2011, 17:06   #273  |  Link
SSH4
Registered User
 
Join Date: Nov 2006
Posts: 87
cretindesalpes, is it possible made 1bit dithered image from gray with any of your functions from dither.dll?

small correction. what the fastest way for made this.

Last edited by SSH4; 26th August 2011 at 17:08.
SSH4 is offline   Reply With Quote
Old 26th August 2011, 19:55   #274  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 610
Quote:
Originally Posted by SilaSurfer View Post
Dither_add_Grain 16 - is that to be used for banding prevention or is it for usage to add grain to the whole frame?
There is no specific purpose, it was mainly a wOxxOm request. You can use it to add visible grain or to replace the internal noise generator in DitherPost(). It was much easier to write a separate function than changing DitherPost().

Quote:
Originally Posted by SSH4 View Post
cretindesalpes, is it possible made 1bit dithered image from gray with any of your functions from dither.dll?
small correction. what the fastest way for made this.
From an RGB picture in grey shades:
Code:
ShowRed ("YV12") # Or ConvertToYV12(matrix="PC.709")
StackVertical (last.BlankClip (color_yuv=0), last)
DitherPost (mode=7, u=1, v=1)
mt_binarize (threshold=0, u=-128, v=-128)
Output will be full range. For YV12 TV-range, replace the mt_binarize with mt_lut ("x 219 * 16 +", u=-128, v=-128).

EDIT:
For much more accurate results, dither in linear light by replacing the StackVertical() with:
Code:
Dither_convert_8_to_16 ()
Dither_y_gamma_to_linear (tv_range_in=false, tv_range_out=false, curve="srgb", u=1, v=1) 
Dither_lut16 ("x 256 /", u=1, v=1)
__________________
dither 1.27.2 for AviSynth | avstp 1.0.3 for AviSynth development | fmtconv r19 for Vapoursynth | trimx264opt segmented encoding

Last edited by cretindesalpes; 26th August 2011 at 20:21.
cretindesalpes is offline   Reply With Quote
Old 26th August 2011, 20:42   #275  |  Link
SSH4
Registered User
 
Join Date: Nov 2006
Posts: 87
Thanx! I thought about StackVertical-DitherPost-mt_binarize(or mt_lut) too.

Oh my god, i missed this - Dither_lut8, Dither_lutxy8, Dither_lutxyz8, Dither_lut16!

cretindesalpes may be possible made full 16bit (MSB/LSB) mod of masktools?
SSH4 is offline   Reply With Quote
Old 27th August 2011, 17:23   #276  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 949
Hello cretindesalpes, Im having problems with a source. Im trying to convert yuv to rgb32 skipping chroma planes all along, (output is greyscale). The code Im more confident with is the next but I tried many variations with no success:
Code:
SmoothGrad (thr=0.25, radius=16, stacked=true,u=1,v=1)

Dither_convert_yuv_to_rgb(lsb_in=true,tv_range=true,output="rgb48y")
ditherpost(mode=6,ampn=0.5,y=3,u=-128,v=-128)
MergeRGB(SelectEvery(3,0),SelectEvery(3,1),SelectEvery(3,2))
Main problems are first smoothgrad, there is no way to skip chroma and get correct results(screen is green), next is Dither_convert_yuv_to_rgb, I miss the u and v parameters, the output in this case is not 100% greyscale, you can find slight variations like 127,128,128, etc. Here ditherpost doesn't solve anything since mergergb creates these variations afterwards...

Last edited by Dogway; 27th August 2011 at 21:19.
Dogway is offline   Reply With Quote
Old 28th August 2011, 07:51   #277  |  Link
xackphair
SIEGE
 
Join Date: Jan 2011
Posts: 3
I am getting a ghosting problem that I do not remember seeing before. I am just using the basic
Code:
dfttest (lsb=true)
DitherPost ()
I will post images when my lossless is done. However, if you have an idea of what is going on, please let me know. Thanks!
xackphair is offline   Reply With Quote
Old 28th August 2011, 09:44   #278  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 610
Quote:
Originally Posted by xackphair View Post
I am getting a ghosting problem that I do not remember seeing before.
It's most likely a dfttest related problem. Dfttest is not protected against ghosting, therefore you have to MCompensate/Interleave the previous and next frames first, and SelectEvery the result. Check the Dither documentation, there is an example using the MCompensate functions. You can also check dfttestMC for a more complex example.


Quote:
Originally Posted by SSH4 View Post
may be possible made full 16bit (MSB/LSB) mod of masktools?
I don't think so. It's a huge amount of work. Moreover, straight multi-dimension 16-bit look-up tables wouldn't work because their size would be squared (hundreds of terabytes for a single lut_xyz16).


Quote:
Originally Posted by Dogway View Post
Main problems are first smoothgrad, there is no way to skip chroma and get correct results(screen is green)
This is normal. u=1 and v=1 means "don't care about the chroma planes", and the output can be any value, including invalid combinations with the luma plane. Green screen most likely means: chroma is all 0, and the luma could be anything. Just add a GreyScale() afterwards if you want to check the luma (but don't process a stack16 clip after a GreyScale, the chroma LSB will be wrong).
Quote:
next is Dither_convert_yuv_to_rgb, I miss the u and v parameters, the output in this case is not 100% greyscale, you can find slight variations like 127,128,128, etc. Here ditherpost doesn't solve anything since mergergb creates these variations afterwards...
The RGB conversion has no means to skip planes, however you are processing here the trashed chroma channels, so the conversion is definitely wrong. But if you want greyscale output, there is no need an RGB conversion. Just copy the Y channel directly to the R, G and B channels. You may also have to extend it to full range.
Code:
SmoothGrad (thr=0.25, radius=16, stacked=true,u=1,v=1)
Dither_lut16 ("x 4096 - 219 / 255 *", u=1, v=1) # TV range -> Full range
ditherpost(mode=6,ampn=0.5,y=3,u=1,v=1)
MergeRGB (last, last, last)
__________________
dither 1.27.2 for AviSynth | avstp 1.0.3 for AviSynth development | fmtconv r19 for Vapoursynth | trimx264opt segmented encoding
cretindesalpes is offline   Reply With Quote
Old 28th August 2011, 16:07   #279  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 949
Yeah, that was the problem, I couldn't use greyscale to LSB, besides LSB also stores chroma modification values. I also tried with u and v = -128 but output was also green. Also tried copying luma to the r,g,b channels but I missed the tv range thing, so THANKS a lot, this is something I already asked in the smoothadjust thread (equation of range conversion).

Im also interested in your opinion on my previous post
The main problem was floyd dithering on non mdegrain'ed areas (where there is motion) EX01. I came up with the EX04 workaround so ordered dithering is always used, does the logic work or you see any flaws in the code? I have in sight modifying my smdegrain mod upon your observations...

Last edited by Dogway; 28th August 2011 at 22:43.
Dogway is offline   Reply With Quote
Old 29th August 2011, 18:29   #280  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 610
Quote:
Originally Posted by Dogway View Post
I also tried with u and v = -128 but output was also green.
If the output clip is 16 bits, filling values have to be 16 bits too, so it's u and v = -128*256

Quote:
Im also interested in your opinion on my previous post
The main problem was floyd dithering on non mdegrain'ed areas (where there is motion) EX01. I came up with the EX04 workaround so ordered dithering is always used, does the logic work or you see any flaws in the code? I have in sight modifying my smdegrain mod upon your observations...
Oh I haven't realized you updated your post. I don't know if the MDegrain difference is reliable enough to build the mask. Intuitively, I would have used a combination of the MMask() SAD results, but your solution looks fine too. Maybe it's possible to get rid of the second MDegrain and compare ms2.DitherPost(mode=-1) to la2? But I suppose you probably had good reasons to use a second MDegrain. Anyway, it seems that differences between EX01 and EX04 are minor.
__________________
dither 1.27.2 for AviSynth | avstp 1.0.3 for AviSynth development | fmtconv r19 for Vapoursynth | trimx264opt segmented encoding
cretindesalpes is offline   Reply With Quote
Reply

Tags
color banding, deblocking, noise reduction

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:15.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.