Revision history [back]

we avoid the word 'bug' here, we rather call it an 'interesting situation' ..

no, fun apart,

where do the c++ and the python solution differ ?

 >>> help(cv2.HoughLinesP)
Help on built-in function HoughLinesP:

HoughLinesP(...)
    HoughLinesP(image, rho, theta, threshold[, lines[, minLineLength[, maxLineGap]]]) -> lines

if you stare hard enough at it, you see the 'lines' argument in the middle. if you omit that, you will have to call each following argument by name like:

lines = cv2.HoughLinesP(dst, 1, np.pi/180, 80, minLineLength=30, maxLineGap=10)

this will already give you the same number of lines / same image as in c++

where do the 2.4 and the 3.0 (python)version differ ?

the 2.4 version is using c-api code under the hood, a CvSeq is used to keep the lines, this gets translated into a 1 row, n cols Mat, resulting in a (numpy)shape like (1,280,4), while the 3.0 version wraps a vector<Vec4i> into a n cols, 1 row Mat , resulting in (280,1,4) shape. rows and cols swapped, that's it.

in the end, this code:

for x1,y1,x2,y2 in lines[0]:
     cv2.line(color_dst, (x1,y1), (x2,y2), (0,255,0), 3, 8)

hits the 1 row in 2.4 correctly, and iterates over cols, while for 3.0, you'd have to use something like:

for l in lines:
    for x1,y1,x2,y2 in l:
        cv2.line(color_dst, (x1,y1), (x2,y2), (0,255,0), 3, 8)

(btw, turns out , the houghlines.py in the 3.0 samples is broken in the very same way ! ..)

we avoid the word 'bug' here, we rather call it an 'interesting situation' ..

no, fun apart,

where do the c++ and the python solution differ ?

 >>> help(cv2.HoughLinesP)
Help on built-in function HoughLinesP:

HoughLinesP(...)
    HoughLinesP(image, rho, theta, threshold[, lines[, minLineLength[, maxLineGap]]]) -> lines

if you stare hard enough at it, you see the 'lines' argument in the middle. if you omit that, you will have to call each following argument by name like:

lines = cv2.HoughLinesP(dst, 1, np.pi/180, 80, minLineLength=30, maxLineGap=10)

this will already give you the same number of lines / same image as in c++

where do the 2.4 and the 3.0 (python)version differ ?

the 2.4 version is using c-api code under the hood, a CvSeq is used to keep the lines, this gets translated into a 1 row, n cols Mat, resulting in a (numpy)shape like (1,280,4), (1,681,4), while the 3.0 version wraps a vector<Vec4i> into a n cols, 1 row Mat , resulting in (280,1,4) (681,1,4) shape. rows and cols swapped, that's it.

in the end, this code:

for x1,y1,x2,y2 in lines[0]:
     cv2.line(color_dst, (x1,y1), (x2,y2), (0,255,0), 3, 8)

hits the 1 row in 2.4 correctly, and iterates over cols, while for 3.0, you'd have to use something like:

for l in lines:
    for x1,y1,x2,y2 in l:
        cv2.line(color_dst, (x1,y1), (x2,y2), (0,255,0), 3, 8)

(btw, turns out , the houghlines.py in the 3.0 samples is broken in the very same way ! ..)

we avoid the word 'bug' here, we rather call it an 'interesting situation' ..

no, fun apart,

where why do the c++ and the python solution differ ?

 >>> help(cv2.HoughLinesP)
Help on built-in function HoughLinesP:

HoughLinesP(...)
    HoughLinesP(image, rho, theta, threshold[, lines[, minLineLength[, maxLineGap]]]) -> lines

if you stare hard enough at it, you see the 'lines' argument in the middle. if you omit that, you will have to call each following argument by name like:

lines = cv2.HoughLinesP(dst, 1, np.pi/180, 80, minLineLength=30, maxLineGap=10)

this will already give you the same number of lines / same image as in c++

where why do the 2.4 and the 3.0 (python)version differ ?

