Decomb Custom Explanation

General questions or discussion about HandBrake, Video and/or audio transcoding, trends etc.
Post Reply
randomreuben
Veteran User
Posts: 468
Joined: Mon Nov 02, 2009 2:18 pm

Decomb Custom Explanation

Post by randomreuben »

Dear jbrjake,

What do the different numbers in this decomb customization option mean? 389:2:3:3:2:40 If you wish, a link to a place that explains this would be much appreciated, if the explanation is too lengthy.

I understand that the first large number is a combination of decomb filters. I don't know what the other numbers signify.

Thanks!

randomreuben
Deleted User 11865

Re: Decomb Custom Explanation

Post by Deleted User 11865 »

This is somewhat out of date but the first settings (except mode which has changed) are explained: http://trac.handbrake.fr/wiki/Decomb

This is up to date for trunk (nightlies) but less detailed except in modes listing: http://trac.handbrake.fr/browser/trunk/libhb/decomb.c
randomreuben wrote:389:2:3:3:2:40
There is no documentation for such a string except at the top of hb-trunk/libhb/decomb.c in a decomb3-patched build.
Last edited by Deleted User 11865 on Wed Jun 16, 2010 8:13 pm, edited 1 time in total.
mduell
Veteran User
Posts: 8187
Joined: Sat Apr 21, 2007 8:54 pm

Re: Decomb Custom Explanation

Post by mduell »

randomreuben
Veteran User
Posts: 468
Joined: Mon Nov 02, 2009 2:18 pm

Re: Decomb Custom Explanation

Post by randomreuben »

Hi Rodeo and mduell,

Thank you for the pointers. I feel silly. I've come across that document a hundred times before, but I never really read that part. I am terribly sorry to have wasted your time. Thank you for the pointers again.

Take care,

randomreuben
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: Decomb Custom Explanation

Post by jbrjake »

Note, you want to go off the copy in the SVN, *not* the Wiki. That was never updated for 0.9.4.

When the new decomb gets checked in, the directions will be like so:

Code: Select all

Parameters:
    Mode : Spatial metric : Motion thresh : Spatial thresh : Mask Filter Mode :
    Block thresh : Block width : Block height

Appended for EEDI2:
    Magnitude thresh : Variance thresh : Laplacian thresh : Dilation thresh :
    Erosion thresh : Noise thresh : Max search distance : Post-processing

Plus:
    Parity
    
Defaults:
    7:2:6:9:1:80:16:16:10:20:20:4:2:50:24:1:-1
*****/

#define MODE_YADIF       1 // Use yadif
#define MODE_BLEND       2 // Use blending interpolation
#define MODE_CUBIC       4 // Use cubic interpolation
#define MODE_EEDI2       8 // Use EEDI2 interpolation
#define MODE_MCDEINT    16 // Post-process with mcdeint
#define MODE_MASK       32 // Output combing masks instead of pictures
#define MODE_GAMMA      128 // Scale gamma when decombing
#define MODE_FILTER     256 // Filter combing mask
#define MODE_COMPOSITE  512 // Overlay combing mask onto picture

/***** 
These modes can be layered. For example, Yadif (1) + EEDI2 (8) = 9,
which will feed EEDI2 interpolations to yadif.

** Working combos:
 1: Just yadif
 2: Just blend
 3: Switch between yadif and blend
 4: Just cubic interpolate
 5: Cubic->yadif
 6: Switch between cubic and blend
 7: Switch between cubic->yadif and blend
 8: Just EEDI2 interpolate
 9: EEDI2->yadif
10: Switch between EEDI2 and blend
11: Switch between EEDI2->yadif and blend
17: Yadif->mcdeint
18: Blend->mcdeint
19: Switch between blending and yadif -> mcdeint
20: Cubic->mdeint
21: Cubic->yadif->mcdeint
22: Cubic or blend -> mcdeint
23: Cubic->yadif or blend -> mcdeint
24: EEDI2->mcdeint
25: EEDI2->yadif->mcdeint
...okay I'm getting bored now listing all these different modes
32: Passes through the combing mask for every combed frame (white for combed pixels, otherwise black)
33+: Overlay the combing mask for every combed frame on top of the filtered output (white for combed pixels)

12-15: EEDI2 will override cubic interpolation
16: DOES NOT WORK BY ITSELF-- mcdeint needs to be fed by another deinterlacer
*****/
The modes get added together. Getting the most benefit from the new decomb patch entails:
256 (for the new erosion/dilation filtering of the combing mask) + 128 (for scaling to gamma-adjusted luma values) + whatever other options you want.

