flash3kyuu_deband 1.5.1 / 2.0pre2 with native VapourSynth support [2012-12-03]

[kolak]

Makes sense, but I have recompressed it again to uncompressed mov but the file is exactly the same (unless -vcodec v210 doesn't mean 'recompress to v210')

Maybe ffmpeg does "smart rendering" so it actually does the same as copy option. :)

[SAPikachu]

@mp3dom @kolak @poisondeathray

I just checked the qt format spec and found the reason. mp3dom was right and I was wrong, the offset should be 0x24 = 36. This mdat chunk has 64bit length - that is, the 4 bytes before "mdat" is "00 00 00 01", and a 8-byte length follows the tag, real data then follows the length. So file_head should be 8 bytes after mdat.

[SAPikachu]

Makes sense, but I have recompressed it again to uncompressed mov but the file is exactly the same (unless -vcodec v210 doesn't mean 'recompress to v210')

v210 is an uncompressed format, so recompress the file won't change the data.

[jmac698]

@Sap...
That's great, I wrote the original script. Can I package it up with your credit? I wanted to know the quick way to find the file head, but I didn't want to read the huge manual.. now I know and I think I can fix this in script to be fully automatic, which is great!
I think we're really making progress on some quite usable high bit depth processing, even ffmeg is going to have ProRes soon...

ps what would be really useful is a type of parsing file reader that you could say fileread(int a, float b, str c ) etc. something like that, but choose word length to read only bytes, and nops to skip bytes. We need to read data files. Maybe a version of sashimi that reads to script variables instead of clips?

[kolak]

@mp3dom @kolak @poisondeathray

I just checked the qt format spec and found the reason. mp3dom was right and I was wrong, the offset should be 0x24 = 36. This mdat chunk has 64bit length - that is, the 4 bytes before "mdat" is "00 00 00 01", and a 8-byte length follows the tag, real data then follows the length. So file_head should be 8 bytes after mdat.

OK- so we need swapuv after script, otherwise colors are wrong. I will check with different files, but it looks like this is a rule (so script can be adjusted inside function).

btw...I compared (just quickly for now) quality and it looks very good and promising. Conversion was slow thought 1.5fps for full HD, but using only one core. Not sure how I can make it using many cores, but in theory it can run at acceptable speed. Looking good :)

Andrew

[SAPikachu]

@Sap...
That's great, I wrote the original script. Can I package it up with your credit? I wanted to know the quick way to find the file head, but I didn't want to read the huge manual.. now I know and I think I can fix this in script to be fully automatic, which is great!
I think we're really making progress on some quite usable high bit depth processing, even ffmeg is going to have ProRes soon...

ps what would be really useful is a type of parsing file reader that you could say fileread(int a, float b, str c ) etc. something like that, but choose word length to read only bytes, and nops to skip bytes. We need to read data files. Maybe a version of sashimi that reads to script variables instead of clips?

Of course you can. Just do anything to it as you like. :)

I don't understand the second part. Do you want to directly parse the file header in script? I think that will be very hard and hackish since AviSynth lacks some useful features (like loops). A better method is integrate a more powerful scripting environment into it. Actually I am thinking of creating a python plugin environment, but I don't have much time to do it recently...

[kolak]

Another thing- is this Floyd dithering just pure implementation?

Filter which I compared it to use noise shaping/error diffusion plus optional random noise.
When noise is added, an R250 random number generator is used. The noise is injected into the quantizer, not into the signal, so the error propagated to the adjacent pixels does not include the random noise.

Can we do the same- is it good idea?


Andrew

[SAPikachu]

OK- so we need swapuv after script, otherwise colors are wrong. I will check with different files, but it looks like this is a rule (so script can be adjusted inside function).

btw...I compared (just quickly for now) quality and it looks very good and promising. Conversion was slow thought 1.5fps for full HD, but using only one core. Not sure how I can make it using many cores, but in theory it can run at acceptable speed. Looking good :)

Andrew

We just need to adjust the file_head based on the mdat chunk mode. SwapUV is unneeded and wrong.

It is hard to get speed improvement using pure script implementation. Better to integrate it into a source plugin, like Sashimi.

[kolak]

We just need to adjust the file_head based on the mdat chunk mode. SwapUV is unneeded and wrong.

