Closed rolfvdhulst closed 4 years ago
It should be doable, but it is not just a one-liner, because the image size is never stored as a parameter.
I do not quite get your intention, though. How would you like to use the image dimensions? Btw, you already have the principal point, which should be approximately the center of the image.
The image dimensions are useful in multiple scenario's. Essentially it comes down to the fact that especially for the ball, not observing on a frame the ball is also significant information about it's whereabouts (which we would like to use).
For example, if the ball is chipped, it may sometimes appear on one camera first moving towards another camera. If we have a model which estimates the position of the ball, we can then validate our fitted chip model by checking if it should indeed NOT be visible on other cameras, for which we need the image coordinates to check if the projection of the ball onto the camera indeed falls outside of the image frame.
Similarly, it is also useful to determine if it's likely that the ball is being occluded because of a robot, or because it left the observed image frame of a camera.
For both of these, we need the image dimensions (at least roughly). We would prefer not to rely on the principal point, as it tends to vary depending on field calibration.
I am also willing to (attempt to) implement this and make a pull request. Felt it is useful to first check if you would agree with changing the protobuf definitions and updating the code for this, though.
I see. It would be great if you could create a PR for it. Let me know if you have any questions.
Since there is no direct connection between the geometry information and the frame detection information anywhere within the code as far as I can tell, would you agree creating a new plugin that keeps track of the image sizes of each camera (and in the future, perhaps other image information / camera parameters if necessary as well) would work the best? The other alternative would be to send the image size with every DetectionFrame (which would be very easy to implement), but that seems to me like a lot of unnecessary network overhead.
It should be added to the protobuf message SSL_GeometryData
somewhere, not to the detection frame.
The geometry data is published in PluginPublishGeometry
, which might be a suitable plugin to use.
Creating a new plugin would be another option. It could write the image dimension to CameraParameters
, which is used to create the geometry message.
I would try to include it the PluginPublishGeometry
first.
See #176. I did not use PluginPublishGeometry but the CameraCalibrationPlugin instead, which was much cleaner as it's not a global plugin but works on a per-camera basis.
Right now, the camera image dimensions are not a part of the SSL_GeometryCameraCalibration. I would like to request that this becomes the case, as such it is then easier to reconstruct if a given ball is within's a camera's view / projects onto the images of the camera . As far as I am aware, it should be relatively simple to obtain this information and store it in the relevant classes.