Revision history [back]

well, i can try to explain, why it is so, but there seems to be no quick way to fix it:

opencv is a c++ library, and the python wrappers are auto-generated from some scripts, so in c++ we have:

vector<Vec4i> lines;

to hold the hough results.

now unfortunately , Vec4i is a descendant of Matx , which is actually a 2d thing, so in python you get:

[ #one for the vector
 [ #one for the 1st dim of Vec4i (1, pretty useless, admittedly :)
  [ #one for the 2nd dim of Vec4i (4 elements)

again, i think, you'll just have to live with it.

well, i can try to explain, why it is so, but there seems to be no quick way to fix it:

opencv is a c++ library, and the python wrappers are auto-generated from some scripts, so in c++ we have:

vector<Vec4i> lines;

to hold the hough results.

now unfortunately , Vec4i is a descendant of Matx , which is actually a 2d thing, so in python you get:

[ #one for the vector
 [ #one for the 1st dim of Vec4i (1, pretty useless, admittedly :)
  [ #one for the 2nd dim of Vec4i (4 elements)

again, i think, you'll just have to live with it.

well, i can try to explain, why it is so, but there seems to be no quick way to fix it:

opencv is a c++ library, and the python wrappers are auto-generated from some scripts, so in c++ we have:

vector<Vec4i> lines;

to hold the hough results.

now unfortunately , Vec4i is a descendant of Matx , which is actually a 2d thing, so in python you get:

[ #one for the vector
 [ #one for the 1st dim of Vec4i (1, pretty useless, admittedly :)
  [ #one for the 2nd dim of Vec4i (4 elements)

again, i think, you'll just have to live with it.