Color banding and noise removal

[Izuchi]

Is it possible to to serve high bit depth scripts to Virtualdub and create lossless 16-bit avi files which can then be encoded using x264 --input-depth 16? I think I know the answer, but just want to make sure.

[feisty2]

dither_out ()

[Reel.Deel]

Originally Posted by Izuchi

Is it possible to to serve high bit depth scripts to Virtualdub and create lossless 16-bit avi files which can then be encoded using x264 --input-depth 16? I think I know the answer, but just want to make sure.

Why not just use Avs2YUV or avs4x26x to pipe high bit-depth video to x264?

Originally Posted by feisty2

dither_out ()

I see why you have 1,226 posts...

[Sparktank]

Shouldn't you be able to encode to x264 using avs2yuv/av4x26x ?
Using Dither_out()

The documentation gives example to encode 10bit:

Dither_quantize (bitdepth=10)
Dither_out ()

Which works if you set:

avs2yuv -raw "script.avs" -o - | x264-10bit --demuxer raw --input-depth 16

VDub should not really be needed. Unless you want a lossless intermediate.
Which would probably serve better if you used FFMPEG to create ffvhuff lossless intermediate.
I haven't really used VDub in a long time, unless I test with UTVideo Codec lossless intermediates.

ffmpeg -codec jpeg2000 -i "video.mxf" -map_metadata -1 -pix_fmt yuv444p12le -vcodec ffvhuff "output-ffvhuff-yuv444p12le.mkv"

ffmpeg supported (ffvhuff) pixel formats:

yuv420p yuv422p yuv444p yuv411p yuv410p yuv440p

gbrp gbrp9le gbrp10le gbrp12le gbrp14le gray gray16le

yuva420p yuva422p yuva444p

gbrap

ya8

yuv420p9le yuv420p10le yuv420p12le yuv420p14le yuv420p16le
yuv422p9le yuv422p10le yuv422p12le yuv422p14le yuv422p16le
yuv444p9le yuv444p10le yuv444p12le yuv444p14le yuv444p16le

yuva420p9le yuva420p10le yuva420p16le
yuva422p9le yuva422p10le yuva422p16le
yuva444p9le yuva444p10le yuva444p16le

rgb24 bgra

[Izuchi]

Yes, I was thinking of creating some lossless intermediary files, should have been more clearer. Thanks, Sparktank I'll give that a try.

[real.finder]

Originally Posted by LouieChuckyMerry

Thanks for your answer, cretindesalpes, I appreciate it. I've been slowly learning a bit here and a bit there and wanted to make sure I was putting the pieces together correctly. Another question, if I may. I updated Dither a few days ago, from v1.25.1 to v1.27.1 (I'm a bit slow) and in the process unwittingly added the avstp.dll to my plugins folder. I typically use the basic above script with SEt's MT AviSynth 2.6 like so:

SetMemoryMax(2048)
SetMTMode(3,7)
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("D:\Temp\[0000]ReEncTemp\TheUnbearableLightnessOfBeing[S]{1988}[720p]\OriginalVideo,OriginalAudio[ViGi].mkv")
SetMTMode(2)
SMDegrain(tr=3,thSAD=400,RefineMotion=True,Plane=0,Chroma=False,Lsb=True,Lsb_Out=True,PreFilter=2)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod()
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3(Lsb_In=True,Lsb=True)
# DitherPost
Dither_Out()

This has always given me good results (except for the occasional corrupt source), but with the avstp.dll in my plugins folder the output video had nasty artifacts every few seconds. Once I figured out that the avstp.dll was the cause of the glitches I found my way to your thread and, after reading the "Short user manuel" I don't understand why the avstp.dll would cause so much trouble. To my obviously wrong understanding it should help. Or is the problem that SMDegrain and FastLineDarkenMod aren't AVSTP enabled?

was the artifacts be like http://i.imgur.com/cvt0nW9.jpg ?

[StainlessS]

Just thought I'de point out that FFTW library used by eg FFT3DFilter as fftw3.dll and dftTest as libfftw3f-3.dll (same dll, just different name)
has been updated several times since the one included in dither tools. (not sure what date last update was). http://www.fftw.org/index.html


Here some update history, current version v3.3.4

FFTW 3.3.4

* New functions fftw_alignment_of (to check whether two arrays are
  equally aligned for the purposes of applying a plan) and fftw_sprint_plan
  (to output a description of plan to a string).

* Bugfix in fftw-wisdom-to-conf; thanks to Florian Oppermann for the
  bug report.

* Fixed manual to work with texinfo-5.

* Increased timing interval on x86_64 to reduce timing errors.

* Default to Win32 threads, not pthreads, if both are present.

* Various build-script fixes.

FFTW 3.3.3

* Fix deadlock bug in MPI transforms (thanks to Michael Pippig for the
  bug report and patch, and to Graham Dennis for the bug report).

* Use 128-bit ARM NEON instructions instead of 64-bits.  This change
  appears to speed up even ARM processors with a 64-bit NEON pipe.

* Speed improvements for single-precision AVX.

* Speed up planner on machines without "official" cycle counters, such as ARM.

FFTW 3.3.2

* Removed an archaic stack-alignment hack that was failing with
  gcc-4.7/i386.

* Added stack-alignment hack necessary for gcc on Windows/i386.  We
  will regret this in ten years (see previous change).
  
