Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support histograms/hashes with AdaptiveDetector #402

Open
Breakthrough opened this issue Jun 16, 2024 · 0 comments
Open

Support histograms/hashes with AdaptiveDetector #402

Breakthrough opened this issue Jun 16, 2024 · 0 comments

Comments

@Breakthrough
Copy link
Owner

Breakthrough commented Jun 16, 2024

AdaptiveDetector works by calculating a running average of the output score of fast cut detectors. In theory, the scores both new detectors produce (histograms and perceptual hashing) can be normalized and used as inputs for AdaptiveDetector.

We could change the configuration options for AdaptiveDetector to allow specifying which detector to use for frame scores, rather than duplicating the config options shared between it and ContentDetector, which is the only supported "input".

Ideally, the methods used - rolling average vs. flash suppression - could be defined globally, or as a separate command. This work is tracked in In the meantime, allowing AdaptiveDetector to specify where the underlying frame scores come from might be workable. This would also avoid a lot of duplication of options.

Another option: we could integrate AdaptiveDetector into the new flash suppression filter by adding a new suppression method which accepts the required parameters. This would be more extensible and future proof, and allow easier switching/comparison between methods. With this approach, adaptive detector would be removed entirely, and instead each detector would specify the "mode" to suppress flashes.

This is ideal since the adaptive ratio might differ between detectors since frame scores aren't normalized across all detectors yet, especially those that show nonlinear responses to change. It would allow us to provide better defaults and define them in the detectors themselves, rather than being tightly coupled as it is right now (AdaptiveDetector requires a lot of knowledge about ContentDetector).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant