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 4th January 2012, 23:01   #381  |  Link
Yellow_
Registered User
 
Join Date: Sep 2009
Posts: 378
sneaker_ger the greenish tint was from the thread cretindesalpes pointed to via #377.

Thanks to you both for the explanation.
Yellow_ is offline   Reply With Quote
Old 4th January 2012, 23:04   #382  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,111
Quote:
Originally Posted by cretindesalpes View Post
@sneaker_ger:

Actually the 10->16->10 bit conversion is neutral. It's probably a (minor) waste of processing power, but it seems to work as expected. See the discussion here.
Ah, I remember reading that in the changelog, but I didn't understand it at that time. So what's the point of using that script (aside from lowering processing power a bit)? Or was 10 bit output not supported at all prior?
sneaker_ger is offline   Reply With Quote
Old 5th January 2012, 00:12   #383  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 610
My previous script had 10-bit dithering with 16-bit output, based on the assumption that the 6 lowest bits would just be dropped or rounded to the nearest value when entering x264.
__________________
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 8th January 2012, 17:31   #384  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,413
Does MScaleVect work with the vector clip created by using multi=true in MAnalyse? The docs don't say anything about that, but I assume that it works as if the source clip was a regular clip containing one set of vectors.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 8th January 2012, 17:33   #385  |  Link
mp3dom
Registered User
 
Join Date: Jul 2003
Location: Italy
Posts: 1,023
I'm asking just to avoid further problems and to be sure...
If a progressive 16bit YV16 stacked clip needs to be converted to a 16bit YV12 stacked clip, can I safely use a plain ConvertToYV12() or do I need to pay attention to something (mainly the LSB part)?
Thanks
mp3dom is offline   Reply With Quote
Old 8th January 2012, 18:42   #386  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 610
Quote:
Originally Posted by Boulder View Post
Does MScaleVect work with the vector clip created by using multi=true in MAnalyse?
Hmm… I'm checking the code, and it might work, but there are things that must be fixed to be safe. Actually the flip parameter will not work at all.

Quote:
Originally Posted by mp3dom View Post
If a progressive 16bit YV16 stacked clip needs to be converted to a 16bit YV12 stacked clip, can I safely use a plain ConvertToYV12() or do I need to pay attention to something (mainly the LSB part)?
Your guess is right, it will not work out of the box. The chroma planes will be resampled, so they definitely have to be processed in 16 bits. I'll probably submit soon a new function to convert between the YUV modes.
__________________
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 13th January 2012, 18:13   #387  |  Link
Yellow_
Registered User
 
Join Date: Sep 2009
Posts: 378
In the bit depth increase with Dither tools is it possible to 'extract' xvYCC extended gamut from suitable sources to 16bit RGB. As explained here: http://sutlib2.sut.ac.th/sut_content...ATA/5637_2.PDF
Yellow_ is offline   Reply With Quote
Old 16th January 2012, 16:55   #388  |  Link
Overdrive80
Anime addict
 
Overdrive80's Avatar
 
Join Date: Feb 2009
Location: Spain
Posts: 625
Hi, is possible to use MT with this filter??? I tried but show error that says; try vertical.....
__________________
Intel i7-6700K + Noctua NH-D15 + Z170A XPower G. Titanium + Kingston HyperX Savage DDR4 2x8GB + Nvidia GTX750 2GB DDR5 + SSD Vertex 4 256 GB + Antec EDG750 80 Plus Gold Mod + Corsair 780T Graphite
Overdrive80 is offline   Reply With Quote
Old 17th January 2012, 02:03   #389  |  Link
Stephen R. Savage
Registered User
 
Stephen R. Savage's Avatar
 
Join Date: Nov 2009
Posts: 337
Quote:
Originally Posted by Overdrive80 View Post
Hi, is possible to use MT with this filter??? I tried but show error that says; try vertical.....
Internally, before each operation, Dither has to unpack a stacked frame into the interleaved version. Therefore, you need to use the "splitvertical" option in MT that processes the left+right sides of the frames simultaneously instead of the top+bottom. This is a terrible design decision in Dither and results in probably 10-20% performance loss shuffling bits around...
Stephen R. Savage is offline   Reply With Quote
Old 17th January 2012, 09:26   #390  |  Link
mp3dom
Registered User
 
