Where is the system origin for the principal point of a camera?

In the example given in the documentation for the function cameraIntrinsics for the image size [480, 640] principal point is located at [320, 240]. On the other hand, the documentation states that 'the pixel coordinates used in Computer Vision Toolbox™ software are one-based, consistent with the pixel coordinates used by Image Processing Toolbox™ and MATLAB®'. So the principal point should be located at [320.5, 240.5]. Which variant is correct if it is known that the principal point should be located at the center of the image?

Answer 1

[Image Analyst]

Well neither is correct since you swapped rows and columns from [480, 640] to when you were talking about [320, 240] and [320.5 and 240.5]. The center of the image is at (240.5, 320.5). Of course this is midway between a patch of 4 pixels at the center of the image so if you want the intensity there you can either interpolate it's value or use indexing once you've rounded the coordinates either up or down. So if you're indexing you can essentially take whichever of the 4 surrounding integer pixel locations that you want.

[Aleksei Pushtaev]

Thank you very much for your reply.

When denoting the image size and coordinates of the principal point, I used the format that is used for the arguments of the cameraIntrinsics function - [mrows ncols] and [cx cy], so there is no mistake here.

The essence of my question is not that in the case of fractional coordinates of the center, it will be problematic for me to determine the intensity value. The exact definition of the center is important for me in connection with determining the exact position of the camera in space, because functions like worldCameraPose use camera parameters as source data.

For a specific physical camera, a calibration procedure can be used, although with the modern precision of camera manufacturing in most cases, I think it is logical to say that the principal point is located exactly in the geometric center of the photosensitive matrix ([320.5, 240.5] in the example given, or as you wrote - (240.5, 320.5)).

For a virtual camera that strictly implements a simple central projection, it is also logical that the principal point should be located in the center of the frame. To test this, I wrote a script that simulates the calibration procedure using a checkerboard image for a camera presented as an OpenGL graphics rendering engine built into MatLab (Axes graphics object). I got that for an image of size [480, 640] for 7 different angles of the checkerboard pattern, the coordinates of the principal point are [319.86, 239.97], i.e. they are closer to the value [320, 240], and not [320.5, 240.5]. In addition, as I wrote, the same value is used in the help documentation in the example to the cameraIntrinsics function. Thus, the question arose – is this a bug in the estimateCameraParameters function or is the principal point really not in the center of the image?

[Image Analyst]

Maybe it's just a convention/feature that they're using because they need integer coordinates because they're to be used as indexes into a matrix. Maybe they can't use floating point coordinates for some reason.

There's always this concept of whether pixels are points, or small square patches corresponding to IFOVs (instantaneous field of view) on the scene. For example, regionprops returns the bounding box as half a pixel outside the pixel coordinates because they're considering the pixels as squares with finite width and they want the bounding box to lie completely outside the little squares. Sometimes this causes problems if you want to crop the image by indexing so I wish they'd give us the option of having "on pixel" integer coordinates or "surrounding the pixel" floating point coordinates half a pixel outside the pixels.

Anyway, if you're interested in why they're doing it that way, contact tech support and they'll escalate it to the computer vision team and get back to you with an answer.

[Aleksei Pushtaev]

Thanks for the explanation.