Absent documentation for sub-pixel coordinate system

[Kirill888]

System information (version)

• OpenCV => all
• Operating System / Platform => all
• Compiler => all

Detailed description

There are a number of methods in OpenCV that accept or generate pixel coordinates as floating point numbers, remap is one of those methods I am using. I googled for a while trying to find out whether this method places centre of the top-left pixel at 0,0 or at 0.5,0.5, some conflicting information came up:

http://answers.opencv.org/question/87923/sub-pixel-coordinate-origin/
http://answers.opencv.org/question/35111/origin-pixel-in-the-image-coordinate-system-in-opencv/

It seems that the correct answer is 0,0 is the centre of the top left pixel, judging by this commit:

e646f9d

There should be a place somewhere in the documentation where the pixel coordinate system is properly defined, not just for the integer case. One paragraph stating what the coordinates of the centre and the four corners of the top left pixel are would suffice.

[alalek]

It depends on concrete implementation of algorithm. I suggest to start digging from resize() algorithms instead of AKAZE implementation. Check for used formulas.
Also nobody forbids to have both approaches/implementations somewhere.

[Kirill888]

Alright, so you are saying that there is no "global library convention" for pixel coordinates beyond integer indexing?

Then documentation for remap function should state explicitly what coordinate system it uses, and it better be consistent with other geometric transform functions, who also don't explicitly define coordinate system they use.

Or are you saying that different backends of that function can assign different meaning to where point 0,0 is?

[alalek]

different backends of that function can assign different meaning

If you mean OpenCL, IPP, OpenVX backends then answer is no - they must use the same meaning of pixel points as original C++ implementation.

warpAffine() can emulate both pixel coordinate systems in theory (it can be transformed via updating transformation matrix). cv::warpPerspective() can't switch between pixel coordinates via changing of input parameters.

Usually you can see selected pixel coordinate symbols via provided formulas (in case of OpenCV there is sometimes lack of details in documentation, but there is open source code and tests).
There are some examples from OpenVX documentation:

• Scale image (resize)
• Warp affine / Warp Perspective
• Remap

[Kirill888]

Thank you for the links, unfortunately they too seem to lack the definition of where exactly 0,0 is relative to pixel boundaries/centre.

I have established experimentally that 0,0 is the centre of the top-left pixels, at least as far as remap is concerned. Here is my experiment in python, hopefully this also demonstrates the problem a bit better than just plain text

https://gist.github.com/Kirill888/0861c2508d41766a0145682e330ff8f5

[alalek]

BTW, There is another experiment with resize: #9096

[andreaplanet]

Also warpAffine uses (-0.5,-0.5)-(0.5,0.5) as coordinates for the area and the missing documentation leads to errors (including OpenCV code) #11784. It is not intuitive, it's different than natural area coordinates used for vector/shape object for example.

[andy-held]

#22288 is good example for where this can lead to hard to detect and debug problems.

[bilzard]

@Kirill888 Thank you for opening this very fundamental topic.

For fillPoly(), it seems that (0, 0) is assumed to be located on center of pixel [1].
(Please point out if I missed something.)

I have established experimentally that 0,0 is the centre of the top-left pixels, at least as far as remap is concerned.

Does this mean this library's implicit specification of the alignment of (0, 0) pixel differs from function to function?

---

[1] https://www.kaggle.com/competitions/google-research-identify-contrails-reduce-global-warming/discussion/430749

[mynickmynick]

Can please anybody update about this issue? thank you very much