Color banding and noise removal

[cretindesalpes]

Oh I can just make the message more explicit.

[cybersharky]

QTGMC( Preset="Slow",FPSdivisor=2)
o=last
super = MSuper(pel=2,sharp=2)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
bc1 = o.MCompensate(super,backward_vec1)
fc1 = o.MCompensate(super,forward_vec1 )

Interleave(fc1,o,bc1)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)
SelectEvery(3,1)

How do I use MDegrain2 as the denoiser with MCompensate?

[StainlessS]

You would (I think) need a new Super & set of vectors on the interleaved clip as the ones already calculated
relate to the original (o) clip and not the interleaved one.
Could well be wrong but think that there is little to be gained by doing motion compensation twice.
Suggest that you just use instead, the function linked below after QTGMC.
http://forum.doom9.org/showthread.php?p=1508289#post1508289 # By Didee, MCDegrain

EDIT: Changed above link to point to specific post rather than thread.

EDIT: Ref the code in prev post, if you throw away the vec2 vectors, then you could use as is
using some denoiser that takes a single frame either side of the frames to denoise eg FFT3DFilter,
instead of the call to MDegrain2 (which requires two frames either side of frame to denoise).

EDIT: If this is for B5 Ivana's head spots, then perhaps QTGMC has already applied temporal denoising
and partially migrated some of the spots into adjacent frames making it difficult to remove the spots later.
Despotting really should be done before any temporal processing, perhaps on even/odd separated fields,
separately.

[GMJCZP]

