[pgroke]

As I already wrote in " Feature Suggestions", I'd be interested in a "deband" filter for XBMC (=the same thing that ffdshow provides under that name).
The original thread is here: http://forum.xbmc.org/showthread.php?tid=114706

In short: I'd really like to have a deband filter for XBMC, and I'd be willing to implement it, given that whoever currently "owns" the CWinRenderer code is OK with it. (I just want to avoid hacking away, and then have my patch rejected.)

CrystalP suggested that I post here to discuss the shader/algorithm etc. so here we go.

bobo1on1, if you happen to read this, maybe you could tell me what you think of my suggestions (see other thread).

Regarding the deband algorithm... I really haven't done much research or experimentation there - yet. My focus was on checking out the XBMC code to see if I can handle it (I think I can), and finding out if the XBMC team would be interested to include that feature.

I have however found an open source implementation which seems to deliver good results: flash3kyuu_deband
http://forum.doom9.org/showthread.php?t=161411
https://github.com/SAPikachu/flash3kyuu_...tree/1.4.2

I haven't had time to look at the source though.

[CrystalP]

Yes I'm interested and bobo1on1 as well. He could do the GL port. I am a part-owner of CWinRenderer.

The difficult part is going to be the implementation of an algorithm. It may be difficult to do as a shader. Maybe this will be the first use of OpenCL in XBMC?

Running on the CPU may be more straightforward but will likely be useless with hardware decoding due to the time spent in GPU-CPU-GPU, though there may be a way with some effort. That's what VLC does all the time after all.

The plumbing to integrate in XBMC is going to be rather simple and we can help with that. This forum exists for people to ask for development help, so feel free.

Good coding!

[jpsdr]

Nice idea, but i just want to give a warnig (or some information) :
I've talked a little with people using the flash3kyuu_deband (v1.4.2). Result is very good, and it seems to be actualy one of the best (if not the best) deband filter. But side effect is that in dark area, thin lines simply disapeared, this is why this knid of filter have parameters, and why people using it don't use the same parameters for a whole film/episode, but work scene by scene. I think the use of this filter should be done with some very very quick algorithm, wich will adjust parameter of the filter according global status of picture (dark or not). Advantage is that apparently this filter seems to have a good optimisation, multi-threaded and using SSE and like.
Also, i've not looked at the code, but i think filter is designed to work with YV12 and YUYV, but i'm not sure about others formats. Now, with xbmc, i don't know if it can be an issue or not.

This is what someone who use the filter answer to me :

The filter is very good on animation that suffer from banding (smooth digitally-painted gradients). Actually I prefer the results of this filter (rather than the 'dither' package by cretindesalpes). I'm actually using it with lower values than default as the dithering noise added is a bit strong to my taste.
Side effects are the same for these kind of filters. Edges on dark areas (or edges on areas with similar colors) have the risk to be wiped-out by the dithering process (so the edge or the line simply vanish). Lowering the values a bit helps to preserve details even more but there's still some loss of details in dark areas. If you dither at 16bit level, you can work with curves, raise the luma, dither and then lower the luma again to default levels. This preserve details even more but the deband effect is weaker (you still have some banding left).
I'm using it on a scene-by-scene level, changing values based on each scenes (based on how strong are the bands, how much detail you loose by filtering it and so on). It's a long manual process but the final result is probably the best you can get. On non-dark areas, the debanding process is near to perfect, with almost no details lost. You need to put care on dark areas.

But, i think it's a very good idea, i hope it will have a good result.

[pgroke]

@jpsdr
I think anything that requires per-scene tuning is misplaced in a video-player, and so in XBMC.

