Add default value for info argument of ClassDescription

[emilk]

• Closes face_tracking example fails with new AnnotationContext implementation #2924

Two changes:

• You can now easily specify the info without having to also specify label and color, using info=0.
• The default info is one with id=0, matching 0.7.0 behavior and how log_points work

(This took me over an hour to figure out 😭)

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested demo.rerun.io (if applicable)

• PR Build Summary
• Docs preview
• Examples preview

[Wumpf]

not acutally sure if the default value is a good idea. "Give a title to this class" becomes odd when one doesn't specify which class is meant - or am I missunderstanding the situation?

[emilk]

I don't know - AnnotationInfo is too complicated for my brain.

Where are you quoting from? I can't find "Give a title to this class" anywhere

[Wumpf]

Oh that's not a quote, that's more of my interpretation of what giving a setting an annotationinfo means

[emilk]

I don't like the implicit default value either. I think I'll merge this and cherry-pick for 0.8.1 (since it fixes a subtle 0.8.0 API regression) and then make a new PR to make info mandatory, making the user code more explicit and intentionally breaking the API

[jleibs]

Probably worth adding a comment to the generated docstring (in class_description.fbs) that if no info is provided, the default is 0.

The consequences of this really are that a line such as:

rr.ClassDescription(keypoint_connections=[(0, 1), (1, 2), (2, 0), (2, 3), (0, 4), (1, 5)])

Implicitly says to annotate keypoint_connections for keypoints that have a class_id of 0, which matches the behavior of log_points, which sets the class_id to 0 if you log keypoints without logging a class-id.

[jleibs]

This still strikes me as a bit of a footgun, but it matches the pre-existing behavior.

[emilk]

I'm gonna remove it in a follow-up-PR, but keep it here to not break API further in the 0.8.1 patch release

[jleibs]

If you want to break it in the future, why not break it now? Is there a meaningful difference between breaking it in 0.8 and breaking it in 0.9?

[emilk]

It's more that I want to do the least intrusive change for 0.8.1.

If we require info to be explicit, should we also make it explicit for log_points? Why require explicitness in one but not the other?

[jleibs]

Fair enough.