Color banding and noise removal

[Sapo84]

Originally Posted by Boulder

Also MAnalyse requires 8-bit input anyway and there's the contrasharpening part after the denoising by MDegrain which makes my head spin. I've seen the 16-bit mod of contrasharpening but to me it looks like it's trying to be much too fancy compared to Didée's original, brilliant idea.

MAnalyse requires 8-bit but MDegrain can output in 16-bit with lsb=true, so it shouldn't be a problem at all, unless you're really against the 16-bit mod of contrasharpening.

[feisty2]

In that case you should probably switch to vaporsynth, vaporsynth mvtools takes 16bits or even 32bits (floating point) precision and, no concerns about MT stuff no more

[Boulder]

Yeah, that's one option. I've tried to do the switch at least once but haven't had the time to properly familiarize myself with the syntax. Loading stuff is easy but there's always more than that

[feisty2]

I don't find vaporsynth script (Python) and avisynth script much different...
Both are simple scripting languages, not monster like C++...

[Boulder]

Once you get used to Python (and coding in general, after 20 years..) In fact, I've had to do some very small coding on Python at work to create some helper jobs so maybe I'll get around to it in the near future.

I have a feeling that the slowdown issue with Dither's gamma-aware resizing is cache related. I just need to find out which portion of the script causes the severe slowdown because directly compared, there is no problem with it.

[Groucho2004]

Originally Posted by Boulder

I've also tried comparing the gamma-aware resizing of Dither and ResampleHQ (I almost always downsize to 720p) and found out that the method by Dither doesn't scale well with SetMTMode. The performance sometimes fluctuates quite a lot and I haven't found a good reason for that.

Do you have avstp.dll in your plugin directory? The multi-threading of avstp and SET's AVS MT don't go well together. If you have the file, remove it from the auto-load directory.

[Boulder]

I do have it but it's set to single-thread mode with avstp_set_threads(1) in my script, that should cover it.

[Groucho2004]

Originally Posted by Boulder

I do have it but it's set to single-thread mode with avstp_set_threads(1) in my script, that should cover it.

I'd still try without it, I tested it with "avstp_set_threads(1)" and it's presence still influenced the results.

[LouieChuckyMerry]

Originally Posted by Groucho2004

I see. In that case, as already suggested, denoise in 8 bit, convert to 16, deband, reduce to 10 bit, feed to x264 10 bit.

Happy Friday! Do you reckon there's a noticeable difference between the above and simply feeding the 16-bit output to 10-bit x264?

[feisty2]

Originally Posted by LouieChuckyMerry

Happy Friday! Do you reckon there's a noticeable difference between the above and simply feeding the 16-bit output to 10-bit x264?

"reckon", aussie?
no, I guess, x264 got "Sierra-2-4A error diffusion", something similar to typical FS (ditherpost mode 6)

[Groucho2004]

Originally Posted by feisty2

"reckon", aussie?

Info on the origin of the word can be found here.
I was rather sure that this word is commonly used in AE as well. Maybe it just fell through the cracks when spelling dictionaries for phones were created.

[fvisagie]

Originally Posted by Groucho2004

commonly used in AE

I reckon quite a few Safricans also use it. So not a reliable indicator of origin.

[feisty2]

Originally Posted by Groucho2004

I was rather sure that this word is commonly used in AE as well.

not now... unless someone like 50 yrs old "country bumpkin" (no offense)

[LouieChuckyMerry]

Originally Posted by feisty2

"reckon", aussie?
no, I guess, x264 got "Sierra-2-4A error diffusion", something similar to typical FS (ditherpost mode 6)

I'm using "Dither_Out()" to feed 10-bit x264; would there still be no apparent difference? Apologies for my obtuseness.

Originally Posted by Groucho2004

Info on the origin of the word can be found here.
I was rather sure that this word is commonly used in AE as well. Maybe it just fell through the cracks when spelling dictionaries for phones were created.

Thanks, good to learn more ways to spread The Tao Of Reckon .

Originally Posted by fvisagie

I reckon quite a few Safricans also use it. So not a reliable indicator of origin.

I picked it up watching weekend westerns as an impressionable youth. Nice to know I'd feel at home in South Africa .

[feisty2]

I'm using "Dither_Out()" to feed 10-bit x264; would there still be no apparent difference? Apologies for my obtuseness.

you can either dither down to 10bits and x264 will take it and skip the bit depth conversion, or pipe that 16bits stuff directly to x264 and x264 will "Sierra-2-4A" it to 10bits
so, no apparent difference

[LouieChuckyMerry]

Thanks for the clarification, feisty2 .

[Desbreko]

Does vanilla 10-bit x264 skip the bit depth conversion now if you feed it 10-bit? Last I heard, it would convert to 16-bit first and then dither down to 10-bit.

[feisty2]

the internal bit depth will always be, 16bits, like, that's an elementary data type to computers
you got char, which is an 8bits integer, and can be used to do, stuff, to 8bits vids
and short, which is a 16bits integer, and in between, it's just, nothing, 10bits integer? never heard of it
8<bit depth<=16 just gotta be padded to 16bits first and truncated (or dithered) to the desired bit depth when all the internal processes are done

[sneaker_ger]

Originally Posted by Desbreko

Does vanilla 10-bit x264 skip the bit depth conversion now if you feed it 10-bit? Last I heard, it would convert to 16-bit first and then dither down to 10-bit.

I think that has remained unchanged but does not matter anyways. At least that's how I always understood it.

Originally Posted by Dark Shikari

x264 uses a variant on Sierra-2-4A error diffusion, a faster alternative to Floyd-Steinberg error diffusion. x264's implementation is explicitly designed such that if the input is upscaled within x264 to a higher bit depth, then downscaled using error diffusion, the result will be losslessly identical to the input.

[LouieChuckyMerry]

Originally Posted by feisty2

the internal bit depth will always be, 16bits, like, that's an elementary data type to computers
you got char, which is an 8bits integer, and can be used to do, stuff, to 8bits vids
and short, which is a 16bits integer, and in between, it's just, nothing, 10bits integer? never heard of it
8<bit depth<=16 just gotta be padded to 16bits first and truncated (or dithered) to the desired bit depth when all the internal processes are done

Interesting information to this ignorant and curious individual. Any idea why 10-bit x264 isn't instead 16-bit x264?