cihantopal / ed_lib

Implementations of edge (ED, EDColor, EDPF), line (EDLines), circle and low eccentric ellipse (EDCircles) detection algorithms.

ED_Lib

EDGE DRAWING LIBRARY FOR GEOMETRIC FEATURE EXTRACTION AND VALIDATION

Keywords: edge detection, edge segment detection, color edge detection, line detection, line segment detection, circle detection, ellipse detection.

Edge Drawing (ED) algorithm is an proactive approach on edge detection problem. In contrast to many other existing edge detection algorithms which follow a subtractive approach (i.e. after applying gradient filters onto an image eliminating pixels w.r.t. several rules, e.g. non-maximal suppression and hysteresis in Canny), ED algorithm works via an additive strategy, i.e. it picks edge pixels one by one, hence the name Edge Drawing. Then we process those random shaped edge segments to extract higher level edge features, i.e. lines, circles, ellipses, etc. The popular method of extraction edge pixels from the thresholded gradient magnitudes is non-maximal supressiun that tests every pixel whether it has the maximum gradient response along its gradient direction and eliminates if it does not. However, this method does not check status of the neighboring pixels, and therefore might result low quality (in terms of edge continuity, smoothness, thinness, localization) edge segments. Instead of non-maximal supression, ED points a set of edge pixels and join them by maximizing the total gradient response of edge segments. Therefore it can extract high quality edge segments without need for an additional hysteresis step.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The list of algorithms in this library:

ED: Edge Drawing detection algorithm. Detects edge segments in an input image and provides the result in segment form (a vector of edge segment pixels).

Paper: C. Topal, C. Akinlar, Edge Drawing: A Combined Real-Time Edge and Segment Detector, Journal of Visual Communication and Image Representation, vol.23, no.6, pp.862-872, August 2012.