It is hard to get speed improvement using pure script implementation. Better to integrate it into a source plugin, like Sashimi.

But when I use new (as you said- correct offset) colors are wrong :(
Tried 2 totally different files- without swpuv colors are wrong.


Andrew

[SAPikachu]

Another thing- is this Floyd dithering just pure implementation?

Filter which I compared it to use noise shaping/error diffusion plus optional random noise.
When noise is added, an R250 random number generator is used. The noise is injected into the quantizer, not into the signal, so the error propagated to the adjacent pixels does not include the random noise.

Can we do the same- is it good idea?


Andrew

f3kdb_dither is pure dithering. I think noise is unneeded unless the clip needs debanding. In next version you can use f3kdb on the 16bit clip.

[mp3dom]

OK- so we need swapuv after script, otherwise colors are wrong.

No, wrong colors was with wrong offset (0x1c) and in that case the SwapUV fixed it. With right offset (0x24) the colors are ok from the start.


When noise is added, an R250 random number generator is used. The noise is injected into the quantizer, not into the signal, so the error propagated to the adjacent pixels does not include the random noise.

Xscaler :D

f3kdb_dither is pure dithering. I think noise is unneeded unless the clip needs debanding. In next version you can use f3kdb on the 16bit clip.
Is it possible (in a future release, without hurry) to implement it as an optional parameter? About f3kdb, isn't it already working on 16bit clip as source? Or are you referring to the deband part (flash3kyuu)? In that case it would be very helpful to deband a 16bit clip and then dither to 8bit.

[SAPikachu]

But when I sue new (as you said- correct offset) colors are wrong :(



Andrew

There is 2 types of mdat chunk. If the 4 bytes before mdat is 00 00 00 01, you need to add 8 to the offset after mdat. Otherwise the original offset is correct.

[kolak]

There is 2 types of mdat chunk. If the 4 bytes before mdat is 00 00 00 01, you need to add 8 to the offset after mdat. Otherwise the original offset is correct.

OK- understand now- thanks. Didn't get your original message: Will check and confirm.
Yes- my files don't have 00 00 00 01, so "normal" offset works fine.

[SAPikachu]

Is it possible (in a future release, without hurry) to implement it as an optional parameter? About f3kdb, isn't it already working on 16bit clip as source? Or are you referring to the deband part (flash3kyuu)? In that case it would be very helpful to deband a 16bit clip and then dither to 8bit.

Yes I meant flash3kyuu_deband. I will make the new version when I have time.

[jmac698]

Yes the script can be sped up alot, that is the reason I requested some new features in sashimi. Those features were finalized just yesterday, so now it is time to rewrite readv210 with the new features, which should speed up load the files a lot.

My understanding of dither is that it can be fixed or random. I read a whole textbook on it once (long time ago), and it seems that uncorrelated noise with shaping looked best. That old floyd-steinberg is easy to understand but causes it's own banding (there's only 5 shades for 4 dots).

Btw, I worked on my own algorithm for fixed dither, that always sums to the target value for the area, meaning you could perfectly reverse it back into a high bit-depth image at full resolution! It can't always work for some pixels though.

As for the file parser, I could use this idea for other things, speed is not an issue, like reading the histograms from colorlike per frame, it's only 256 numbers of text, or reading the in-pattern results in dgindex, just one line per frame.. and in this case, reading 8 bytes to determine file header - such a siimple task, that I don't want to write a whole plugin just for those numbers... because ultimiately I find coding up an idea in script far, far faster to get a practical result (even though it may be slow). And yes you can do loops in avisythn, however I don't need them to parse files, the plugin will have some simple logic for that.

[Gavino]

AviSynth lacks some useful features (like loops).
See GScript in my sig.
For the purist, you can also use recursive functions to create loops in vanilla Avisynth.

[jmac698]

recursion and gscript are documented here
http://avisynth.org/mediawiki/Advanced_Scripting_Tips

[kolak]

My understanding of dither is that it can be fixed or random. I read a whole textbook on it once (long time ago), and it seems that uncorrelated noise with shaping looked best. That old floyd-steinberg is easy to understand but causes it's own banding (there's only 5 shades for 4 dots).



I think thit is the reason why MS filter adds noise- to cover FS own banding.

To be honest- going from 10 to 8bit with MS filter looks good enough- I would rather like to have more speed.

