High-quality ellipse detection: arc-support line segments in practice

What the paper contributes and what the code is

The repository is the source code for the paper Arc-support Line Segments Revisited: An Efficient and High-quality Ellipse Detection, and the readme asks you to use the citation of the IEEE TIP version instead of the arXiv version.

That distinction matters for anyone writing this up. The preprint and the journal version are the same work, but the published version is the one to cite, and the readme is explicit about it rather than leaving it to chance.

The framing of the contribution is that the proposed ellipse detector owns the features of high localization accuracy, efficiency, robustness, and stability, which comprehensively yields high-quality ellipse detection performance in front of real-world images. The readme notes that detecting ellipses is universally considered a tough and long-standing problem in the ellipse detection field, and that the aim is to both accurately and efficiently detect ellipses in images.

That dual goal is the interesting framing. Plenty of ellipse detectors are accurate and plenty are fast, and the tension between them is what makes the field difficult. A detector that approximates the arc geometry aggressively is fast but puts the fitted centre slightly off, which matters enormously in an inspection application and hardly at all in a photo of a plate of food.

The source code is free for academic use, and the readme asks you to cite the paper if you use it. That is a different arrangement from an open source licence, and it is the one thing to settle before you build anything on this. The repository carries a file named CC-BY-SA-NC-license.txt, which is the Creative Commons Attribution-ShareAlike-NonCommercial terms, and the licence status recorded for the repository is a custom one that GitHub cannot classify.

So the practical reading is that the academic path is clearly permitted with attribution. Anything commercial needs a separate arrangement with the authors.

The project is written in MATLAB with a C++ extension, the primary language is C++, and the last push was on 2026-08-12 with no GitHub releases published, so there is nothing to install and nothing to version against.

Only two parameters, and what they do

The parameter design is the part of this detector that makes it usable, and the readme is direct about it.

There are only two extrinsic parameters, namely the elliptic angular coverage and the ratio of support inliers, which enables the proposed ellipse detector to be conveniently used and applied in real applications.

Two parameters is a remarkable number for an ellipse detector, and the reason is that the algorithm's internals handle the rest. Most such detectors expose a dozen knobs for edge selection, gradient thresholds, grouping tolerances and refinement iterations, and the defaults rarely suit your images. Here the algorithmic choices are fixed by the method and you tune only two things.

The elliptic angular coverage, written in the readme as $T_{ac}$, is how much of an ellipse's angular extent a candidate arc set must cover. The default is 165 degrees. A high value means the arc support has to wrap most of the way around the ellipse, which rejects spurious arc groups that only happen to look locally elliptical.

The ratio of support inliers, $T_r$, is how much of the observed arc support has to be consistent with the candidate ellipse. The default is 0.6. Raising it makes the detector stricter about outliers in the support set, lowering it lets it tolerate noisier data.

The readme is careful about the defaults: the values 165 degrees and 0.6 are used for comparison experiments in the paper. That is an important detail, because it tells you the defaults are tuned to make the paper's benchmarks comparable rather than to be optimal for arbitrary photographs. Anyone applying this to their own images should expect to move them.

The example in section 4.4 of the readme does exactly that, using $T_{ac} = 165^{o}$ and $T_r = 0.5$ on the image that mixes polarities. So even the authors lowered the inlier ratio for the harder case, where the image contains ellipses of both signs.

There is a third option that is not a tuning knob but a filter. The specified_polarity option can help users find the polarity-specific ellipses in the image. The readme demonstrates it with separate positive and negative polarity runs over the same image, which is how you isolate the dark-rimmed ellipses from the bright-rimmed ones in an image where both appear.

That option is what makes the detector practical for inspection work, where an object's outline and its inner structure can produce ellipses of opposite sign that you do not want mixed together.

Building it, and the MATLAB dependency chain

The requirements are short and they are old-fashioned.

MATLAB, OpenCV version 2.4.9, and 64-bit Windows operating system. That is the whole list, and the specific OpenCV version is a strong signal about the era the code was written in.

The build step is a mex compilation. You compile the file generateEllipseCandidates.cpp in MATLAB on your computer to generate the mex file generateEllipseCandidates.mexw64, and the readme gives the exact command:

