-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
PixelateAnnotator throws errors if the area is too small, BlurAnnotator is not censoring if area is too large #703
Comments
Hi, @Clemens-E 👋🏻 ! Thanks a lot for your interest in supervision. Good catch. I think we can handle this problem as follows:
|
Sounds like a good plan, however this doesn't allow the user to decide what specific size they want to use depending on the detection area. Another option would be to allow passing the kernel/pixel size in the annotate function. |
Like you said, I don't think most people need this level of control. In general, we try to make the API as simple as possible and don't overcomplicate it unless necessary. Are you interested in implementing this fix? |
I will try doing that, you might have to review multiple times though, my python skills aren't fully enterprise ready 😄
I would fall back to the dynamic version, but I can try doing an average color |
No worries. I'm happy to help with my reviews.
Problem is that |
Search before asking
Bug
When using PixelateAnnotator with no additional configuration, it throws an error if the area to pixelate is too small:
I added this debug to this section
The last output before the error is:
Box: (644, 444, 678, 453)
ROI shape: (9, 34, 3)
I left the pixel size at the default (10), so I'm guessing the 9 is too small for it
As seen in the below code, I made this adjustment to automatically pick the largest possible pixel size and half it by 2, this works very well.
This approach would also resolve an issue with the BlurAnnotator.
If the kernel size set to the default, and the area is large, the resulting area is still very identifiable.
Maybe we can resolve this by having the option to provide a lambda instead of a fixed number, so the user can dynamically decide how large the used kernel/pixel size should be.
If that's something worth implementing in the project, I would be happy to create a PR.
Environment
hardware not relevant
Minimal Reproducible Example
No response
Additional
No response
Are you willing to submit a PR?
The text was updated successfully, but these errors were encountered: