cihantopal / ed_lib Goto Github PK

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

EDColor.h has still a reference to GPL

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

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.

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

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.

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,

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:

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?

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

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

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

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？

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.

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.

    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];

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

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?

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|

/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

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

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.

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