Source 8 bitdepth... output 10 bits??

[Overdrive80]

I have the doubt if it is really interesting process a video with a bitdepth 8-bit, transform it to 10-bit using tools like dither, and export to encode.

I understand that if a video has a lower color depth and I transform it, not obtain quality, however I want to know if really would avoid artifacts like banding and increase its compressibility, at least; althought after I encoding on 8 bits.

Am I losting the time with this script?

###################################
# FILTRADO #
###################################

Setmtmode(2)

original=last

aa=spline64Resize(width(original)*2,height(original)*2).SangNom(aa=29).spline64Resize(width(original),height(original)).mergechroma(original)

prefiltrado= dfttest(sigma=4,tbsize=1,tmode=0,lsb=true).ditherpost(mode=2)


super=Msuper(prefiltrado)

backward_vec3 = MAnalyse(super, isb = true, delta = 3, overlap=4,search=4)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4,search=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4,search=4)

forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4,search=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4,search=4)
forward_vec3 = MAnalyse(super, isb = false, delta = 3, overlap=4,search=4)

prefiltrado.MDegrain3(super,backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,
\thSAD=370,plane=4,lsb=true).ditherpost(mode=2)

contrasharpening(last,aa)

toon(0.10)

gradfun3()

[hello_hello]

The problem I'm having experimenting with dithering is actually finding a clip where I get the resizing or noise removal to cause banding. If I didn't want it to happen.....

I did try a little experiment with an encode which already contained banding by opening it with an AVISynth script and then comparing it to the original with and without resizing. Even without resizing dithering made a difference. It didn't get rid of the banding but it did reduce it's "sharpness" a little. When resizing down using spline36 it seemed to sharpen the banding a little while once again dithering reduced it, although only by a very small amount.

Currently I'm experimenting with dithering while resizing a fairly clean 1080p source down to 720p. It definitely effects the way the video is compressed. My experiment was to take a 30 second section of the original video and resize it down to 480p using different combinations of resizing and dithering. I started by first using lossless compression (huffyuv), and while each combination produced exactly the same result according to my eyes, according to the file sizes it doesn't. The dithering (I assume) adds more "information" even if I can't actually see it.

Anyway, if you're interested, here's the sort of result I was getting. The difference in file sizes for the lossy, compressed encodes are only tiny as I'm only compressing a 30 second video at 720x300, so the lossy file sizes are in bytes. The first result is the lossless file size while the second is the lossy one.

Spline36 (116.8MB, 1,416,344)
Spline36 + Gradfun3 (117.8MB, 1,416,265)
DitherTools resizing (123.5MB, 1,410,792)

So as the lossless file size increases, the lossy file size decreases. When using lossless compression I couldn't pick the difference between splice36 and dithertools resizing. Same jagged edges and halos. Each of the above looked identical to me so any differences after x264 encoding on my eyes was the effect of lossy compression.

Using the default x264 settings and CRF20, when stopping each on identical frames to compare them, they looked the same quality, just different. So I opened up the original video to compare them for encoding accuracy. I've really only compared static scenes so far but the encoding was most accurate when using dithertools resizing, then when using Spline36 followed by gradfun3, then spline36 on it's own. There really wasn't a lot in it, it came down to things like the how the shape of a shadow under someone's chin might be encoded... that sort of thing.

Lowering the CRF value to 16 and using the slower x264 preset I'd still say the accuracy of encoding was in the same order, but of course by then the differences were pretty minuscule. Up at CRF25 I'd say the same still applied only for some reason I think I preferred the encode using spline36 and gradfun3, only by then the encoding wasn't exactly accurate either way.

So based on the above little test and what I saw, I'd say gradfun3 probably can't hurt and might improve compression/quality by a small amount, but I'm still to encode a video which lets me experiment with it's effect on banding. I don't know whether generally it'd reduce it or whether there might be some circumstances under which it might make it worse. If you find out, please post back.

[sneaker_ger]

I have the doubt if it is really interesting process a video with a bitdepth 8-bit, transform it to 10-bit using tools like dither, and export to encode.

I understand that if a video has a lower color depth and I transform it, not obtain quality, however I want to know if really would avoid artifacts like banding and increase its compressibility, at least; althought after I encoding on 8 bits.

Am I losting the time with this script?

Your script does not do any conversion to 10 bit.

[Overdrive80]

Your script does not do any conversion to 10 bit.

I thought that dithertools transform source to use lsb option. My mistake. ¬¬'

[sneaker_ger]

Unless I'm mistaken, gradfun3() simply outputs 8 bit. Outputting higher bit-depths is a bit more complicated and hackish, as AviSynth does not support anything higher than 8 bit natively. If you feed your script to 10 bit x264 it will automatically upconvert it to 10 bit and you can benefit from the increased compression of 10 bit H.264. It's still better to directly output to 16 or 10 bit, though, to maximize any debanding effects.

[Overdrive80]

Ahh, ok you referering to use something like this (http://forum.doom9.org/showthread.php?t=162656), doesn´t???