So 391, what I'm suggesting for testing the new patch, is 256 (fiter) + 128 (gamma) + 4 (cubic interpolation) + 2 (blending slightly combed frames) + 1 (yadif). That means it'll scale gamma values before looking for combed pixels, then filter its map of combed pixels to remove noise, then send any frames it thinks are a little bit interlaced to be blended, and send any frames it thinks are very interlaced to yadif, which will use a cubic interpolation to decide how to scale up one of the fields in the frame.
Deleted User 11865

Re: Decomb Custom Explanation

Post by Deleted User 11865 »

jbrjake wrote:Note, you want to go off the copy in the SVN, *not* the Wiki. That was never updated for 0.9.4.
I always point to both since while the Wiki is outdated, aside from the modes which have changed completely, the 6 other settings have a more detailed explanation there than in the source.
jbrjake wrote:When the new decomb gets checked in, the directions will be like so:

Code: Select all

Parameters:
    Mode : Spatial metric : Motion thresh : Spatial thresh : Mask Filter Mode :
    Block thresh : Block width : Block height

Appended for EEDI2:
    Magnitude thresh : Variance thresh : Laplacian thresh : Dilation thresh :
    Erosion thresh : Noise thresh : Max search distance : Post-processing

Plus:
    Parity
    
Defaults:
    7:2:6:9:1:80:16:16:10:20:20:4:2:50:24:1:-1
*****/

#define MODE_YADIF       1 // Use yadif
#define MODE_BLEND       2 // Use blending interpolation
#define MODE_CUBIC       4 // Use cubic interpolation
#define MODE_EEDI2       8 // Use EEDI2 interpolation
#define MODE_MCDEINT    16 // Post-process with mcdeint
#define MODE_MASK       32 // Output combing masks instead of pictures
#define MODE_GAMMA      128 // Scale gamma when decombing
#define MODE_FILTER     256 // Filter combing mask
#define MODE_COMPOSITE  512 // Overlay combing mask onto picture

/***** 
These modes can be layered. For example, Yadif (1) + EEDI2 (8) = 9,
which will feed EEDI2 interpolations to yadif.

** Working combos:
 1: Just yadif
 2: Just blend
 3: Switch between yadif and blend
 4: Just cubic interpolate
 5: Cubic->yadif
 6: Switch between cubic and blend
 7: Switch between cubic->yadif and blend
 8: Just EEDI2 interpolate
 9: EEDI2->yadif
10: Switch between EEDI2 and blend
11: Switch between EEDI2->yadif and blend
17: Yadif->mcdeint
18: Blend->mcdeint
19: Switch between blending and yadif -> mcdeint
20: Cubic->mdeint
21: Cubic->yadif->mcdeint
22: Cubic or blend -> mcdeint
23: Cubic->yadif or blend -> mcdeint
24: EEDI2->mcdeint
25: EEDI2->yadif->mcdeint
...okay I'm getting bored now listing all these different modes
32: Passes through the combing mask for every combed frame (white for combed pixels, otherwise black)
33+: Overlay the combing mask for every combed frame on top of the filtered output (white for combed pixels)

12-15: EEDI2 will override cubic interpolation
16: DOES NOT WORK BY ITSELF-- mcdeint needs to be fed by another deinterlacer
*****/
I was hoping that as this is decomb 3, after enough testing has been done, all these new features might be combined in a new "spatial metric" with value 3 for simplicity. Or is this considered further down the road?
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: Decomb Custom Explanation

Post by jbrjake »

Rodeo wrote:I was hoping that as this is decomb 3, after enough testing has been done, all these new features might be combined in a new "spatial metric" with value 3 for simplicity. Or is this considered further down the road?
Well that's not what a spatial metric is. Decomb's spatial metric is the method it uses to measure whether or not a pixel in a frame is combed compared to adjacent pixels in the frame. That hasn't changed, I'm still using tritical's bob+blur method. These changes concern the data fed to the metric (whether it's raw or gamma-scaled) and how the resulting combing map is examined afterwards. However, I was lazy when I added the gamma-scaled input and never implemented the other spatial metrics (which I never use) to accept that kind of input. So right now, using the gamma scaled mode in parameter 1 makes the spatial metric parameter get ignored. So I see where you're coming from, seeing it as a separate method--especially since it's in a separate function. However, the right solution is to just add the other spatial metrics to the new detect_gamma_combed_segment() function.

