Harmonize opencv and numpy coordinate conversions

[anuragprat1k]

Type of Issue

OpenCV

0/0---X--->
 |
 |
 Y
 |
 |
 v

Numpy

0/0---column--->
 |
 |
row
 |
 |
 v

We deal with this conversion in the perception stack to make things work but don't have clear types or boundaries defined which creates a minefield for bugs that you have to tread about carefully. Fix this.

Select the type of issue:

• [ ] Bug report (to report a bug)
• [x] Feature request (to request an additional feature)
• [ ] Tracker (I am just using this as a tracker)
• [ ] Refactor request
• [ ] Documentation Ask

[soumith]

from the diagram, are you saying that they are the same co-ordinate system?

[anuragprat1k]

from the diagram, are you saying that they are the same co-ordinate system?

the axis ordering is different because of how indexing works in each - a point at (a,b) in one is at (b,a) in the other.

[soumith]

oh i see, OpenCV returns[x,y] and numpy returns[row, column], got it. I'd have expected OpenCV to return [y, x]. Actually I quickly googled, and they say OpenCV is indeed row-major and returns accessors as [y, x]: https://stackoverflow.com/questions/8184053/accessing-elements-of-a-cvmat-with-atfloati-j-is-it-x-y-or-row-col

[anuragprat1k]

right, that is part of the problem - the order of opencv image coordinate system is the reverse of what you would need for row-major access. So, if you have (x,y) in opencv image coordinates (as in the diagram above), row-major access means you'll need to still use (y,x) to access it (see one of the answers from above https://stackoverflow.com/a/42327350)

[soumith]

that's also what I'm saying.

Whether you use numpy or OpenCV, you use row-major. So they are consistent.