search

alicevision / CCTag

Detection of CCTag markers made up of concentric circles.
https://cctag.readthedocs.io
Mozilla Public License 2.0
350 stars 87 forks source link

[bug] ctest failure on compilation and low accuracy #219

Open mpr-projects opened 1 month ago

mpr-projects commented 1 month ago

Hello,

I've cloned and compiled the latest version of CCTag available on github (commit 3cb3b00) with

My main system is Arch Linux with gcc 14.2.1 but I've also compiled/tested CCTag with gcc 13.1.1 for compatibility with nvcc. I've compiled it with and without CUDA support and in either case there are no errors during configuration or compilation but when I run ctest then the first test fails. Here's the output:

Test project /home/me/Documents/build/CCTag/build
    Start 1: cctag_fitEllipse.test_ellipseFitting
1/2 Test #1: cctag_fitEllipse.test_ellipseFitting ...***Failed    0.03 sec
    Start 2: geometry_ellipse.test_ellipse
2/2 Test #2: geometry_ellipse.test_ellipse ..........   Passed    0.03 sec

50% tests passed, 1 tests failed out of 2

Total Test time (real) =   0.06 sec

The following tests FAILED:
     1 - cctag_fitEllipse.test_ellipseFitting (Failed)
Errors while running CTest
Output from these tests are in: /home/me/Documents/build/CCTag/build/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.

When I run the test sample then only one or two markers are recognized (it varies by run) - also it takes very little time to run...

~/D/b/C/b/Linux-x86_64> ./detection --input ../../CCTag/sample/02.png -n 3
You called ./detection with:
    --input     ../../CCTag/sample/02.png
    --nbrings     3
    --bank      
    --params    
    --output    

******************* Image mode **********************
Total time:  0.170000s wall, 0.180000s user + 0.020000s system = 0.200000s CPU (117.6%)

#frame 0
Detected 1 candidates
1476 827.272 17 1

1 markers detected and identified

The same happens with my own images. I also used a fresh Arch Linux install in a virtual box and I got the same result (so I don't think that some peculiarity of my specific system is causing it). When I ran the same process on Ubuntu 20.04 LTS in a virtual box it worked fine. Both ctests passed and all tags were recognized (it took much longer but that's probably in part because it ran in a VB with limited resources):

You called ./detection with:
    --input     ../../CCTag/sample/02.png
    --nbrings     3
    --bank      
    --params    
    --output    

******************* Image mode **********************
Total time:  7.118771s wall, 8.590000s user + 0.080000s system = 8.670000s CPU (121.8%)

#frame 0
Detected 6 candidates
1449.76 666.733 67 1
408.464 782.559 11 1
1703.4 513.985 16 1
1476.09 827.202 17 1
785.149 875.716 22 1
947.186 769.549 25 1

6 markers detected and identified

Then I installed Ubuntu 24.04 LTS in a virtual box and I got similar results as on my Arch Linux installations (the first ctest failed and one, two or at most three markers were recognized in the samples). Since this happens on both Arch Linux and Ubuntu I don't think that my use of Arch Linux is the problem.

I've also tested CCTag version 1.0.3 on my Arch Linux and on Ubuntu 24.04 LTS with the same results.

Another issue that may be related to this one is that my AliceVision installation compiles and runs without problems if I compile without CCTags (well, almost without problems, there is a seg fault just when I exit Meshroom...) but when I compile with CCTags then AliceVision seg faults (in cameraInit) as soon as I import one or more images.

Have you come across this issue? Have you been able to run CCTag on an up-to-date Linux installation? Do you think it's an issue with CCTag or am I doing something wrong? Maybe the new versions of some dependencies (boost, opencv, ...) cause an issue - I haven't tested that yet.

Thanks for your help!

simogasp commented 1 month ago

can you post what's in /home/me/Documents/build/CCTag/build/Testing/Temporary/LastTest.log

mpr-projects commented 1 month ago

Thanks for your fast reply! Here's the output of the test on my main Arch Linux System:

Start testing: Aug 12 09:30 CEST
----------------------------------------------------------
1/2 Testing: cctag_fitEllipse.test_ellipseFitting
1/2 Test: cctag_fitEllipse.test_ellipseFitting
Command: "/home/me/Documents/build/CCTag/build/Linux-x86_64/cctag_fitEllipse" "--run_test=test_ellipseFitting" "--catch_system_error=yes"
Directory: /home/me/Documents/build/CCTag/build/src/cctag/test
"cctag_fitEllipse.test_ellipseFitting" start time: Aug 12 09:30 CEST
Output:
----------------------------------------------------------
Running 10 test cases...
unknown location(0): fatal error: in "test_ellipseFitting/test_pixel_int": std::domain_error: to_ellipse_2: singularity 1
/home/me/Documents/build/CCTag/CCTag/src/cctag/test/fitEllipse.cpp(73): last checkpoint
unknown location(0): fatal error: in "test_ellipseFitting/test_pixel_int2": std::domain_error: to_ellipse_2: singularity 1
/home/me/Documents/build/CCTag/CCTag/src/cctag/test/fitEllipse.cpp(93): last checkpoint
unknown location(0): fatal error: in "test_ellipseFitting/test_float1": std::domain_error: to_ellipse_2: singularity 1
/home/me/Documents/build/CCTag/CCTag/src/cctag/test/fitEllipse.cpp(111): last checkpoint
unknown location(0): fatal error: in "test_ellipseFitting/test_float2": std::domain_error: to_ellipse_2: singularity 1
/home/me/Documents/build/CCTag/CCTag/src/cctag/test/fitEllipse.cpp(129): last checkpoint
fitEllipse it: 0 provided, at least 5 are needed to estimate an ellipse
fitEllipse it: 1 provided, at least 5 are needed to estimate an ellipse
fitEllipse it: 2 provided, at least 5 are needed to estimate an ellipse
fitEllipse it: 3 provided, at least 5 are needed to estimate an ellipse
fitEllipse it: 4 provided, at least 5 are needed to estimate an ellipse

*** 4 failures are detected in the test module "testFitEllipse"


Test time =   0.06 sec
----------------------------------------------------------
Test Failed.
"cctag_fitEllipse.test_ellipseFitting" end time: Aug 12 09:30 CEST
"cctag_fitEllipse.test_ellipseFitting" time elapsed: 00:00:00
----------------------------------------------------------

2/2 Testing: geometry_ellipse.test_ellipse
2/2 Test: geometry_ellipse.test_ellipse
Command: "/home/me/Documents/build/CCTag/build/Linux-x86_64/geometry_ellipse" "--run_test=test_ellipse" "--catch_system_error=yes"
Directory: /home/me/Documents/build/CCTag/build/src/cctag/geometry/test
"geometry_ellipse.test_ellipse" start time: Aug 12 09:30 CEST
Output:
----------------------------------------------------------
Running 1 test case...

*** No errors detected


Test time =   0.03 sec
----------------------------------------------------------
Test Passed.
"geometry_ellipse.test_ellipse" end time: Aug 12 09:30 CEST
"geometry_ellipse.test_ellipse" time elapsed: 00:00:00
----------------------------------------------------------

End testing: Aug 12 09:30 CEST
mpr-projects commented 2 days ago

Hello, so I spent some time last night debugging the code. Since sometimes the detection works and sometimes it doesn't I was looking for parts of the code that give different results when repeatedly running the test. I think the issue is in file src/cctag/Fitting.cpp. Line 127 is

    const auto evr = M_ev.eigenvectors().real().array();

Up to that line the values of all vectors/matrices are the same when I run the test many times. That's not the case in this line. The eigenvectors (when just taking M_ev.eigenvectors()) are always the same but the result from taking their real component (M_ev.eigenvectors().real()) is not. For example, if I cout the components of M_ev.eigenvectors() for the first test I get

 (-0.498542,0) (0.813644,0) (-0.684956,0)
 (0.764862,0) (0.514083,0) (-0.728583,0)
 (0.407974,0) (0.27148,0) (-0.00162751,0)

and when I cout those of M_ev.eigenvectors().real() (in the same run for the same test) I get

 -91.875 54.25 -5.62393e-15
 37.125 44.25 6.61632e-06
 37.125 2.38221e-44 2.52234e-44

or in another run I get 

-91.875 54.25 4.35458e+27
 37.125 44.25 2.06218e-19
 37.125 7.37873e+28 1.84702e+31

It's been a few years since I last used Eigen so I don't really know what's causing that, I'm assuming there is some issue with Eigen's lazy evaluation. As a quick (and hacky) fix I replaced the single line 127 with

    const auto evr_ = M_ev.eigenvectors();
    const auto evr = evr_.real().array();

I'm not sure why that works, I guess assigning the eigenvectors to evr_ prevents Eigen from doing some optimizations ... anyway, I've temporarily forked your repository (https://github.com/mpr-projects/CCTag/) and added the hacky fix so I can use it more easily when building AliceVision/Meshroom in Docker. Please let me know when CCTag has fixed the issue so I can switch back to your repository.