Really the way I see decomb moving for simplicity is string-based input. The most user-unfriendly thing about it, imo, isn't the complexity of the modes offered so much as the cryptic, numeric codes for mode and the frustration of having to include all parameters before the parameter you want to modify from its default. Like, having to explicitly state all the default values just to change the parity is ridiculous. And you know well that even I get confused on which mode number is which. So what I'd like is something along the lines of:

--decomb="mode=yadif,blend,cubic,eedi2,gamma,filter:motionthresh=3:filter=2:parity=1"

So you could set them in any order, skip any you want to leave at defaults, and use plain english names.
Deleted User 11865

Re: Decomb Custom Explanation

Post by Deleted User 11865 »

jbrjake wrote:
Rodeo wrote:I was hoping that as this is decomb 3, after enough testing has been done, all these new features might be combined in a new "spatial metric" with value 3 for simplicity. Or is this considered further down the road?
Well that's not what a spatial metric is. Decomb's spatial metric is the method it uses to measure whether or not a pixel in a frame is combed compared to adjacent pixels in the frame. That hasn't changed, I'm still using tritical's bob+blur method. These changes concern the data fed to the metric (whether it's raw or gamma-scaled) and how the resulting combing map is examined afterwards. However, I was lazy when I added the gamma-scaled input and never implemented the other spatial metrics (which I never use) to accept that kind of input. So right now, using the gamma scaled mode in parameter 1 makes the spatial metric parameter get ignored. So I see where you're coming from, seeing it as a separate method--especially since it's in a separate function. However, the right solution is to just add the other spatial metrics to the new detect_gamma_combed_segment() function.
Makes sense.
jbrjake wrote:Really the way I see decomb moving for simplicity is string-based input. The most user-unfriendly thing about it, imo, isn't the complexity of the modes offered so much as the cryptic, numeric codes for mode and the frustration of having to include all parameters before the parameter you want to modify from its default. Like, having to explicitly state all the default values just to change the parity is ridiculous.
I agree. Perhaps what bothers me most of all, in fact.
jbrjake wrote: And you know well that even I get confused on which mode number is which. So what I'd like is something along the lines of:

--decomb="mode=yadif,blend,cubic,eedi2,gamma,filter:motionthresh=3:filter=2:parity=1"

So you could set them in any order, skip any you want to leave at defaults, and use plain english names.
Now that would be just awesome :D :D :D
Deleted User 11865

Re: Decomb Custom Explanation

Post by Deleted User 11865 »

Rodeo wrote:
jbrjake wrote: And you know well that even I get confused on which mode number is which. So what I'd like is something along the lines of:

--decomb="mode=yadif,blend,cubic,eedi2,gamma,filter:motionthresh=3:filter=2:parity=1"

So you could set them in any order, skip any you want to leave at defaults, and use plain english names.
Now that would be just awesome :D :D :D
Have you started working on this at all? If not, I might try and implement it myself as this is such a good idea.

My idea would be to mimic x264_param_parse() to parse the full string and x264_param_apply_tune() for the mode since it takes multiple values separated by commas. Does that seem like a good idea?
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: Decomb Custom Explanation

Post by jbrjake »

I'll do it myself. It's not worth pursuing at this moment because it will break my bobbing patch for sure. It's going to be hard enough to merge in to decomb 3. You don't have to look to x264 for examples for all this stuff; HB's CLI already parses comma separated arguments for all audio-related options.
Deleted User 11865

Re: Decomb Custom Explanation

Post by Deleted User 11865 »

jbrjake wrote:I'll do it myself. It's not worth pursuing at this moment because it will break my bobbing patch for sure. It's going to be hard enough to merge in to decomb 3. You don't have to look to x264 for examples for all this stuff; HB's CLI already parses comma separated arguments for all audio-related options.
OK. Turns out after I was done playing with the pixels in the advanced panel (see my post in that topic) I couldn't just stop there and started working on it anyway (that was before you replied).

I'll post my initial patch the the decomb thread in case you still want to look at it.
Post Reply