[https://www.sciencedirect.com/science/article/pii/S1047320312000831]

Demo video: https://www.youtube.com/watch?v=-Bpb_OLfOts

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

EDPF: Edge Drawing - Parameter Free: Detects edge segments without need for parameter tuning. It runs naive ED with all parameters at their extreme to detect all possible edge segments, then invalidates false detected segments due to Helmholtz Principle.

Paper: C. Akinlar, C. Topal, EDPF: A Real-time Parameter-free Edge Segment Detector with a False Detection Control, Int’l Journal of Pattern Recognition and Artificial Intelligence, vol.26, no.1, 2012.

[https://doi.org/10.1142/S0218001412550026]

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

EDLines: Detects line segments in the image and provides the result as a vector list consisting of starting and ending points. EDLines is alos a parameter-free algorithm which validates all detected lines via Helmholtz Principle.

Paper: C. Akinlar, C. Topal, EDLines: A real-time line segment detector with a false detection control, Pattern Recognition Letters, vol.32, iss.13, pg. 1633-1642, October 2011.

[https://www.sciencedirect.com/science/article/pii/S0167865511001772]

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

EDCircles: Detects circles and ellipses (up to a level of eccentricity) in an input image and returns the result in a list of circle and ellipse parameters. Just like EDPF and EDLines, EDCircles is alos a parameter-free algorithm that applies validation via Helmholtz Principle.

Paper: C. Akinlar, C. Topal, EDCircles: A Real-time Circle Detector with a False Detection Control, Pattern Recognition, 46(3), 725-740, March 2013.

[https://www.sciencedirect.com/science/article/pii/S0031320312004268]

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

EDColor: Edge Drawing - Color: Detects edges in segment form on color image using a color gradient computation, hence provides better results than converting the image to grayscale.

Paper: C. Akinlar, C. Topal, ColorED: Color edge and segment detection by Edge Drawing (ED), Journal of Visual Communication and Image Representation, vol.44, pp.82-94, April 2017.

[https://www.sciencedirect.com/science/article/pii/S1047320317300305]

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Instructions: You can detect edge segments with ED, EDPF and EDColor; and lines and circles with EDLines and EDCircles, easily. It is also possible to feed ED instances to EDLines or EDCircles to extract line segments, circles and ellipses without need to run edge segment detection again. In this way, redundant computation can be avoided. Results might slightly differ between using directly EDLines and ED + EDX (EDLines, EDCircles, etc.) because of the differences in default gradient operators and parameters in the algorithms. There are several usage scenarios available in test.cpp.

Dependencies: OpenCV 3.4

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Disclaimer for Edge Drawing Library

This software library is provided "as is" and "with all faults." Authors of this library make no warranties of any kind concerning the safety, suitability, lack of viruses, inaccuracies, typographical errors, or other harmful components of this software product. There are inherent dangers in the use of any software, and you are solely responsible for determining whether this software product is compatible with your equipment and other software installed on your equipment. You are also solely responsible for the protection of your equipment and backup of your data, and the authors of this software product will not be liable for any damages you may suffer in connection with using, modifying, or distributing this software product. By using this library in any scientific work, you are implicitly presumed to have accepted all of the above statements, and accept to cite the aforementioned papers.

ed_lib's Issues

incorrect comment in circle linear equation

At line 2968 in file EDCircles.cpp, there is a mistake.

// |N Suv| |uc| = |b1|
// |Suv Svv| |vc| = |b2|

It should be:

// |Suu Suv| |uc| = |b1|
// |Suv Svv| |vc| = |b2|

Memory leak， Process finished with exit code 137 (interrupted by signal 9: SIGKILL)

EdgeDrawing algorithm is great，
but i find that the EdgeDrawing algorithm in opencv contrib, as the program runs, the memory usage is increasing

MIT license conflict with header file GPLv3 license

ED_Lib/EDLines.h

Line 7 in 7f171db

* it under the terms of the GNU General Public License as published by

Hi, License in the header file is GPLv3, and there exists an sole MIT license file, and license information at the end of the readme file is Please contact for commercial use. The three of them are in conflict, which one should we observe?

how add rectangle detecte?

Possible minor bug in EDCircles::DetectArcs()

ED_Lib/EDCircles.cpp

Line 898 in f187542

if (specialCase && coverage < 1.0 / 16) { info[firstLine].taken = true; firstLine = lastLine; continue; }

According to the comment, this line should say greater than, not less than. Like so:

// In the case of the special case, the arc must cover at least 22.5 degrees
if (specialCase && coverage > 1.0 / 16) { info[firstLine].taken = true; firstLine = lastLine; continue; }

I think changing this reduces EDCircles' number of "false positives", or at least the positives that I don't recognize as (partial) circle myself when I look manually at the edgeImage.

CMake Error: target name "test" is reserved

I would like to include ED_Lib as a git submodule in my project but I get the following error:

CMake Error at 3rdparty/ED_Lib/CMakeLists.txt:24 (add_executable):
  The target name "test" is reserved when CTest testing is enabled.

This error occurs as a result of the following code in CMakeLists.txt:

add_executable(test test.cpp)
target_link_libraries(test ${OpenCV_LIBS} EDLib)

CMake includes some functionality for automated testing so the name "test" is reserved. Would it be possible to rename the target "test" into something else?

Chopping off one pixel at the end of each segment in EDPF::ExtractNewSegments()

ED_Lib/EDPF.cpp

Line 219 in 7f171db

vector<Point> subVec(&segmentPoints[i][start], &segmentPoints[i][end - 1]);

My fork is getting so refactored that it's a bit hard to translate back to original ED_Lib now, but I think the referenced line is in error. I think it should just say end, instead of end - 1.

The corresponding line in my code is here:
https://gitlab.com/tobben/hpm/-/blob/b079a6f824984bc89cc7df5ed1247974fda99dbe/hpm/ed/EDCommon.c++#L33

The issue is easiest to see and to validate manually in very short segments. This is the edgeImage:

This is the validated segment when using end - 1.

This is the same segment with end - 1 changed to end:

Changing this makes EDCircles find more circles.

Please stop me if the copping of that last pixel is intentional, which it very well might be.

Ironically, from a top level view, the performance of my particular application got worse, since more (real) circles were found, that it had to filter away. I balanced this back by lowering LONG_ARC_ERROR in EDCircles.cpp.

buffer size too small

For large size image, EDLines buffer sizes are some times too small and constructor overruns.

In my use, I've fixed the lines as bellow.

ED_Lib/EDLines.cpp

Line 24 in 745472f

// Temporary buffers used during line fitting

    size_t buffer_size = 1; 

    for (int segmentNumber = 0; segmentNumber < segmentPoints.size(); segmentNumber++) {
        auto segment_size = segmentPoints[segmentNumber].size();
        buffer_size = std::max(buffer_size, segment_size);
    }    

    double *x = new double[buffer_size];
    double *y = new double[buffer_size];

What is the reasoning behind dividing sigma by 2.5 when performing edge validation?

The paper states that ED works best with sigma = 1, which I can see is what is used.
But, why then does the code divide the original sigma by 2.5 and re-smooth the image?

ED_Lib/EDPF.cpp

Line 20 in 6ea56f1

sigma /= 2.5;

I don't see any rational for this in the paper, am I missing something? Does this produce better validation results?

how to adjust the circle parameters to detect high-resolution（5500*4500） images

Will EDColor be implemented in OpenCV?

Hi, EDColor is still missing in OpenCV, do you plan to work on it? It is the only "module" missing in the ED series... Since 2020 I am using my own adapted version and maybe i missed some improvements... (I already proposed one and it is still open though)

Thanks for the already good work.

EDColor : about converting RGB to CIEL*a*b*

Hi,

nice job done here, I tried your library and it works pretty well (I only used EDColor which interested me more).

Looking at the code, there's something maybe you're not aware of.
When converting RGB to XYZ space, RGB values have to be linear (gamma corrected).
So like in the test example, feeding the algorithm with an image directly read from a file is a bit incorrect. I added my own function to get lineared RGB and the detection is better !

If you want to try it yourself, here is my function to convert RGB to linear :

void EDColor::RGBtoLinear(const double &R, const double &G, const double &B, double &r, double &g, double &b, const bool &fast) // Apply linear RGB gamma correction
{
    if (fast) {
        r = 0.012522878 * R + 0.682171111 * R * R + 0.305306011 * R * R * R;
        g = 0.012522878 * G + 0.682171111 * G * G + 0.305306011 * G * G * G;
        b = 0.012522878 * B + 0.682171111 * B * B + 0.305306011 * B * B * B;
    }
    else {
        // Gamma correction - conversion to linear space - source http://www.brucelindbloom.com/index.html?Eqn_RGB_to_XYZ.html
        // most correct approximation but it is SLOW
        if (R > 0.04045)
            r = pow((R + 0.055) / 1.055, 2.4);
        else
            r = R / 12.92;
        if (G > 0.04045)
            g = pow((G + 0.055) / 1.055, 2.4);
        else
            g = G / 12.92;
        if (B > 0.04045)
            b = pow((B + 0.055) / 1.055, 2.4);
        else
            b = B / 12.92;
    }
}

In EDColor.cpp, function MyRGB2LabFast() - compute red, green and blue like this :

...
for (int i = 0; i<width*height; i++) {
        R = redImg[i] / 255.0;
        G = greenImg[i] / 255.0;
        B = blueImg[i] / 255.0;
        RGBtoLinear(R, G, B, red, green, blue, true);
        ...

Regards,
AbsurdePhoton.

double free or corruption (out)

When use the camera to detect the circle, some errors will occur after the program runs for a period of time.
I found that the following three errors will be reported.
1、double free or corruption (out)
2、free(): invalid next size (fast):
3、corrupted double-linked list

Hello, I would like to know if your EDCilrcle can realize real-time circular recognition

Hello, I would like to know if your EDCilrcle can realize real-time circular recognition

why different opencv?

Thanks for great job for line and circle detection.
After run test_ED, opencv(4.5.2) & EDLIB show different run time but same results(no diff between pixel), as follows:
testED.getEdgeImage() (Original) : 48.5386
detectEdges() (OpenCV) : 15.8752
different pixel count : 0
-------------------------------------------------
testEDLines.getLineImage() : 7.61791
detectLines() (OpenCV) : 22.7407
different pixel count : 0
Also, opencv consumes less total time(include detectEdge and detectLine). Any difference in function implemention？

circle or ellipse, I also want get the fit No. of segmentPoints, how to do?

I got the circle from Ytup_Det_Ed_Cricles testEDCircles = Ytup_Det_Ed_Cricles(testED)
I got the outline from testED.getSegments()
but i also want get the circle's outline match No. of the segmentPoints

License File

Hey, there doesn't seem to be a license file in this repo??

Error when I build

/home/amov/LineDetector/ED_Lib/video_test.cpp: In function ‘int main(int, const char**)’: /home/amov/LineDetector/ED_Lib/video_test.cpp:35:13: error: ‘EdgeDrawing’ was not declared in this scope Ptr<EdgeDrawing> ed = createEdgeDrawing(); ^~~~~~~~~~~ /home/amov/LineDetector/ED_Lib/video_test.cpp:35:24: error: template argument 1 is invalid Ptr<EdgeDrawing> ed = createEdgeDrawing(); ^ /home/amov/LineDetector/ED_Lib/video_test.cpp:35:31: error: ‘createEdgeDrawing’ was not declared in this scope Ptr<EdgeDrawing> ed = createEdgeDrawing(); ^~~~~~~~~~~~~~~~~ /home/amov/LineDetector/ED_Lib/video_test.cpp:36:11: error: base operand of ‘->’ is not a pointer ed->params.EdgeDetectionOperator = EdgeDrawing::SOBEL; ^~ /home/amov/LineDetector/ED_Lib/video_test.cpp:36:44: error: ‘EdgeDrawing’ is not a class, namespace, or enumeration ed->params.EdgeDetectionOperator = EdgeDrawing::SOBEL; ^~~~~~~~~~~ /home/amov/LineDetector/ED_Lib/video_test.cpp:37:11: error: base operand of ‘->’ is not a pointer ed->params.GradientThresholdValue = 36; ^~ /home/amov/LineDetector/ED_Lib/video_test.cpp:38:11: error: base operand of ‘->’ is not a pointer ed->params.AnchorThresholdValue = 8; ^~ /home/amov/LineDetector/ED_Lib/video_test.cpp:54:15: error: base operand of ‘->’ is not a pointer ed->detectEdges(gray); ^~ /home/amov/LineDetector/ED_Lib/video_test.cpp:55:15: error: base operand of ‘->’ is not a pointer ed->detectLines(lines); ^~ /home/amov/LineDetector/ED_Lib/video_test.cpp:56:15: error: base operand of ‘->’ is not a pointer ed->detectEllipses(ellipses); ^~ CMakeFiles/video_test.dir/build.make:62: recipe for target 'CMakeFiles/video_test.dir/video_test.cpp.o' failed make[2]: *** [CMakeFiles/video_test.dir/video_test.cpp.o] Error 1
so there may some problem with EdgeDrawing,but I can`t find it in the source
How to do it?
Thanks

Bug in method EDCircles::ValidateCircles()

Dear @CihanTopal

There is a bug from **line 1073 to 1101** in the file **EDCircles.cpp**. the variable _noPoints_ may exceed the number of _8*(width+height)_which is the allocated size for the pointer px, py. In this case, the operation for the px,py on **EDCircles::ComputeEllipsePoints** from **line 2596 to 2612** will WRITE out of the memory allocated for the pointer px and py. It will destory the Heap of the program and issue crash or unknow problems.

Solution: 
    1) allocate the px,py after the _noPoints_ caculated  and destroy it in each loop. 
OR
    2) allocate enough space for the pointer px,py base on the width/height of the image.

Thanks for your Great idea of the ED algorithm.

Best,
Gan

EDCircles Request for Ideas

Hello @CihanTopal!

This time I've given the following image to EDColor:

It generates nice edges and segments:

But, EDCircle misses one of my markers (the top blue one).

I've tried adjusting gradThresh and sigma (the blur size). It's possible to tweak them so that all six markers are found in this test image, but then I get a similar problem, with missing markers, in other test images, so I want to keep gradThresh and sigma fixed.

That marker looks close to circular in the segments image:

... which gives me hope that EDCircles could be tweaked to detect it.

I want to dive into EDCircles.cpp to see if there's anything I can do. Do you have any immediate ideas about where I could start?
Is there something in the segment structure around the circle that makes it an edge case, or particularly hard to detect?

Best regards,

about constuct by python

Merhaba, geçenlerde 'Edge Drawing A combined real-time edge and segment detector' makalenizi okudum, parçayı değiştirmek istiyorum, ED algoritmasının python uygulaması var mı? İlgili bilgiler için teşekkür ederiz.
Hello, I recently read your article 'Edge Drawing A combined real-time edge and segment detector', and I want to modify part of the code. Is there a python implementation of ED algorithm? Any relevant information would be greatly appreciated.

EDColor detect line cost time to expensive

hello CihanTopal,EDColor detect line cost time to expensive.Do you have idea to decrease time when deal with color image

Accuracy on detected radii, minor axes and major axes

I'm experimenting with using ED_Lib for a motion tracking system that tracks colored spheres on images.

Today I conducted the following experiment:

1. Create a render where 135 red spheres of known size are placed out in a grid pattern on a plane, against a white background.
2. Use EDColor to detect as many as possible (never mind false positives, they are not a problem).
3. Use center point and minor axis (not major axis) gotten from EDColor to calculate a 3d position for each sphere.
4. For each position, place out a different colored, equal sized sphere alongside the red one.
5. Create a new render, which shows the error in 3d position, for each sphere.

The output of EDColor (result of step 2) was like this:

The image above is scaled down. The real output from step 2 is very large (123Mpix).

We see that EDColor regards spheres that are projected close to the image center, as well as halved sphere projections along the top and bottom edges of the image as circles. We also see that complete sphere projections far from the image center is recognized as ellipses.

So ED_Lib deviates a bit from reality. All the projections of spheres, except the middle one, are really ellipse shapes. This deviation was expected.

The result of step 5 was like this:

or, seen from straight above:

Here we see that ED_Lib is good enough at finding the correct ellipse center.
We also see that ED_Lib is good enough at finding the radii/minor axes of the projections that are close to the image center (nearly perfectly circular ones).

However, it looks like ED_Lib has troubles detecting accurate enough minor axis size for the more elliptical projections, both those that are approximated to be circles, and those who are recognized as ellipses.

In reality, the radii/minor axes of all the projections are identical.

Here is a close up of one of the most elliptical sphere projections, overlaid with the ED/EDPF edge image in black, and the detected ellipse, in yellow:

We see that the detected ellipse is too small by ~1 pixel (some places 0, some places 2, but never too large).
This causes the calculation in step 3 to find a position that is too far away from the camera.

Here is another example, with one of the most elliptical projections that is still recognized as a circle by EDCircle:

We see a white gap between the green line and the red sphere, which means that the radius found by EDCircle is bigger than the real minor axis. This causes the calculation in step 3 to find a position that is too close to the camera.

I have thoroughly tested my equations, and done the same experiment with another circle detector to make sure the 3d position errors you see above really originate from ED_Lib's axis detection errors.

So finally, the question:
I want to minimize or compensate for the radius/minor axis error.
I can imagine a few ad-hoc solutions that would scale the radii or minor/major axes after the fact, but I wonder:
Is there anything we can do to improve the accuracy of ED_Lib itself?
Where would you start?

Best regards, and thanks again for ED_Lib!
tobben

PS! I also did the experiment with step 3. changed to include the detected major axis in the calculations. That produced a slightly worse result, errors in the same direction, but larger, so never mind the major axis, I just need accurate enough minor axes.

PPS! My code is here. gitlab.com/tobben/hpm and the usage of it is here gitlab.com/tobben/hp-mark

license

EDColor.h has still a reference to GPL

check case

ED.cpp line 336

Code:
case SCHARR_OPERATOR:
gx = abs(3 * (com1 + com2) + 10 * (smoothImg[iwidth + j + 1] - smoothImg[iwidth + j - 1]));
gy = abs(3 * (com1 - com2) + 10 * (smoothImg[(i + 1)*width + j] - smoothImg[(i - 1)*width + j])); // <-- break missing ?
case LSD_OPERATOR:

Truncation of ellipse major and minor axis lengths

In an earlier issue, I've said that I solved an issue by adding + 1.0 to these lines:

  // semimajor axis
  a = sqrt(F3 / A2) + 1.0;
  // semiminor axis
  b = sqrt(F3 / C2) + 1.0;

Now I've removed the + 1.0s again, and solved the issue in a better way.

The semi-major and semi-minor axis lengths were truncated, which caused the accuracy issue I had. This is solved by changing the type of the axes member within the mEllipse class from cv::Size to cv::Size2d.

Here:
https://github.com/CihanTopal/ED_Lib/blob/master/EDCircles.h#L54

Also, the constructor and all calls to it must be adjusted to take doubles.

All other parts of the code use doubles for major/minor axis lengths, so no further changes are required.

This fix improves accuracy of the ellipse detector by half, or maybe a quarter of, a pixel on average.