mex generateEllipseCandidates.cpp -IF:\OpenCV\opencv2.4.9\build\include -IF:\OpenCV\opencv2.4.9\build\include\opencv -IF:\OpenCV\opencv2.4.9\build\include\opencv2 -LF:\OpenCV\opencv2.4.9\build\x64\vc11\lib -IF:\Matlab\settlein\extern\include -LF:\Matlab\settlein\extern\lib\win64\microsoft -lopencv_core249 -lopencv_highgui249 -lopencv_imgproc249 -llibmwlapack.lib

Every path in that command is an absolute Windows path, and the readme says the corresponding software paths of OpenCV and MATLAB should be replaced with your own. So the command is a template rather than something you paste and run.

What the flags show is the structure of the dependency. The three -I flags point at the OpenCV include directories and at MATLAB's own extern include directory. The -L flags point at the OpenCV x64 vc11 library directory and at MATLAB's win64 microsoft library directory, and the final -l flags link against three specific OpenCV libraries, opencv_core, opencv_highgui and opencv_imgproc, and against libmwlapack for the linear algebra routines.

The fact that the C++ file exists at all is the design point. Generating ellipse candidates from an edge map is the expensive part of the pipeline, and putting it in a compiled mex extension rather than in MATLAB vectorised code is what makes it fast. The MATLAB side then does the grouping and fitting.

Once that is built, the usage is two steps. Compile the mex file, then run the demo file LCS_ellipse.m. The repository layout matches that split exactly: generateEllipseCandidates.cpp is the compiled extension, ellipseDetectionByArcSupportLSs.m is the detection algorithm, fitEllipse.m does the fitting, drawEllipses.m renders the results, and LCS_ellipse.m is the demo that drives the whole thing.

There is also a C++ re-implementation linked in the readme, by the GitHub user memory-overflow, under the name standard-ellipse-detection, which is worth knowing about if you need the algorithm without MATLAB.

What the examples show about performance

The examples section gives the numbers with the machine specified, which is the right way to report a runtime.

The results run with default parameters on the same computer with an Intel Core i7-7500U 2.7GHz CPU and 8 GB of memory. The individual runs are: four detected ellipses in 0.090 seconds at 651 x 436 resolution, twenty-five in 0.460 seconds at 720 x 435, three in 0.060 seconds at 512 x 456, and eight in 0.110 seconds at 752 x 525.

So the timings are comfortably interactive. Even the twenty-five ellipse case, which is the heaviest of the four, finishes in under half a second, and the fastest is a twentieth of a second. For a detector working on individual images that is not a constraint, and it is worth noting the machine is a laptop-class processor rather than a desktop part.

The polarity examples use the same image at 752 x 525 and are almost identical in cost: 0.080 seconds for the positive polarity run and 0.086 seconds for the negative one. That symmetry tells you the polarity filter is a cheap classification of already-computed candidates rather than an extra detection pass, which is what you would hope for since you might run both.

The mixed-polarity example is the one that shows the cost of a looser setting. It detects five ellipses in 0.226 seconds at 1000 x 680, with the angular coverage at 165 degrees and the inlier ratio lowered to 0.5. So on the largest image in the set, with the inlier ratio lowered to 0.5, it takes about four times as long as the simplest case. The resolution is not the only factor, since the strictness setting changes how many candidates survive to the fitting stage, but the combination tells you that the parameter that matters for speed is the inlier ratio rather than the angular coverage.

That is a useful thing to work out from four examples rather than a hundred. A looser inlier ratio keeps more candidate arc groups alive through the pipeline, and every one of them costs a fitting attempt.

The successful application cases listed at the end of the readme are what the accuracy claim is for: car wheel hub recognition, PCB inspection, object fingerprinting and robot vision. All four are tasks where a slightly wrong ellipse is a wrong measurement rather than a cosmetic difference, which is consistent with the emphasis on localization accuracy over a detector that merely finds something elliptical.

Editorial conclusion

Adopt this detector if you need accurate ellipse fitting on real images, particularly where a border case decides the answer, because the design keeps full resolution arc geometry instead of approximating it. Do not adopt it for production use without checking the licence terms, because the code is released free for academic use with a citation requirement rather than under a permissive open source licence. Before you commit, read the two parameter descriptions carefully, since the defaults were chosen for the paper's comparison experiments rather than for your images, and use the specified_polarity option when your ellipses have a known sign.

Frequently asked questions

Official sources

1. AlanLuSun/High-quality-ellipse-detection on GitHub
2. Issues
3. README