Protobuf format

Software Image Database Project
1

Hey Everyone,

let’s discuss and specify the protobuf format for the metadata and the tags here.
The current state will be at (it is edibility by everyone, you are welcome to edit it):

https://ep.mafiasi.de/p/robocup-protobuf

Greetings,
Fabian

2

I made a first draft for possible MetaDatas.
I did not include a custom team field yet.

3

thx. looks good! i’ve added some fields for labels of objects (could be used for machine learning):
balls,goalPosts,robots,lineCrosses,ownFeet

4

what type of camera matrix you guys like to use?
3x4 Matrix?
3x3 Homography?

(just asking because we do not use any camera matrix at the moment)

5

I can’t answer your question at the moment.
But I have another one: would it be better, if we add object_type to the Box2D so we can say what is inside the box? And then use only one field for objects instead of multiple ones?

6

A camera matrix is basically a 3x3 rotation matrix plus a 3d position vector, i.e. it could be written as a 4x4 matrix where the last row has the elements 0, 0, 0, 1.
Personally, I would prefer separating them as rotation matrix plus position vector.
In our code, the camera matrix does only specify the extrinsic calibration of the camera, for internal calibration we use focal length and principal point of the camera without writing them in a matrix.

7

ok, nice idea to use only one repeated field for the labels with the object_type in the box2d. i changed the protobuf format a little bit and added another type for a label (POINT, LINE, BOX). does is make sense for you?

8

is the positiion vector in the cameramatrix different from the position on the field?

9

what do you mean by the z field of the position? rotation angle or robot height?
maybe it’s better to use a “Position{x,y,theta}” or something like that?

10

The position vector in the camera matrix is the position of the camera relative to the point on the ground that is below the robots torso. So it would generally have a small x coordinate (a few centimeters), a y coordinate of 0 and a z coordinate of about 45cm (depending on the camera).

So obviously we have both {,dis}advantages with saving camera matrices or joint angles:
Joint angles are always available, they do not contain any extrinsic camera calibration parameters (which might be needed to make them really usable), whereas a camera matrix would include these, but camera matrices could be relative to different coordinate systems used by different teams (or not be provided at all by some teams).

11

We can name the entries of the vectors with something like x1, x2 and x3 and then define the meanings in comments or something like that. The z entrie was meant to be the angle. But we could also use a second type for that. I don’t know what is the besser (perhaps easier) approach in here.

But you are right we have to define the coordinate roots. We also need one for the images if we want to use the labels.
For the field position we should use the SPL standard. I would vote for the image coordinates to be located a the left top edge, or have anyone other opinions on that?

12

I agree with you (TopLeft Image Coordinates, SPL Standard for Coordinate System, meanings as comments like in the spl standard message header)

i also started a new discussion about the labels and if its really a good idea to include them into our protobuf: How to label images and how to save the labels