What's the meaning of 'apriltag.c:448: homography_compute2: Assertion `max_val_idx >= 0' failed.'? about apriltag HOT 5 CLOSED

This check was added in #317 to avoid indexing with a negative index. I hope that the proposed fix in #213, which was ported into #317 via 359a984, fixes the issue, but apparently, it does not.

Do you have a reproducible script and data for this?

from apriltag.

this is my code:

#include "apriltag.h"
#include "tagStandard41h12.h"

#include <iostream>
#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
#include <opencv2/opencv.hpp>

int main() {

  std::string img_path = "path_to_img";
  cv::Mat img = cv::imread(img_path, CV_8UC1);

  apriltag_family_t *tf;
  apriltag_detector_t *td;

  tf = tagStandard41h12_create();
  td = apriltag_detector_create();
  apriltag_detector_add_family(td, tf);

  image_u8_t im = {img.cols, img.rows, img.cols, img.data};
  zarray_t *detections = apriltag_detector_detect(td, &im);

  apriltag_detector_destroy(td);
  tagStandard41h12_destroy(tf);
  return 0;
}

this is the picture:

and the commit is e6cd3c7

from apriltag.

Thanks. I can reproduce this with the apriltag_demo:

apriltag_demo -f tagStandard41h12 319063435-0f7a44f8-58e7-452c-99bc-142160e24a93.jpg

from apriltag.

With the debug information

I can see that there are two odd perfect axis-aligned rectangular quads and with the debugger I can see that those coordinates are horizontally and vertically aligned (identical x and y coordinates).

While it is very unlikely that we will get detections that are perfectly axis-aligned like this on a sub-pixel level, I don't see why homography_compute2 should be able to compute a homography from this.

from apriltag.

At e6cd3c7 I am able to repro with:

rm -r build
cmake -B build
cmake --build build
uild/apriltag_demo -f tagStandard41h12 ~/Downloads/319063435-0f7a44f8-58e7-452c-99bc-142160e24a93.jpg

(I wasn't able to repro with -DCMAKE_BUILD_TYPE=Release since it removes asserts)

Printing out the correspondences matrix that is input to homography_compute2 in this case gives:

-1.0000 -1.0000 191.9706 454.0736 
1.0000 -1.0000 191.9706 454.0736 
1.0000 1.0000 191.9706 472.9767 
-1.0000 1.0000 191.9706 472.9767 

Which is a degenerate case for which a valid homography does not exist. We should return null rather than asserting from homography_compute2.

But how did we end up with a degenerate case not getting filtered out earlier? This is the quad in question:

The reason is that we only end up with a degenerate quad after the refine_edges step and there are not checks on the result of the refine edges step that the quad is valid. This is fine IMO since the fastest way to know if a quad is valid at this point is just to do the decode step, which is what happens next

from apriltag.