* Fix incompatibility with Intel icc which pretends to be gcc
  but does not support quad precision.

* make libfftw{threads,mpi} depend upon libfftw when using libtool;
  this is consistent with most other libraries and simplifies the life
  of various distributors of GNU/Linux.

FFTW 3.3.1

* Changes since 3.3.1-beta1:
  
  - Reduced planning time in estimate mode for sizes with large
    prime factors.

  - Added AVX autodetection under Visual Studio.  Thanks Carsten
    Steger for submitting the necessary code.

  - Modern Fortran interface now uses a separate fftw3l.f03 interface
    file for the long double interface, which is not supported by
    some Fortran compilers.  Provided new fftw3q.f03 interface file
    to access the quadruple-precision FFTW routines with recent
    versions of gcc/gfortran.

* Added support for the NEON extensions to the ARM ISA.  (Note to beta
  users: an ARM cycle counter is not yet implemented; please contact
  fftw@fftw.org if you know how to do it right.)

* MPI code now compiles even if mpicc is a C++ compiler; thanks to
  Kyle Spyksma for the bug report.

EDIT: Needs to be in system32 (or equiv on 64bit) as both fftw3.dll and ibfftw3f-3.dll (ibfftw3f-3.dll is name as supplied in zip).

[AzraelNewtype]

Originally Posted by StainlessS

EDIT: Needs to be in system32 (or equiv on 64bit) as both fftw3.dll and ibfftw3f-3.dll (ibfftw3f-3.dll is name as supplied in zip).

It's SysWOW64 on 64-bit OS... for the 32-bit dlls. If you're doing 64-bit avs, you put the 64-bit versions into system32 still. I'm only spelling it out because it's hilariously confusing.

Thanks Microsoft.

[StainlessS]

Thank you AzraelNewtype.

It's hilariously confusing.

Thanks Microsoft.

Another MS sweetie,

According to MS, Your System drive is the one you boot to, and your Boot drive is the one your system is on !

Always good for a giggle, is MS.

[creaothceann]

Does it have to be in System/SYSWOW64, or can it also be in a directory included in %PATH%?

[Groucho2004]

Originally Posted by creaothceann

Does it have to be in System/SYSWOW64, or can it also be in a directory included in %PATH%?

The latter also works.

[LouieChuckyMerry]

Originally Posted by real.finder

was the artifacts be like http://i.imgur.com/cvt0nW9.jpg ?

It's difficult to tell by your screenshot because I never encoded any anime with the AVSTP.dll issue, but it looks very similar. For my non-anime encodes, it looked like frost or ice (white artifacts) on the edges of images in the frame and was especially noticeable when there was action (camera pans, movement, etc.).

[real.finder]

Originally Posted by LouieChuckyMerry

It's difficult to tell by your screenshot because I never encoded any anime with the AVSTP.dll issue, but it looks very similar. For my non-anime encodes, it looked like frost or ice (white artifacts) on the edges of images in the frame and was especially noticeable when there was action (camera pans, movement, etc.).

the screenshot from pan too

and didn't happened in all video, it happened in ED in this frame only, and in avs 64 (with setmtmode) without AVSTP, and after I see it in the final encode I try to reproduce it but it didn't reproduced with many tries

[LouieChuckyMerry]

Originally Posted by real.finder

the screenshot from pan too and didn't happened in all video, it happened in ED in this frame only, and in avs 64 (with setmtmode) without AVSTP, and after I see it in the final encode I try to reproduce it but it didn't reproduced with many tries

If you can't reproduce it then perhaps it was just a one-time occurrence? I've experienced, very rarely, artifacts because the source file was corrupted, possibly a bad mux or a digital glitch.

[real.finder]

Originally Posted by LouieChuckyMerry

If you can't reproduce it then perhaps it was just a one-time occurrence? I've experienced, very rarely, artifacts because the source file was corrupted, possibly a bad mux or a digital glitch.

I tried with the same source and script

[bxyhxyh]

Hello, guys

If I use dither_resize16(1280,720,csp="YV24") on 1080p clip, this works ok.

I always resized chroma and luma separately before.
Are they same?

[Desbreko]

Yes, that'll be identical to resizing the chroma separately like this:

y = Dither_resize16(1280,720, u=1, v=1)
u = UToY8().Dither_resize16(1280,720, src_left=0.25)
v = VToY8().Dither_resize16(1280,720, src_left=0.25)
YToUV(u,v,y)

Resizing the chroma separately as Y8 clips is useful if you're using AviSynth's resizers or something else like nnedi3_rpow2 instead of Dither_resize16 on it, but otherwise, it's simpler and probably also faster to just use the csp option.

[fvisagie]

Originally Posted by Desbreko

Resizing the chroma separately as Y8 clips is useful if you're using AviSynth's resizers or something else like nnedi3_rpow2 instead of Dither_resize16 on it, but otherwise, it's simpler and probably also faster to just use the csp option.

Please explain in what situations one would want to do one of these (separately resize or use the csp option), and why?

Thanks,
François

[Desbreko]

It's for when you want to downscale the luma of a video with subsampled chroma without losing any more of the chroma resolution. Specifically, a lot of anime is produced at 720p or thereabout and upscaled to 1080p for release on Blu-ray, so converting the 1080p YV12 video on the BD to 720p YV24 when you encode it lets you avoid wasting bits on upscaled luma.

[fvisagie]

Thanks.