the 2.4 version is using c-api code under the hood, a CvSeq is used to keep the lines, this gets translated into a 1 row, n cols Mat, resulting in a (numpy)shape like (1,681,4), while the 3.0 version wraps a vector<Vec4i> into a n cols, 1 row Mat , resulting in (681,1,4) shape. rows and cols swapped, that's it.

in the end, this code:

for x1,y1,x2,y2 in lines[0]:
     cv2.line(color_dst, (x1,y1), (x2,y2), (0,255,0), 3, 8)

hits the 1 row in 2.4 correctly, and iterates over cols, while for 3.0, you'd have to use something like:

for l in lines:
    for x1,y1,x2,y2 in l:
        cv2.line(color_dst, (x1,y1), (x2,y2), (0,255,0), 3, 8)

(btw, turns out , the houghlines.py in the 3.0 samples is broken in the very same way ! ..)

we avoid the word 'bug' here, we rather call it an 'interesting situation' ..

no, fun apart,

why do the c++ and the python solution differ ?

 >>> help(cv2.HoughLinesP)
Help on built-in function HoughLinesP:

HoughLinesP(...)
    HoughLinesP(image, rho, theta, threshold[, lines[, minLineLength[, maxLineGap]]]) -> lines

if you stare hard enough at it, you see the 'lines' argument in the middle. if you omit that, you will have to call each following argument by name like:

lines = cv2.HoughLinesP(dst, 1, np.pi/180, 80, minLineLength=30, maxLineGap=10)

this will already give you the same number of lines / same image as in c++

why do the 2.4 and the 3.0 (python)version differ ?

the 2.4 version is using c-api code under the hood, a CvSeq is used to keep the lines, this gets translated into a 1 row, n cols Mat, resulting in a (numpy)shape like (1,681,4), while the 3.0 version wraps a vector<Vec4i> into a n cols, rows, 1 row col Mat , resulting in (681,1,4) shape. rows and cols swapped, that's it.

in the end, this code:

for x1,y1,x2,y2 in lines[0]:
     cv2.line(color_dst, (x1,y1), (x2,y2), (0,255,0), 3, 8)

hits the 1 row in 2.4 correctly, and iterates over cols, while for 3.0, you'd have to use something like:

for l in lines:
    for x1,y1,x2,y2 in l:
        cv2.line(color_dst, (x1,y1), (x2,y2), (0,255,0), 3, 8)

(btw, turns out , the houghlines.py in the 3.0 samples is broken in the very same way ! ..)

why do the c++ and the python solution differ ?

 >>> help(cv2.HoughLinesP)
Help on built-in function HoughLinesP:

HoughLinesP(...)
    HoughLinesP(image, rho, theta, threshold[, lines[, minLineLength[, maxLineGap]]]) -> lines

if you stare hard enough at it, you see the 'lines' argument in the middle. if you omit that, you will have to call each following argument by name like:

lines = cv2.HoughLinesP(dst, 1, np.pi/180, 80, minLineLength=30, maxLineGap=10)

this will already give you the same number of lines / same image as in c++

why do the 2.4 and the 3.0 (python)version differ ?

the 2.4 version is using c-api code under the hood, a CvSeq is used to keep the lines, this gets translated into a 1 row, n cols Mat, resulting in a (numpy)shape like (1,681,4), while the 3.0 version wraps a vector<Vec4i> into a n rows, 1 col Mat , resulting in (681,1,4) shape. rows and cols swapped, that's it.

in the end, this code:

for x1,y1,x2,y2 in lines[0]:
     cv2.line(color_dst, (x1,y1), (x2,y2), (0,255,0), 3, 8)

hits the 1 row in 2.4 correctly, and iterates over cols, while for 3.0, you'd have to use something like:

for l in lines:
    for x1,y1,x2,y2 in l:
        cv2.line(color_dst, (x1,y1), (x2,y2), (0,255,0), 3, 8)

(btw, turns out , the houghlines.py in the 3.0 samples is broken in the very same way ! ..)