What about these methods:

Jarvis, Judice, and Ninke dithering diffuses the error also to pixels one step further away. The dithering is coarser, but has fewer visual artifacts. It is slower than Floyd–Steinberg dithering because it distributes errors among 12 nearby pixels instead of 4 nearby pixels for Floyd–Steinberg.

Stucki dithering is based on the above, but is slightly faster. Its output tends to be clean and sharp.

Burkes dithering is a simplified form of Stucki dithering that is faster, but less clean than Stucki dithering.

As a goal I would see 2x faster than RT dithering for full HD on eg. 12 core PC, with quality as FS.


Andrew

[kolak]

Current solution can give about 12fps on 8 core machine (older Xeons- not i7)- just need to run many instances. MS filter is a bit faster.


Andrew

[Fullmetal Encoder]

Yes I meant flash3kyuu_deband. I will make the new version when I have time.

Thank you very much for this. I eagerly await the full higher bit depth capability. Thanks also for providing us with such a high quality dithering tool. It's very impressive compared to what else is available.

[SAPikachu]

@Gavino @jmac698
So I must revise my wording - AviSynth doesn't have some convenient language features. At least it is very hard to parse raw data directly in script. Of course there are hackish ways to do that. :)

@jmac698 @kolak
Adding random noise can indeed reduce banding. Actually flash3kyuu_deband does that between core debanding and dithering.

[kolak]

Can you add optional (with possibility to set strength) add noise to fkdb_dither?


Andrew

[SAPikachu]

Can you add optional (with possibility to set strength) add noise to fkdb_dither?


Andrew

Actually that's what flash3kyuu_deband does. After adding high bit-depth input, it will be superset of f3kdb_dither.

[kolak]

OK- you're adding high bit-depth input for flash3kyuu_deband and than f3kdb_dither is not needed- cool :)

[kolak]

Not sure if it's a good place, but:

is there anyone interested to write frameserver for one of the editing software (preferably in v20 and YUY2- I believe theses are native formats for software for 10 and 8bit mode). Not for free.

Something like debugmode for Premiere/Vegas.

You can contact me via PM.

Thanks,
Andrew

[mp3dom]

The problem is that a lot of NLE internally works in RGB colorspace or have RGB filters. A YUY2/v210 output makes sense if no colorspace occurs during all the editing stage. Anyway Vegas and Premiere already can use DebugMode, Avid (and I suppose FinalCut) uses QuickTime Reference (which is similar to DebugMode).

[kolak]

Different software, which is way more stable and faster than all of them and it does work internally in YUV (maybe that's why it's so fast).


Andrew

[kolak]

Actually that's what flash3kyuu_deband does. After adding high bit-depth input, it will be superset of f3kdb_dither.

Done some test an additional noise does help- file from Xscaler is "smoother" than from f3kdb_dither and the difference is due to additional noise added by Xscaler filter.

flash3kyuu_deband with high bit-depth support will be very powerful :)

[SAPikachu]

Finally escaped from another project and get some free time. :)

New version should be available in 1 or 2 weeks.

[kolak]

Cool :)

Andrew

[mp3dom]

Awesome! I've the right project to test on :)

[SAPikachu]

A little update. My work has suddenly became very busy recently, I only completed about 50% of the improvement in the last 2 weeks... Need maybe several weeks more to fully implement the changes.

I also planned to add some more features to the new version:

* 9 - 15 bit output
* dynamic noise

[kolak]

Dynamic noise sounds interesting :)

Can't wait to see it in action.

[mp3dom]

What should do "dynamic noise"? You mean put noise only on zones where debanding take place (without adding noise to, example, a flat area of the same image)? Sounds cool! Can't wait to see how much is the gain (or detail preservation) in debanding an 8bit source vs debanding directly a 10bit source.

[SAPikachu]

What should do "dynamic noise"? You mean put noise only on zones where debanding take place (without adding noise to, example, a flat area of the same image)? Sounds cool! Can't wait to see how much is the gain (or detail preservation) in debanding an 8bit source vs debanding directly a 10bit source.

"dynamic noise" means different noise pattern on different frames, somewhat like diff_seed but much faster. (Actually diff_seed will be replaced with that). I am finalizing the last new functionality (9 ~ 15 bit output), new version should be available in a few days. (Hope the estimation is accurate this time :P )

