More > JRiver Media Center 31 for Windows

Black bar detection not updating tag correctly

<< < (9/12) > >>

mattkhan:
ok makes sense

looking at my stats, going up to skip=24 looks like a positive move though not perfect

out of ~600 films, I'm left with ~140 that don't match (once some tolerance is allowed)

of those, there are ~70 films which produce a different result with skip=24 vs skip=8 and which is different to MC (by more than 0.01 in AR terms)

of those 70, I think most (~60) look more correct with skip=24 though there are <10 which have questionable results (would need to look at them manually to know what is going on I think)

there are also ~14 where changing black levels makes a major difference, there are definitely a few cases where this is correct but it's wrong more often than not and when it's wrong, it's way way wrong (like producing an AR of 4.1). I would think this could be completely automated (run it with both, see if it produces a different but still "normal" AR, if so it's likely to be correct).

what parameters are you using for the next build?

Hendrik:
Parameters are likely not changing much, but rather adding filtering and heuristics on top of the results, rather then taking every single result rectangle into account.

This should definitely fix issues where skip is too low, because the frames at the beginning only make up a tiny percentage that would just be ignored, even if it slips by the skip parameter.
Not sure about level being too high. I would think if level is too high, it would only show up in some very dark scenes and overall fix itself if some other scene is brighter, but alas. I'll have to dig into some samples of that being a problem.

mattkhan:
my examples of black level making a difference attached (in case you have any of those films), 18 & 25 refer to the black level (18/255 and 25/255 for actual limit values)

Hendrik:
The next build will have a simple heuristic and a report with a scoring system (1-5).

Example report:

--- Code: ---Score: 5
Result: 0x278x3840x1882 (2.39)

0x278x3840x1882 (2.39), 89% (1109 frames sampled), first seen at 00:14:14
0x278x3512x1882 (2.19), 1% (16 frames sampled), first seen at 00:42:48
2x278x2910x1882 (1.81), 1% (10 frames sampled), first seen at 00:42:48
138x278x3678x1882 (2.21), 1% (10 frames sampled), first seen at 00:57:00

Hits <1% have been skipped due to a high accuracy score.

--- End code ---

It takes into account the percentages of the various detection, as well as the aspect ratio to make a determination. Lets see how the result of that is going to be. 5 and 4 should be relatively safe detections, unless something fundamentally is going wrong, any lower might warrant some investigation. At least thats the idea. Lets see if thats how it works on larger samples!

I thought about also looking at the values in the rects, but didn't do it yet. For example, pillar boxing is relatively rare, so if thats detected it might be weird, or equal bars on both sides are better matches then uneven ones. I'll add those if needed, but it seemed to just make everything overly complicated when most videos might just fall within these heuristics already.

For easier smartlist to detect things, I could add an expression function to get the score directly, if that seems helpful.

Hendrik:
Testing my library, so far the only low scores i'm getting are from badly defined borders in broadcast. So you have stuff like the dump below. I might add some more logic to try to unify rects that are very close together like this again, without just blindly unifying all rects like the old code did.
Going to be a bit until my entire library ran again. I should probably only do movies, TV shows rarely come with black bars. But anyway its going now!


--- Code: ---Score: 3
Result: 4x4x1920x1080 (1.78)

4x4x1920x1080 (1.78), 60% (889 samples), first at 00:00:45
2x4x1918x1080 (1.78), 16% (236 samples), first at 00:03:44
2x0x1918x1080 (1.77), 13% (184 samples), first at 00:11:12
0x4x1920x1080 (1.78), 11% (163 samples), first at 00:18:40

Hits <1% have been skipped due to a high accuracy score.

--- End code ---

I was using round=4 to minimize those, but clearly they are still showing up. Although it does make me wonder why there is 2px differences between them... (edit: its applying the rounding to the width, not the crop itself. Makes sense. So you can have 0 -> 1920 and 2 -> 1918, but not 2 -> 1920).

Navigation

[0] Message Index

[#] Next page

[*] Previous page