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

Add image for issue #26642 unit test #1228

Open
wants to merge 2 commits into
base: 4.x
Choose a base branch
from

Conversation

JSpencerPittman
Copy link

@JSpencerPittman JSpencerPittman commented Jan 13, 2025

The added image will be used in the following PR to solve issue #26642: opencv/opencv#26760.

In the PR I mention why I'm submitting this for a closed issue.

@asmorkalov
Copy link
Contributor

1.11mb is too much for regular tests. Is the issue still relevant, if image is resized 4 times, 2 times or something like this?

@JSpencerPittman
Copy link
Author

@asmorkalov glad this problem came up, I tried resizing the image, and suddenly the number of detected points dropped dramatically.

  • At 100% QRDetect::searchHorizontalLines yields $32,000+$ points.
  • At 97% I get 10,124 and it still causes the program to fail.
  • At 96% I get 10,019 and it immediately can tell there's no QR code.
    I'll investigate what's causing searchHorizontalLines() to detect so many points in the provided images in issue #26642 at near 100% resolution, yet barely any if I drop it to less than 90% of its original resolution.

@asmorkalov
Copy link
Contributor

@JSpencerPittman What if just generate a lot of small horizontal lines in the test code then?

@JSpencerPittman
Copy link
Author

JSpencerPittman commented Jan 14, 2025

@asmorkalov

Found the issue. The image has a lot of introduced static since the background from the images don't easily fit into one of the two bins when applying an adaptive threshold used by the QRDetect. Consequently, searchHorizontalLines() will see a lot of potential points in the static. The resize operation, often smooths an image hence the dramatic drop in potential points due to less noise. In support of this is that the number stays high if I use nearest neighbor for interpolation with cv2.resize to prevent smoothing.

With a new perspective on the problem I'm considering a less invasive PR that simply applies a smoothing filter either in advance or conditionally to remove this static.

Horizontal lines alternative for test data.

Oh that's convenient, I'll generate the lines from the image and try to use them directly then. I'll also try some resizing without smoothing and maybe cropping to get within the size limit to see if that would work.

@JSpencerPittman
Copy link
Author

I cropped the region of the image that causes the long hang times while under 1MB.

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

Successfully merging this pull request may close these issues.

2 participants