Continued instability in MVTools (see my previous post). :(

PD: Or is it a incompatibildad with the latest version of avisynth?

[cretindesalpes]

QMJCZP:

Please be more specific. I would need your script, as simple as possible to make it crash, and an excerpt of your source clip that exhibits the problem.

[GMJCZP]

Here the sample and script:

Here (http://www.mediafire.com/?vaiwldoae21pft7)

Thanks.

[ajp_anton]

I feel like I missed something trivial, but is there an easy way to convert RGB24 to RGB48?

[cretindesalpes]

QMJCZP:

Thank you. I'll check your sample.

ajp_anton:

To convert from RGB24 to the format I call RGB48Y:
Interleave (
\ ShowRed (pixel_type="YV12"),
\ ShowGreen (pixel_type="YV12"),
\ ShowBlue (pixel_type="YV12"))
Dither_convert_8_to_16 ()

[ajp_anton]

That's what I ended up using. I just thought there'd be an easier way. Why not make dither_convert_8_to_16 support RGB also?
BTW, any reason not to have RGB48 as stacked RGB instead of 3x stacked Y-planes?

[cretindesalpes]

Because these tools are designed to work with planar data, which RGB is not. I could make them support any possible colorspace but this is a lot of work I don't want to do. My main goal for the version 1 of this package is to bring new possibilities in Avisynth processing, not to achieve production-class tools. That's why everything looks like clumsy hacks ; I just don't care about elegant design because I didn't plan any specification or anything, I just go where it looks interesting at the moment.

[cybersharky]

It appears I'm also encountering MVTools issues.

SetMemoryMax(512)
SetMTMode(2,0)
LoadPlugin("D:\MeGUI_OneClick_Preview\tools\avisynth_plugin\mvtools2.dll")
LoadPlugin("D:\MeGUI_OneClick_Preview\tools\avisynth_plugin\avstp.dll")
LoadPlugin("D:\MeGUI_OneClick_Preview\tools\avisynth_plugin\dither.dll")
Import("D:\MeGUI_OneClick_Preview\tools\avisynth_plugin\QTGMC-3.33.avsi")
Import("D:\MeGUI_OneClick_Preview\tools\avisynth_plugin\dither.avsi")
Import("D:\MeGUI_OneClick_Preview\tools\avisynth_plugin\mt_xxpand_multi.avsi")
LoadPlugin("D:\MeGUI_OneClick_Preview\tools\avisynth_plugin\mt_masktools-25.dll")
LoadPlugin("D:\MeGUI_OneClick_Preview\tools\avisynth_plugin\RemoveGrainSSE2.dll")
LoadPlugin("D:\MeGUI_OneClick_Preview\tools\avisynth_plugin\NNEDI3.dll")
LoadPlugin("D:\MeGUI_OneClick_Preview\tools\avisynth_plugin\TTempSmooth.dll")
LoadPlugin("D:\MeGUI_OneClick_Preview\tools\avisynth_plugin\FFT3DFilter.dll")
Import("D:\MeGUI_OneClick_Preview\tools\avisynth_plugin\McDegrainSharp.avsi")
LoadPlugin("D:\MeGUI_OneClick_Preview\tools\dgindex\DGDecode.dll")
mpeg2source("C:\Users\me\Documents\DVDrips\BABYLON5_S4_DISC4_E15\VIDEO_TS\VTS_01_1.d2v")
QTGMC( Preset="Slow",FPSdivisor=2)
LanczosResize(640,368)
McDegrainSharp()
GradFun3 ()


Faulting application name: x264.exe, version: 0.124.2197.0, time stamp: 0x4f97d104
Faulting module name: mvtools2.dll, version: 2.6.0.3, time stamp: 0x4faf77d0
Exception code: 0xc0000005
Fault offset: 0x000a2a61
Faulting process id: 0x1a0c
Faulting application start time: 0x01cd39855f35be4d
Faulting application path: D:\MeGUI_OneClick_Preview\tools\x264\x264.exe
Faulting module path: D:\MeGUI_OneClick_Preview\tools\avisynth_plugin\mvtools2.dll
Report Id: a725c16f-a578-11e1-8831-1c6f65d777b9
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2012-05-24T08:15:42.000000000Z" />
<EventRecordID>27978</EventRecordID>
<Channel>Application</Channel>
<Computer>my-PC</Computer>
<Security />
</System>
<EventData>
<Data>x264.exe</Data>
<Data>0.124.2197.0</Data>
<Data>4f97d104</Data>
<Data>mvtools2.dll</Data>
<Data>2.6.0.3</Data>
<Data>4faf77d0</Data>
<Data>c0000005</Data>
<Data>000a2a61</Data>
<Data>1a0c</Data>
<Data>01cd39855f35be4d</Data>
<Data>D:\MeGUI_OneClick_Preview\tools\x264\x264.exe</Data>
<Data>D:\MeGUI_OneClick_Preview\tools\avisynth_plugin\mvtools2.dll</Data>
<Data>a725c16f-a578-11e1-8831-1c6f65d777b9</Data>
</EventData>
</Event>

[Dogway]

Just wanted to add my 2cents. I got a thread deadlock while encoding to FFV1, I don't know if it's relevant since I don't encode as often but I used:
setmtmode(2,2)
smdegrain(...)
I wonder if that's right, or avstp.dll has crashes with MT, I chose to take out avstp.dll for that specific encode. Hope it helps...

[Boulder]

I had issues with MVTools internal multithreading and SetMTMode, disabling internal multithreading fixed them.

[Boulotaur2024]

Yeah, I've always had troubles using anything else than SetMtMode(5) or no SetMtMode at all iirc, the recommended SetMtMode(3) MySource() SetMtMode(2) SMDegrain always crashed eventually even though it first looked like it was about to work.

By the way a huge thanks to CretinDesAlpes (chapeau l'artiste si tu me permets), it really felt like night and day between not using your tools at all and learning how to finally properly use them (it's not so easy though). The added value is like 200% on the final encode, I've always wanted to thank you but couldn't for some reason. You have all my respect... and more

[cretindesalpes]

Boulotaur2024:

Thanks for your support!

Dogway:

I couldn't reproduce the deadlock. I used smdegrain() with default settings, and encoded ~10000 PAL frames with FFV1 in CLI FFmpeg.

EDIT: I tried with tr=4 and it freezed after 4500 frames. Now I have something to investigate!

cybersharky:

I couldn't reproduce the crash. I tried encoding about 20000 frames. However:
– I don't know the number of threads you used, as you just specified 0 in the SetMTMode parameter. I tried with 4 threads (my native configuration).
– It's strongly advised to run the source filter (mpeg2source here) in MT mode 5 and to switch to mode 2 afterwards.

QMJCZP:

I couldn't make your script crash. But I have a few more questions:
– Could you confirm that the script crashes with the exact source sample you provided in the zip file? It is very short, and the script loaded a different file.
– The SetMTMode() functions were commented in your script, and I have no idea what was the number of threads it actually used. This matters because of the related memory usage, the cache memory being fixed to 512 KB.
– I couldn't find any function called PreF_MDeGrain2.avsi (apparently from John Meyer), so I had to bypass it. I would need it to check the script.
– While looking for a link to this function, I stumbled across a Didée's post (http://forum.doom9.org/showpost.php?p=1345390&postcount=1285) regarding a Clense instability in MT mode. And your script uses Clense via RemoveDirt2. So you could try to replace it with the Didée's suggestion.

[GMJCZP]

Thanks for your support!

QMJCZP:

I couldn't make your script crash. But I have a few more questions:
– Could you confirm that the script crashes with the exact source sample you provided in the zip file? It is very short, and the script loaded a different file.
– The SetMTMode() functions were commented in your script, and I have no idea what was the number of threads it actually used. This matters because of the related memory usage, the cache memory being fixed to 512 KB.
– I couldn't find any function called PreF_MDeGrain2.avsi (apparently from John Meyer), so I had to bypass it. I would need it to check the script.
– While looking for a link to this function, I stumbled across a Didée's post (http://forum.doom9.org/showpost.php?p=1345390&postcount=1285) regarding a Clense instability in MT mode. And your script uses Clense via RemoveDirt2. So you could try to replace it with the Didée's suggestion.

Thanks cretindesalpes:

I will answer in order:

- The source is the same, what happens is that as I have no internet itself I could not upload a file larger. The script is generic, because it is for a series of DVDs.
- Indeed, I use SetMTMode (), what happens is grayed out to prevent the crash, for your testing simply remove the # to the left of the command. My PC is a Core 2 Duo E4400 with 2GB RAM.
- Sorry for not having included PreF_MDeGrain2 function, here the script:

function PreF_MDeGrain2(clip src)
{

preNR = src.unfilter(-6,-6)

preNR_super = preNR.MSuper(pel=2, sharp=1)
src_super = src.MSuper(pel=2, sharp=1, levels=1)

backward_vec4 = MAnalyse(preNR_super, isb = true, delta = 4, overlap=4)
backward_vec2 = MAnalyse(preNR_super, isb = true, delta = 2, overlap=4)
forward_vec2 = MAnalyse(preNR_super, isb = false, delta = 2, overlap=4)
forward_vec4 = MAnalyse(preNR_super, isb = false, delta = 4, overlap=4)

src.MDegrain2(src_super, backward_vec2,forward_vec2,backward_vec4,forward_vec4,thSAD=400)
}

- I'll try the Didée's suggestion. Thanks for the tip.

Whatever else you need let me know.
Good luck, and thanks again.

[cretindesalpes]

QMJCZP:

Thank you. But I still couldn't make the script crash.

Dogway:

OK, I think I found the problem. Please update avstp (http://forum.doom9.org/showthread.php?p=1564516#post1564516).

[Lenchik]

Someone may be interested in implementation of such conversion through Dither plugin: http://forum.doom9.org/showthread.php?p=639432#post639432

[nhope]

I'd be interested in suggestions for dealing with the banding that you see starting at about 03:00 in my test video on YouTube (http://www.youtube.com/watch?v=u5qmfIKGMKA), as the blue opening of the cave fades up from black.

The clip was shot in HDV (1440x1080-60i). There is no significant banding in the original clip. There is some noise. For YouTube I bobbed to 30p as follows, then wrote an RGB UT Video Codec lossless intermediate for further editing in Vegas, then encoded it to x264 in MeGUI at crf 18.

#Clip frameserved in RGB from Sony Vegas Pro
AviSource("d:\fs.avi")
ConvertToYV12(interlaced=true)
AssumeTFF
QTGMC( Preset="Slower", EdiThreads=2 )
Spline36Resize(1920,1080)
AssumeFPS(29.97)

I can provide source if it helps. If so, the original .m2t HDV file, or the lossless file from later in the process?

[Reel.Deel]

Hi nhope, I'm assuming your original HDV source is YUV 4:2:0. Correct? Why not deinterlace in it's original color space and save to a lossless file and then import to Vegas? It saves you from having extra unnecessary color space conversions.

BTW the link to your video on youtube does not work.

[-Vit-]

I'd be interested in suggestions for dealing with the banding that you see starting at about 03:00 in my test video on YouTube (http://www.youtube.com/watch?v=u5qmfIKGMKA), as the blue opening of the cave fades up from black.
Before you start debanding it you could try to remove the cause of the banding. Maybe x264 or QTGMC. For the occasional manual fade you can use x264 zones: for example add: --zones 100,200,b=1.5 to the command line to give 1.5x bitrate to frames 100 to 200. Add multiple zones so: --zones 100,200,b=1.5/400,500,b=1.5. You can also adjust the quantizer with q=x instead of b=x, but I find that value hard to guess at. (Edit: CRF 18 sounds plenty for 1080, but sometimes x264 seems to underestimate the bitrate needed on fades)

In QTGMC, adding DCT=5 sometimes helps with fades.

[nhope]

BTW the link to your video on youtube does not work.
Thanks. Now fixed (http://www.youtube.com/watch?v=u5qmfIKGMKA).

I'm assuming your original HDV source is YUV 4:2:0. Correct?
Correct.

Why not deinterlace in it's original color space and save to a lossless file and then import to Vegas? It saves you from having extra unnecessary color space conversions.

What source method would you suggest? I wanted to use DGIndex/MPEG2Source directly on the file, having read that it's the preferred option (http://forum.videohelp.com/threads/343362-Avisynth-MPEG2Source) for MPEG source, but it "expanded" my colorspace to PC levels, even if I selected "TV Scale" in the video options. Same with FFVideoSource. If I "squeezed" that back with SmoothLevels(preset="pc2tv"), the result is much further away from the original than if I go via RGB then YV12 as in the script I posted.

Before you start debanding it you could try to remove the cause of the banding...
Thanks. I'll try out your suggestions.

Notwithstanding -Vit-'s suggestions, which of the following scripts makes more sense for avoiding banding in this scenario? Or something else? And should I be looking at using a "coarser" dither?

...
QTGMC()
Spline36Resize(1920,1080)
dfttest (lsb=true)
DitherPost ()

...
QTGMC()
Spline36Resize(1920,1080)
GradFun3 ()

[nhope]

Well, I'm getting a pretty good result with this...

QTGMC( Preset="Slower" )
Spline36Resize(1920,1080)
dfttest
GradFun3 (radius=16)

... but the overall luminance of the "bounces" up and down compared to the more noisy original. Adding ampo=2 made that worse (although it seems to give a little less banding when studying an individual frame).

Now I'm wondering if all I should be doing to avoid this banding in the fade on YouTube is just to add noise with AddGrainC? Or if it's simply unavoidable no matter what I do due to YouTube's encoder and the Flash Player?

I'm also interested in what the code might be for implementing a mask that would make the filter only operate on the blue water and not the darker areas of the diver and near-black cave.

Here's a link to a frame grab (http://dl.dropbox.com/u/21489814/cave-after-qtgmc-no-denoise-no-debanding.png) after QTGMC and resizing, but without any denoising or debanding/dithering. And here's a link direct to the part of the video (http://www.youtube.com/watch?v=u5qmfIKGMKA#t=00m30s) with the "radiating" banding. Obviously it behaves differently at different resolutions.

[cretindesalpes]

It will be very difficult to get rid of the band crawling in a Youtube video. Maybe you can try GradFun3 (mode=6, ampn=4, staticnoise=true) on this fade, but I doubt it will be of any use.

You could also give a try to the LumaDB (http://www.mediafire.com/?gfvlpplt03rmm#wty3h3izyk5md) script.

[Reel.Deel]

What source method would you suggest?

Hi nhope, for the most part I usually use DGIndexNV and sometimes FFMS2. I use them on my Canon DSLR files with the Cinestyle profile and the colors do not get expanded nor squeezed.

Maybe it would be best if you upload a sample from the original file.

[poisondeathray]

Probably not much you can do. Even if you "fix" it on your end before uploading, by the time YT re-encodes it - the "banding" will come back . You need lots of bitrate to retain dither and noise, and 10bit helps but that's not applicable here







What source method would you suggest? I wanted to use DGIndex/MPEG2Source directly on the file, having read that it's the preferred option (http://forum.videohelp.com/threads/343362-Avisynth-MPEG2Source) for MPEG source, but it "expanded" my colorspace to PC levels, even if I selected "TV Scale" in the video options. Same with FFVideoSource. If I "squeezed" that back with SmoothLevels(preset="pc2tv"), the result is much further away from the original than if I go via RGB then YV12 as in the script I posted.



They don't "expand" anything . Both FFMS2 and MPEG2Source serve the original YV12. It might be vegas and studio RGB workflow , but you have to be more clear on the exact steps you are using

[nhope]

Thanks for the replies. LumaDB at default settings is very bandy. GradFun3 (mode=6, ampn=4, staticnoise=true) is looking very promising! It previews more nicely than everything else I've tried. When I went to encode in MeGUI so I could upload some further tests to YouTube I was mysteriously struck by this problem (http://forum.doom9.org/showthread.php?p=1576774#post1576774) so I'll report back about the colorspace stuff after I've sorted that out.

[raido]

I've been using...

zzz_denoise ()
DitherPost (mode=2)

It's awesome. I workes really well at reducing posterization. Typically my sources have noise that I haven't fully eliminated. Sometimes when this noise is encoded, the posterization "flickers" on the borders between each band. This filter is the closest thing I've found that comes close to completely eliminating them while retaining detail. I also got a 10% reduction in file size (using crf 21). The thing is that it's really slow (getting about 3 fps on a 720x576 source). I tried setmtmode 2,3,4 and they don't seem to work. Can this be multithreaded?

[Revgen]

Here is >>>> dither-1.17.0.zip <<<< (http://ldesoras.free.fr/src/dither-1.17.0.zip).

The link isn't working for me. AVSTP link isn't working either.

EDIT

Link works now. Thank You.

[Lenchik]

Dither_convert_yuv_to_rgb (lsb_in=true)
Dither_convert_rgb_to_yuv (SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2),
\ lsb=true, output="YV24")
Is this the only way to convert from YV12 to YV24 or YV16? Is there or will be any way to convert it without going to RGB?

[cretindesalpes]

Dither 1.18.0: (http://forum.doom9.org/showthread.php?p=1386559#post1386559)

Added Dither_quantize to dither to bitdepths higher than 8 (almost the same function as previously posted on this thread).
Added Dither_srgb_display for Y'CbCr preview and accurate screen captures.
More meaningful error messages about wrong clip formats.
SmoothGrad and Dither_box_filter16 now work correctly on picture of width > 2048
Fixed a bug in multithreaded Dither_resize16.
Bug fixed in MVTools (multithreaded MCompensate).

Lenchik:

Here is another solution to go from YV12 to YV24, assuming progressive frames and MPEG-2 chroma placement:
# Stack16 clip on input

w = Width ()
h = Height () / 2
u = UToY8 ().Dither_resize16 (w, h, kernel="spline36", src_left=0.25, u=1, v=1)
v = VToY8 ().Dither_resize16 (w, h, kernel="spline36", src_left=0.25, u=1, v=1)
YToUV (u, v, last)

# Stack16 clip on output

I hope I got the src_left coefficient right, chroma placement always give me headaches. Use w = Width () / 2 and src_left=0 to obtain 4:2:2 instead of 4:4:4.

[wOxxOm]

Added Dither_quantize to dither to bitdepths higher than 8 (almost the same function as previously posted on this thread).That old function with 10bit dithering hack wasn't applying dither to msb and copied it as is, actually dithering only the least significant 2 bits - and what about Dither_quantize?

[cretindesalpes]

I was referring to this function (http://forum.doom9.org/showthread.php?p=1519194#post1519194), which works as expected.

[wOxxOm]

Oh, thanks, I overlooked that one. However why isn't there a 'mode' parameter?

[cretindesalpes]

You're right, I forgot it… :eek:

You can redownload the archive, I've just fixed it without changing the version number.

[Reel.Deel]

Thanks for the update cretindesalpes! I noticed that avstp is still v.1.0.0 instead of v.1.0.1. I don't know if this is by mistake or not.

[Tempter57]

cretindesalpes

This is taken from the dither.avsi documentation:
dfttest (lsb=true)
SmoothGrad ()
Dither_quantize (10, mode=6,reducerange=true)
Dither_convey_yuv4xxp16_on_yvxx ()

[cretindesalpes]

Reel.Deel:

Yes, a mistake again, shame on me. The package is updated to v1.18.1 with the right dll version. I hope I got everything right this time.

Tempter57:

Use reducerange=true only if you want to encode with --input-depth 10. In this example, the bitdepth was still 16. But it wasn't very clear actually, so I elaborated a bit more.

[shark000X]

cretindesalpes, hi!

Thank you very much for the great tools that for last years stay to be revolutionary from a technical point of view.

It seems, if we use
Dither_convert_8_to_16()
Dither_quantize(8, mode=6, reducerange=false)
no matter which mode, the result is the same as if Dither_quantize is not used at all. Is it a feature, or my mistake?
In the above example the reducerange=true variant just flips the MSB and LSB, no other changes also.
May be the Crop() is enough here to go back to the natural 8 bits?

Thanx

[mandarinka]

The first command sets LSB part to zeros. Therefore, the second command dithers those zeros into the unchanged MSB. It's sorta logical for the MSB part (8-bit) to be unchanged after that. And since the LSB was zeros too, nothing changed there too.

[Reel.Deel]

Hello, I keep getting the green screen problem when I use Dither_convert_8_to_16(). I'm using the latest MaskTools 2. I searched hi and low for older versions of masktools on my system but came up with nothing. Dither was working just fine about a month ago and everything seemed to be ok. I went back to and older version of dither and it did not fix it. I'm using Windows XP 32bit and running SEt's latest Avisynth. Any suggestions will be greatly appreciated.

[cretindesalpes]

Please post your script.

[mandarinka]

Are you sure you have the right dll too? mt_masktools-25.dll for avisynth 2.5.8, or mt_masktools-26.dll for avisynth 2.6?

[SilaSurfer]

cretindesalpes hello.

Could you post an example of multicompensating temporal-spatio denoiser like FFt3dfilter or Dfttest using Multi vectors. I can't get it right.

[Reel.Deel]

Hello, this is the script I have been using. I have tried the official version of MastTool2 v2.0a48 and also Vit's MaskTool2 v2.0a48 modded for the updated 2.6 interface. Both seem to produce the same green screen.

setmemorymax(1024)

#Load Plugins

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\Dither\avstp.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\Dither\dither.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\Dither\mt_masktools-26.dll")
#LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\Dither\mt_masktools-26 vit.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\Dither\mvtools2.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\Dither\dfttest.dll")

#Load Scripts

Import("C:\Program Files\AviSynth 2.5\plugins\Dither\dither.avsi")
Import("C:\Program Files\AviSynth 2.5\plugins\Dither\mt_xxpand_multi.avsi")

#=============================================================================

SETMTMode(3,0)

#Source

FFVideoSource("MVI_1397.MOV")

SetMTmode(2)

Dither_convert_8_to_16 ()

Dither_resize16 (1280, 720)

I only get the green screen problem lower half after using Dither_convert_8_to_16 (). If I add Dither_resize16 (1280, 720) the green screen problem goes away and the LSB looks correct ( at least I think :) ) Is this the expected behavior of dither?

I was snooping around the dither.avsi, out of curiosity is this all that Dither_convert_8_to_16 is? I know I must be missing something.

Function Dither_convert_8_to_16 (clip src)
{
StackVertical (src, src.Dither_gen_null_lsb ())
}

Function Dither_gen_null_lsb (clip src)
{
vers = VersionNumber ()
p_t = (vers < 2.60) ? "YV12" : Dither_undef ()
BlankClip (src, pixel_type=p_t, color_yuv=0)
}

Function Dither_undef () {}

[Lenchik]

Here is another solution to go from YV12 to YV24, assuming progressive frames and MPEG-2 chroma placement
Great script! Thank you! Never thought that simply putting clips of proper dimensions to YToUV will create YV24 or YV16.
Cheat sheet of chroma placement for such script (and maybe for interlaced material in advance) would be great too.

[cretindesalpes]

SilaSurfer:

tr = 3 # Temporal radius
sup = MSuper ()
vec = sup.MAnalyse (multi=true, delta=tr, blksize=8, overlap=4)
MCompensate (sup, vec, tr=tr, thSAD=200)
dfttest (sigma=8, tbsize=tr*2+1)
SelectEvery (tr*2+1, tr)

Reel.Deel:

It's perfectly normal to have a green half screen on the bottom part. It means all LSB data are 0, which is normal right after a Dither_convert_8_to_16. If you put a DitherPost() just after, you'll see that everything is fine. The symptom of a wrong Masktools version is 100 % green screen whatever the original content.

[Reel.Deel]

Thanks for fast responce cretindesalpes!

I guess I just got a little paranoid after seeing the naked results of Dither_convert_8_to_16. :)

[SilaSurfer]

cretindesalpes thanks for helping out.

[atra dies]

"709" ITU-R BT.709 transfer curve for digital video
"601" ITU-R BT.601 transfer curve, same as "709"
"170" SMPTE 170M, same as "709"
"240" SMPTE 240M (1987)
"srgb" sRGB curve

These are the current possible curve values in the dither.html for linear to gamma to linear. I used default for SD content a month or two ago and remember seeing it defaulted to srgb and then looked that up to see if it was the same as 601. (I am not clear on this stuff, I just read something about srgb and 709 are the same till you get near zero, there's a hook to prevent something and shadows are lifted or something like that) Were the curves right then? I can easily do them over.

For SD, use 601, which is the same as 709, which is for HD too? srgb is for computer images?

Also, I'm not complaining just letting you know in case you want to know in the dither html I see things copied to their inverse functions like The matrix used to convert the Y’CbCr pixels to R’G’B’. is found under Dither_convert_rgb_to_yuv when it should be rgb to ycbcr pixels, right?