But I don't expect to get "perfect" results. I do however wish for some post-processing filters like deband to improve the visual quality of certain movies and TV series in my collection.
Some of them suffer from (quite bad) banding, some would need a procamp/video-equalizer.
If those post-processing filters can be configured per movie/per episode/per season/per series that would be good enough for me.
(When I'm watching on my normal PC, I have the deband filter in ffdshow enabled permanently. So far I never had the urge to turn it off.)

But side effect is that in dark area, thin lines simply disapeared, this is why this knid of filter have parameters, and why people using it don't use the same parameters for a whole film/episode, but work scene by scene. I think the use of this filter should be done with some very very quick algorithm, wich will adjust parameter of the filter according global status of picture (dark or not).

Maybe - or maybe not. The scenes where I notice banding the most are usually dark scenes. My TV has a S-LCD Panel (MVA or PVA, I always forget which it is), and they tend to WAY over-emphasize details in dark areas when you're not watching from the center. So banding in bright scenes is visible, especially with almost saturated colors (which have some color-components close to zero). But banding in dark scenes is way worse.
So I personally wouldn't want less blending/dithering in dark scenes.
Also I think making the filter adaptive per pixel would probably be easier & faster, since it doesn't require a second pass.

Advantage is that apparently this filter seems to have a good optimisation, multi-threaded and using SSE and like.
Also, i've not looked at the code, but i think filter is designed to work with YV12 and YUYV, but i'm not sure about others formats. Now, with xbmc, i don't know if it can be an issue or not.

Well, I'm aiming for a GPU solution. Mainly because I would like to see this work with DXVA/VDPAU in the long run. I don't have any experience with GPU-computing - I just "feel" that this is a job for the GPU. Maybe moving the whole frame from video-ram to main-ram, processing there, and then moving it back to video-ram would work just fine with most of todays hardware. But it just feels wasteful, and I'm almost certain that we can get away with lower hardware requirements if we let the GPU handle it.

Anyway, thanks for your input!

[bobo1on1]

Start by figuring out what exactly the filter does, then you can decide how to best implement it.
Shaders are fine when doing the same operation for each pixel, like scaling or color space conversion, but if you're doing any complex branching (if() statements) in the shader then it's going to be horribly slow.

[pgroke]

Sooo...
I have started experimenting with Media Player Classic's "shader" feature.
This is my current prototype (which is FAR from perfect, but well...):

Code:

sampler s0 : register(s0);
float4 p0 : register(c0);

#define IMAGE_WIDTH        (p0[0])
#define IMAGE_HEIGHT    (p0[1])

#define RADIUS            16
#define THRESHOLD        (3.0 / 256.0)

#define SAMPLE_COUNT    8        // 1 ... 8
//#define SKIP_THRESHOLD_TEST        // just for testing

/*
    OFFSET_MODE
        1 = cross (axis aligned, fast)
        2 = diagonal (45°, slower)
        3 = box (fully random, much slower)
*/
#define OFFSET_MODE        1

#define OUTPUT_BOOST    1.0
#define OUTPUT_OFFSET    0.0

float rand(float2 pos)
{
     return frac(sin(dot(pos.xy, float2(12.9898, 78.233))) * 43758.5453);
}

bool is_within_threshold(float3 original, float3 other)
{
    return !any(max(abs(original - other) - float3(THRESHOLD, THRESHOLD, THRESHOLD), float3(0, 0, 0)));
}

float4 main(float2 pos0 : TEXCOORD0) : COLOR
{
    float2 step = float2(1.0 / IMAGE_WIDTH, 1.0 / IMAGE_HEIGHT) * RADIUS;
    float2 halfstep = step * 0.5;

    // compute additional sample positions

    float2 seed = pos0 + p0[3]; // no idea what p0[3] is exactly, but it changes every frame, which is what we need...
#if OFFSET_MODE == 1
    float2 offset = float2(rand(seed), 0.0);
#elif OFFSET_MODE == 2
    float2 offset = float2(rand(seed), 0.0);
    offset.y = offset.x;
#elif OFFSET_MODE == 3
    float2 offset = float2(rand(seed), rand(seed + float2(0.1, 0.2)));
#endif

    float2 on[8] = {
        float2( offset.x,  offset.y) * step,
        float2( offset.y, -offset.x) * step,
        float2(-offset.x, -offset.y) * step,
        float2(-offset.y,  offset.x) * step,
        float2( offset.x,  offset.y) * halfstep,
        float2( offset.y, -offset.x) * halfstep,
        float2(-offset.x, -offset.y) * halfstep,
        float2(-offset.y,  offset.x) * halfstep,
        };

    float3 col0 = tex2D(s0, pos0).rgb;
    float4 accu = float4(col0, 1.0);

    for (int i = 0; i < SAMPLE_COUNT; i++)
    {
        float4 cn = float4(tex2D(s0, pos0 + on[i]).rgb, 1.0);
#ifndef SKIP_THRESHOLD_TEST
        if (is_within_threshold(col0, cn.rgb))
#endif
            accu += cn;
    }

    accu.rgb = accu.rgb / accu.a;

    // boost to make it easier to inspect the effect's output
    accu.rgb -= float3(OUTPUT_OFFSET, OUTPUT_OFFSET, OUTPUT_OFFSET);
    accu.rgb *= OUTPUT_BOOST;
    accu.rgb = clamp(accu.rgb, float3(0, 0, 0), float3(1, 1, 1));

    return float4(accu.rgb, 1.0);
}

[bobo1on1]

You can probably stick that code into XBMC's convolution shaders, or make a new filter shader, it looks quite simple.
So basically you just sample a group of pixels, and if the difference between them is lower than a certain threshold, it's considered banded?

[wedok]

so now its 2018.
is there any kind of debanding possible with kodi?