Join Date: Jul 2003
Location: Italy
Posts: 1,023
Quote:
Originally Posted by cretindesalpes View Post
Your guess is right, it will not work out of the box. The chroma planes will be resampled, so they definitely have to be processed in 16 bits. I'll probably submit soon a new function to convert between the YUV modes.
Thanks for the explanation. On the contrary, may I assume that I can safely convert YV16 to YUY2 back and forth without too much trouble? They should be equal (apart the former being planar and the latter interleaved) and lossless.
mp3dom is offline   Reply With Quote
Old 17th January 2012, 16:20   #391  |  Link
Overdrive80
Anime addict
 
Overdrive80's Avatar
 
Join Date: Feb 2009
Location: Spain
Posts: 625
Quote:
Originally Posted by Stephen R. Savage View Post
Internally, before each operation, Dither has to unpack a stacked frame into the interleaved version. Therefore, you need to use the "splitvertical" option in MT that processes the left+right sides of the frames simultaneously instead of the top+bottom. This is a terrible design decision in Dither and results in probably 10-20% performance loss shuffling bits around...
Thanks for your answer. It's a shame to lose that speed of process.

@Cretindealpes

With this script
Code:
dfttest(tbsize=1,sigma=10,lsb=true)

LSharpAAF(aatype="supaa") #With any aa success the same

gradfun3(smode=1,lsb_in=true,mode=0,ampo=1.2)
I get this in bottom image:

__________________
Intel i7-6700K + Noctua NH-D15 + Z170A XPower G. Titanium + Kingston HyperX Savage DDR4 2x8GB + Nvidia GTX750 2GB DDR5 + SSD Vertex 4 256 GB + Antec EDG750 80 Plus Gold Mod + Corsair 780T Graphite

Last edited by Overdrive80; 17th January 2012 at 16:25.
Overdrive80 is offline   Reply With Quote
Old 17th January 2012, 19:48   #392  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 610
Boulder:

Dither 1.13.3 released.
I think I fixed the MScaleVect + multi issue but I couldn't test all the possible cases. Send feedback if something goes wrong.

Yellow:

Sounds complicated but doable. It would require a custom source plug-in.

Stephen R. Savage:

The actual reason is that MT() requires a constant clip height for horizontal division, and a constant clip width for vertical division. Anyway, the Dither tools have been designed with heavy filtering in mind (dfttest, motion compensation, bilateral filtering, etc). The overhead caused by the stack16 format is probably several orders of magnitude lower than the load of the whole filter chain, so I don't really care. Clearly not perfect from the programmer's point of view, but much more user-friendly than a straightforward interleaved format.

mp3dom:

Yes, the 16-bit conversion between YV16 and YUY2 is lossless. Regarding your previous request, the YV16-YV12 converter is a bit complicated to design (like the YUV-RGB conversion was) and I haven't much time to spend on it. Unfortunately it won't be ready "soon", contrarily to what I said previously.

Overdrive80:

The result of your dfttest command is a stack16 clip. If you display it, you'll find that the bottom part of the picture is full of colored garbage. So if you try to apply an anti-aliasing filter on it, both parts of the picture will interfere. Moreover, there is a risk of messing up the pixel MSB/LSB consistency. Try to apply the AA filter in the 8-bit land, before dfttest or after GradFun3. If you really want to apply the AA filter on the stack16 clip, see post #250, but it looks overkill to me just for one filter, I wouldn't recommend that in this situation.
__________________
dither 1.27.2 for AviSynth | avstp 1.0.3 for AviSynth development | fmtconv r19 for Vapoursynth | trimx264opt segmented encoding