[mp3dom]

Fantastic! Thanks a lot!!

[Keiyakusha]

What is the possible benefit it different noise pattern over frames? For compression, all I can see is that it makes harder to compress video, and harder to preserve deband. For real-time, it will behave more like noise and pattern is not something visible by your eye anyway...

[SAPikachu]

What is the possible benefit it different noise pattern over frames? For compression, all I can see is that it makes harder to compress video, and harder to preserve deband. For real-time, it will behave more like noise and pattern is not something visible by your eye anyway...

I heard from somewhere that dynamic noise is good for some videos, but I don't remember the exact theory. Anyway, it is only a switch and not very hard to implement. Just try it yourself. :)

[Nevilne]

It will make encoders allocate more bits to low detail areas - such as gradients.
Though if done right the dithering noise should not matter too much.

[Keiyakusha]

I heard from somewhere that dynamic noise is good for some videos, but I don't remember the exact theory. Anyway, it is only a switch and not very hard to implement. Just try it yourself. :)

Its OK I was just wondering what is the real use for it. Anyway I'm really looking for 10bit output :)

It will make encoders allocate more bits to low detail areas - such as gradients.
While probably true, this only hurt compression overall. Because these bits will be wasted. Allocating more bits while pattern is static is good, but when it is dynamic more bits needed to achieve the same perceived quality level. So you'll end up taking bits from high detail areas for nothing. On the opposite way, what we want for encoding is calming down fluctuations to reduce difference between similar frames and then allocating more bits by tweaking encoder itself.

[SAPikachu]

Released 1.4.0.

[mp3dom]

Great!! Thanks!!
Just to be sure to do the right thing... I'm importing a v210 mov via your ReadV210 so I'm having a stacked clip.
Is this the right cmd to do the debanding at 10/16bit and then dithering to 8bit regular clip?

ReadV210(...)
f3kdb(precision_mode=4,input_mode=1,input_depth=16)
f3kdb_dither(mode=1,stacked=true,input_depth=16)

It seems the right way. In any case, the result is amazing!! Thanks!

[SAPikachu]

Great!! Thanks!!
Just to be sure to do the right thing... I'm importing a v210 mov via your ReadV210 so I'm having a stacked clip.
Is this the right cmd to do the debanding at 10/16bit and then dithering to 8bit regular clip?

ReadV210(...)
f3kdb(precision_mode=4,input_mode=1,input_depth=16)
f3kdb_dither(mode=1,stacked=true,input_depth=16)

It seems the right way. In any case, the result is amazing!! Thanks!

Don't need to add f3kdb_dither after f3kdb, it's OK to just use precision_mode = 3, the result will be the same since the algorithm is identical. :)

[mp3dom]

Wow, so we can do it now in only 'one pass'. So f3kdb_dither now is only meant if someone wants to dither down a clip without debanding, right?
Thanks again very much! The results look impressive!

[SAPikachu]

Wow, so we can do it now in only 'one pass'. So f3kdb_dither now is only meant if someone wants to dither down a clip without debanding, right?
Thanks again very much! The results look impressive!

Yes, actually f3kdb_dither is only a shortcut now, same result can be achieved with f3kdb by setting Y/Cb/Cr/ditherY/ditherC to 0.

[kolak]

Once I have bit of time going to test it- thanks for your work SAPikachu:thanks:

[kolak]

When I tried ver 1.4 with avisynth 2.6 I got out of memory error in your dll reported by Vdub.
Same conditions, just with older version- no problem.

[DarkT]

GradFun3 results, in comparison pix from page 1 look better to me. Is the new version better? What are the adventages over GF3?

[cretindesalpes]

f3kdb is faster than GradFun3, at least with settings giving similar results.

[mp3dom]

I get some exception too when a stacked clip (1920x2160) is feeded as YUY2 (not YV16).
Regarding the differences, I found that f3kdb correctly debands zones that GradFun3 doesn't detect, but GradFun3 seems to preserve very dark areas (and edges with similar colors to contiguous zones) better.

To enhance the edges detection, since now we can work on 16bit, isn't it possible to work with curves (increase contrast, get a mask to get where to dither, return to original curve and dither, skipping edges) or to create an edge mask on the source and then copy it (only the edges detected) to the debanded clip?