apriltag3 vs apriltag2 -- detect quad

[ruichaowang]

Describe the bug
Apriltag 3 has a lower detect rate than Apriltag 2.
Tag family: tagCodes36h11

To Reproduce
Steps to reproduce the behavior:
parameters for apriltag3:

    td->nthreads = 8;
    td->quad_decimate = 1;
    td->quad_sigma = 0.0;

    td->qtp.max_nmaxima = 10;
    td->qtp.min_cluster_pixels = 1;

    td->qtp.max_line_fit_mse = 200.0;
    // td->qtp.critical_rad = 1 * M_PI / 180;
    td->qtp.cos_critical_rad = cos(10 * M_PI / 180);
    td->qtp.deglitch = 0;
    td->qtp.min_white_black_diff = 1;

    td->tag_families = zarray_create(sizeof(apriltag_family_t*));

    pthread_mutex_init(&td->mutex, NULL);

    td->tp = timeprofile_create();

    td->refine_edges = 1;
    td->decode_sharpening = 0.25;

    td->debug = 1;

Expected behavior
Apriltag 3 can detect more tags than Apriltag 2.

** Input Image**
raw imgae:

using apriltag2:

using apriltag3:

Screenshots
apriltag2 debug,

apriltag3 debug,

as you can see the apriltag2 can detect more quads.

Operating Sytem
m1 mac

Additional context
Add any other context about the problem here.

[ruichaowang]

re-upload raw images.

[christian-rauch]

The behaviour between the implementations changed. This repo hosts all the versions. If you need an older implementation, you will have to check out that specific commit.

@mkrogius @wxmerkt Since this also came up in #262, I think it makes sense to create branches apriltag1 and apriltag2 for the previous versions 1 and 2. Do you agree? Which commits would match the latest state of the version 1 and 2 implementations?

[ruichaowang]

The behaviour between the implementations changed. This repo hosts all the versions. If you need an older implementation, you will have to check out that specific commit.

It would be great to have branch apriltag2 for the previous versions 2.
But from my point of view, the apriltag3 should have a better detection rate than apriltag2, but which is not ture in this case.

[mkrogius]

@ruichaowang Neither AprilTag 3 nor AprilTag 2 supports tags with the extra calibration squares on the corners like that. I also don't recognize the style of the image you have uploaded as apriltag2_debug, which makes me wonder whether this is actually an AprilTag 2 implementation? If I had to guess, this would actually be an AprilTag 1 implementation, which didn't officially support tags with calibration squares, but which did have better detection rate in this scenario than AprilTag 3.

@christian-rauch I think that makes sense. Unfortunately none of the earlier AprilTag releases are commits in this repo. It may take some digging in order to find the original releases for AprilTag 1 and AprilTag 2

[XavierQL]

@christian-rauch here i am confused by the highly distorted image how to detect the apriltag accurately and efficiently？from my side, the first step is to rectify the image and then to detect the apriltage code. But like the fisheye image as the issue shown, the undistorted image has cropped lots of FOV(using opencv), so how to detect the tags at the edge of the image?

[christian-rauch]

@XavierQL What is confusing? You should rectify the image in any case to have the line detection working properly. Is this related to the AprilTag 2 vs. 3 discussion above?

[s-trinh]

Unfortunately none of the earlier AprilTag releases are commits in this repo. It may take some digging in order to find the original releases for AprilTag 1 and AprilTag 2

There is:

• https://april.eecs.umich.edu/media/apriltag/

apriltag-0.9.tgz	2015-06-26 20:36
apriltag-0.91.tgz	2015-06-26 20:36
apriltag-0.92.tgz	2015-06-26 20:36
apriltag-2014-10-20.tgz	2015-06-26 20:36
apriltag-2015-03-14.tgz	2015-06-26 20:36
apriltag-2015-03-18.tgz	2015-06-26 20:36
apriltag-2016-10-11.tgz	2016-10-11 23:09
apriltag-2016-10-21.tgz	2016-10-21 20:41
apriltag-2016-12-01.tgz	2016-12-02 01:52
apriltag-2018-11-29.tgz	2018-12-16 17:29

I don't know if it is the source code for AprilTag1 but at least there are some previous versions.