Last edited by cretindesalpes; 17th January 2012 at 19:52.
cretindesalpes is offline   Reply With Quote
Old 17th January 2012, 20:05   #393  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,413
Quote:
Originally Posted by cretindesalpes View Post
Boulder:

Dither 1.13.3 released.
I think I fixed the MScaleVect + multi issue but I couldn't test all the possible cases. Send feedback if something goes wrong.
Thanks, I'll test it as soon as I have the time.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 17th January 2012, 22:27   #394  |  Link
Overdrive80
Anime addict
 
Overdrive80's Avatar
 
Join Date: Feb 2009
Location: Spain
Posts: 625
@Cretindealpes

Thanks, i will try after gradfun3. ^^
__________________
Intel i7-6700K + Noctua NH-D15 + Z170A XPower G. Titanium + Kingston HyperX Savage DDR4 2x8GB + Nvidia GTX750 2GB DDR5 + SSD Vertex 4 256 GB + Antec EDG750 80 Plus Gold Mod + Corsair 780T Graphite
Overdrive80 is offline   Reply With Quote
Old 18th January 2012, 16:54   #395  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 610
For unpatched 10-bit x264 builds, straight 16-bit input will cause errors, unless you have scaled the original data in the inverse way x264 does. For 8-bit input, I don't know if things have changed or not (likely not).

