Handle empty ROS2 camera frame_id without panicking

[Woodii1998]

Related

Closes #12718

What

Empty header.frame_id in ROS2 camera messages caused a TransformForest panic due to self-referential pinhole topology. At the MCAP parser level, empty frame IDs now trigger a graceful downgrade: CameraInfo import is skipped entirely, while Image and CompressedImage fall back to plain 2D import without spatial metadata. As a defense-in-depth measure, TransformForest now also ignores self-referential pinhole projections instead of panicking.

[MichaelGrupp]

I think this should be handled on re_tf level instead of MCAP workarounds. An empty string can also come from elsewhere (ping @Wumpf: let me know if you agree). I'm a bit surprised that we are panicking, need to reproduce this myself (next week). Last time I looked into empty frame IDs was for 0e66bc0

[oxkitsune]

Related: There's #12663 that also solves this on the TF level

[Woodii1998]

I think this should be handled on re_tf level instead of MCAP workarounds. An empty string can also come from elsewhere (ping @Wumpf: let me know if you agree). I'm a bit surprised that we are panicking, need to reproduce this myself (next week). Last time I looked into empty frame IDs was for 0e66bc0

I agree with handling this in re_tf so that empty frame ids can never panic the transform system, regardless of the source.

But I think #12663 goes a bit too far: it does not just make the system robust, it reinterprets empty frame ids as implicit/entity-derived frames. That changes the meaning of the data.

For example, if a camera topic has frame_id = "", I would rather treat that as missing spatial metadata and degrade it to plain 2D import. Under #12663, it instead starts behaving like a valid implicit frame, which hides the fact that the original frame metadata was missing.

So my preference would be:

re_tf handles robustness globally;
importers keep schema-specific fallback behavior where missing frame metadata has a well-defined meaning.