---

There is also kaess/apriltags code:

AprilTags library

Detect April tags (2D bar codes) in images; reports unique ID of each
detection, and optionally its position and orientation relative to a
calibrated camera.

See examples/apriltags_demo.cpp for a simple example that detects
April tags (see tags/pdf/tag36h11.pdf) in laptop or webcam images and
marks any tags in the live image.

Ubuntu dependencies:
sudo apt-get install subversion cmake libopencv-dev libeigen3-dev libv4l-dev

Mac dependencies:
sudo port install pkgconfig opencv eigen3

Uses the pods build system in connection with cmake, see:
http://sourceforge.net/p/pods/

Michael Kaess
October 2012

----------------------------

AprilTags were developed by Professor Edwin Olson of the University of
Michigan.  His Java implementation is available on this web site:
  http://april.eecs.umich.edu.

Olson's Java code was ported to C++ and integrated into the Tekkotsu
framework by Jeffrey Boyland and David Touretzky.

See this Tekkotsu wiki article for additional links and references:
  http://wiki.tekkotsu.org/index.php/AprilTags

----------------------------

This C++ code was further modified by
Michael Kaess (kaess@mit.edu) and Hordur Johannson (hordurj@mit.edu)
and the code has been released under the LGPL 2.1 license.

- converted to standalone library
- added stable homography recovery using OpenCV
- robust tag code table that does not require a terminating 0
  (omission results in false positives by illegal codes being accepted)
- changed example tags to agree with Ed Olson's Java version and added
  all his other tag families
- added principal point as parameter as in original code - essential
  for homography
- added some debugging code (visualization using OpenCV to show
  intermediate detection steps)
- added fast approximation of arctan2 from Ed's original Java code
- using interpolation instead of homography in Quad: requires less
  homography computations and provides a small improvement in correct
  detections

todo:
- significant speedup could be achieved by performing image operations
  using OpenCV (Gaussian filter, but also operations in
  TagDetector.cc)
- replacing arctan2 by precomputed lookup table
- converting matrix operations to Eigen (mostly for simplifying code,
  maybe some speedup)

[s-trinh]

For anyone looking, on GitHub there seems to be several repositories for the Java AprilTag1 version:

• https://github.com/ennerf/mvn-repo-sources/blob/master/april-tags/src/main/java/april/tag/TagDetector.java

  Added april-tags minimal 0.91
  corresponds to basic java configuration in
  http://april.eecs.umich.edu/wiki/index.php/Download_and_Installation
  

• https://github.com/soartech/soar/tree/master/Domains/RoomsWorld/april/java/src/april/tag

---

And a modified Java version of AprilTag1 here:

• https://github.com/icyphy/ptII/blob/master/edu/umich/eecs/april/image/AprilTagFilter.java

  <p>The April tags accessor code uses code written by Edwin Olson (ebolson@umich.edu), see
    <a href="https://april.eecs.umich.edu/#in_browser" target="_top">https://april.eecs.umich.edu/</a></p>

  <p>These files are part of a modified subset of the
    april package created by Professor Edward A. Lee (eal@eecs.berkeley.edu) that
    removes all dependencies on external libraries and graphical classes
    and renames the packages to follow Java naming conventions.</p>

  <h2>License</h2>
  <p>Most of April is GPL'd, but we asked for and received a BSD license on the Java april/tag code.</p>
  <p>On 8/20/15 2:38 AM, Edwin Olson wrote:</p>
  <blockquote>
    <p>I am okay with dual-licensing the Java code in april/tag and its necessary dependencies under BSD  clause license. (And since I'm putting this in writing-- this does not extend to other software in the april repository.) The specific license is included below for reference, which includes an additional attribution clause versus the one you sent.</p>

    <p>That said, the java version is so ludicrously outperformed by the C version that I'd really like to convince you to (somehow) use the C version instead. It's not a C-versus-Java thing; the detector logic itself is using completely new algorithms.  It is also *much* cleaner in terms of dependencies.</p>

    <p>Is there some way to make the C version easier to use from Java? I'm no fan of JNI either. Any ideas?</p>
    
    <p>Best,</p>
    
    <p> -Ed</p>