Dither_convert_8_to_16 and other modified filters just shift bits to produce 16 bit output (an extension of the Rec 709 method to convert between 8- and 10-bit data), which is not the way x264 works. Therefore, to encode 10-bit video, you'll have to provide x264 with 10-bit data to be sure it won't rescale them. So the fslg_dither_to_n_bits script (or any equivalent) is required if you want to preserve the exact data scale. If you don't care about pre-dithering to 10 bits, the script becomes much simpler:
Code:
Dither_lut16 ("x 64 / 0.5 + 1023 min", y=3, u=3, v=3)
Dither_convey_yuv4xxp16_on_yvxx ()
__________________
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 19th January 2012, 00:00   #396  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 610
If I understand correctly the x264 conversion code, the maximum value of the input scale (65535) is mapped onto the maximum value of the output scale (1023). So the error is roughly proportional to the value and remains below 1 quantum of the lowest bitdepth, in absolute value. That is -0.1 % for 10 bits.
__________________
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 21st January 2012, 23:09   #397  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,567
It is not directly related to this thread but does anyone knows a way to open 16bit image sequence (png or tif) in avisynth for further processing? I imagine it should be opened as stacked YV24. (YV12 is a no go, I don't want subsampled chroma, upscaling image 2x with point resize before import is a no go too - they'll be too big, I don't have space or time for this.). So far with hacked ffms2 I only managed to open one image (not sequence) as stacked yv12. But PNG showed some corruption (tif is fine) and anyway it was far from what I need...

Last edited by Keiyakusha; 21st January 2012 at 23:14.
Keiyakusha is offline   Reply With Quote
Old 26th January 2012, 06:36   #398  |  Link
atra dies
Registered User
 
Join Date: Jul 2011
Posts: 32
Pardon my inexperience but I have several important questions:

What operations are more correctly done in linear scale light:
downsizing I assume, denoising (mdegrain)?, smoothlevels 16bit (altering y levels)? I remember someone said anything that averages pixels in another thread. I put mdegrain between a linear/gamma conversion and it looked OK although I did catch a blurring in some hay during a fast camera pan.

And when using bilinear to downsize, because every other filter rings or has a dark line around edges, is the lowpass an accurate calculation obtaining the highest sustainable frequency without aliasing or is it a conservative generic value that is blurring the image? I used fh and fv of 1.3 and things looked much better without much aliasing if at all. I know spline was much sharper but as I said there were dark lines around edges. I understand there will be undesirable things happening in certain patterns like brick or criss crossed clothing designs and have seen this in some modern dvds.

If converting yv12 to yuy2 with the bug fix script in 2.5.8, does the bilinear lowpass here or any other time when upsizing? I would assume it's just the downsize that the lowpass is applied but considering some bugs that have come to light like mpeg1 chroma placement, I am paranoid.

This lowpass is why everyone rags on bilinear but I find the spline useful only if I want to sharpen my clips and I usually don't like the outcome of sharpening, even LSF, when I view the final dvd. I probably oversharpened as a little goes a long way as far as that's concerned. For awhile there I was using spline48 then 144 and I do not like the effect those produced. Two tap spline is what I would prefer. Anything more warps some details because they are sharpened too much.

Something to watch out for: I noticed some ringing introduced by msuper when sharp is set above bilinear interpolation.

Last edited by atra dies; 26th January 2012 at 08:16.
atra dies is offline   Reply With Quote
Old 26th January 2012, 10:20   #399  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 939
cretindesalpes, is it possible to have the previous version of dither? I am getting strange results with the newer and I'd like to compare them.
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 26th January 2012, 22:02   #400  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 610
Quote:
Originally Posted by atra dies View Post
What operations are more correctly done in linear scale light:
downsizing I assume, denoising (mdegrain)?, smoothlevels 16bit (altering y levels)?
Although it's technically correct, denoising in linear light isn't necessary, because usually noise pixel values are close to each other. Operating in linear light is better when averaged pixel values are far. Moreover, the current modified MDegrain accepts only 8-bit input, and the conversion to 8-bit linear is not recommended because of the important resolution loss in the dark range.

Quote:
And when using bilinear to downsize, because every other filter rings or has a dark line around edges, is the lowpass an accurate calculation obtaining the highest sustainable frequency without aliasing or is it a conservative generic value that is blurring the image?
The value is more or less arbitrary, but should be a decent compromise. It all depends on the interpolator frequency response shape. For example, the linear interpolator has a quite slow rolloff (huge aliasing excepted for highly oversampled data) and starts attenuating significantly the frequency content of the picture far before the Nyquist frequency. So if you increase fh and fv, you'll get a sharper picture but more aliasing. The visual result highly depends on the content nature. Anyway, for almost all filter (excepted sinc-based ones with a high number of taps), the default fh and fv values will bring you both aliasing and smoothing. Another thing to consider is that the ringing on the final video resulting from a large kernel is not necessarily bad. If the picture is scaled again during display, these ringing may contain valuable information that can help the display resizer to reconstitute fine details, instead of creating ringing and bluring where they didn't exist on the video. So it may look better at the native resolution, but worse when scaled.

Quote:
If converting yv12 to yuy2 with the bug fix script in 2.5.8, does the bilinear lowpass here or any other time when upsizing?
I'm not sure to understand the question. From a signal processing point of view, the resizer works like this:
  1. virtually upsample the picture to an infinite sampling frequency (like a continuous signal) by multiplying it with a Dirac impulse train (or grid, because we are in 2D). Muliplying is space domain is equivalent to convolving in frequency domain. Here, we get the picture spectrum mirrored and replicated. In one dimension: 0|¯\_|Fn becomes: ..._/¯¯¯\___/¯|¯\___/¯¯¯\_...
  2. Convolve the signal with the normalised kernel impulse. This is where filtering happens, because the kernel is intended to be an approximation of a brickwall lowpass filter. fv and fh are implicitly divided by an additional factor in case of downscaling. Convolving in space domain is equivalent to multiplying spectrums in frequency domain, and we try here to clear everything above the desired cutoff frequency.
  3. Then, the filtered signal is sampled again according to the new size, offsets, etc. This is where aliasing occurs, because the impulse spectrum may have a frequency content higher than both new and old nyquist frequencies, letting the rests of the mirrored parts fold and overlap where they shouldn't.
I don't know if I'm clear, but the important thing to understand it that there is always some kind of lowpass filtering during a scaling. Even upscaling.

Quote:
Originally Posted by tormento View Post
cretindesalpes, is it possible to have the previous version of dither? I am getting strange results with the newer and I'd like to compare them.
Yes, they should be all available, just change the version numbers in the zip file url. What kind of strange result are you getting?
__________________
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 January 2012 at 22:09.
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 17:50.


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