Skip to content

calib3d: findChessboardCornersSB() minor updates#12668

Merged
alalek merged 1 commit intoopencv:masterfrom
alalek:calib3d_chessboardsb_updates
Sep 30, 2018
Merged

calib3d: findChessboardCornersSB() minor updates#12668
alalek merged 1 commit intoopencv:masterfrom
alalek:calib3d_chessboardsb_updates

Conversation

@alalek
Copy link
Copy Markdown
Member

@alalek alalek commented Sep 27, 2018

  • avoid updating of input image during equalizeHist() call
  • avoid for() with double variable (use 'int' instead)
  • more CV_Check*() macros
  • use Mat_, Matx
  • static for local variables
docker_image:Custom=javascript
buildworker:Linux x64 Debug=linux-2

- avoid updating of input image during equalizeHist() call
- avoid for() with double variable (use 'int' instead)
- more CV_Check*() macros
- use Mat_<T>, Matx
- static for local variables
@alalek
Copy link
Copy Markdown
Member Author

alalek commented Sep 27, 2018

/cc @D-Alex

BTW, I'm observing strange results if CALIB_CB_NORMALIZE_IMAGE is "forced" in findChessboardCornersSB() (with and without other changes from this PR): alalek@calib3d_chessboardsb_updates_test

  • chessboard.cpp:3190: flags |= CALIB_CB_NORMALIZE_IMAGE;
  • enable #if 0 debug code in tests (see patch)
  • Run: ./bin/opencv_test_calib3d --gtest_filter=*Calib3d_ChessboardDetector2.accuracy*

@D-Alex
Copy link
Copy Markdown
Contributor

D-Alex commented Sep 27, 2018

I can reproduce the behaviour. The reason is that the input image has a patten which is basically like a forest for the detector after normalization detecting valid points everywhere.

Response Map
feature_map_2

This should not be a problem as long as the pattern is big enough. However, because the board size is close to the initial size of 3x3 the checks are currently to weak to filter them out.
image_11

The correct fix would be to enforce more consistency checks for the initial boards or to change the heuristic how initial boards are generated from a single seed point.

I will have a look if I can improve the heuristic. Are there any time constraints for getting the fix done?

@alalek
Copy link
Copy Markdown
Member Author

alalek commented Sep 28, 2018

OpenCV 4.0 gold release is planned in the end of October.

This is non-default mode, looks like equalizeHist() introduces some artifacts. May be other pre-processing like adaptiveThreshold() should work better on these synthetic images.

Do you have some objectives about this patch?

for(double angle=0;angle <= CV_PI;angle+=CV_PI*0.1)
for (int angle_i = 0; angle_i < 10; angle_i++)
{
double angle = angle_i * (CV_PI * 0.1);
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@D-Alex Is this loop still correct? (<= condition has been replaced to < to get exact 10 "tests")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks ok. PI was already tested during the first iteration and should not be tested twice like in the previous implementation.

@alalek
Copy link
Copy Markdown
Member Author

alalek commented Sep 30, 2018

👍

@alalek alalek merged commit ae4c72a into opencv:master Sep 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants