Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

ROSBag: RealSense bags have a 4-byte depth-units trailer that is guessed, not parsed

Ouverte
  • Quelque chose ne va pas ?
#151 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@theluckystrike y travaille déjà.

Depuis le 17/10/2026.

  • #155 par @theluckystrike — ouverte

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
python
Domaine
backend, computer-vision

Piste de recherche

Start with ROSBag._autodetect_typestore and the __iter__ trim logic in src/machinevisiontoolbox/Sources.py, then inspect tests/create_ros_fixture.py and the existing ROS bag tests. First reproduce the suspected data loss with Intel’s single_depth_color_640x480.bag, which should be checked before changing parsing. Done means image trailers are parsed without trimming valid bytes, depth units are preserved and handled as specified, and fixtures cover bags with and without trailers; the open pull request #155 indicates work is already underway.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug help wanted

ROSBag can mis-read bag files recorded with the Intel RealSense SDK (librealsense). RealSense appends 4 extra bytes to every sensor_msgs/Image message, which the current code handles by guessing a fixed number of trailing bytes to strip.

What we found

Investigated by parsing real bags directly, outside rosbags:

  • In a 1280x720 bag recorded with librealsense, every sensor_msgs/Image message has exactly 4 bytes after the valid message. For color frames the trailer is 00000000. For depth frames it is the float32 0.001 (bytes 6f 12 83 3a), the RealSense depth unit in metres per count. It matches the bag's own .../option/Depth_Units/value topic, and librealsense's writer (ros_writer.cpp, write_video_frame) deliberately appends a depth_units float to a modified sensor_msgs::Image. So the trailer is real metadata, not junk, and we currently throw it away.
  • For both image types, step == width * bytes_per_pixel, the data array length is height * step, and the message length is end_of_array + 4. The extra bytes sit entirely after the array, so row padding does not explain them.
  • Intel's own sample bag single_depth_color_640x480.bag (which also contains realsense_msgs/StreamInfo) has 0 extra bytes. But _is_realsense is true for it, so the fixed trim_order=(4,) in ROSBag._autodetect_typestore would chop 4 real bytes from each message. We have not verified this (rosbags was not installed in the environment used); it should be the first regression test.

Where

ROSBag._autodetect_typestore and the __iter__ code that applies self._trim_bytes, in src/machinevisiontoolbox/Sources.py.

Proposed fix

  • Add RealSense-style fixtures (with and without the trailer) to tests/create_ros_fixture.py, plus a regression test for the 0-extra-bytes sample bag.
  • For Image / CompressedImage, parse the fixed message layout by hand up to the data array (header, height, width, encoding, is_bigendian, step, array length prefix n), set end = position + 4 + n, treat raw[end:] as the footer, check n == height * step, and hand only raw[:end] to the type store. No probing, no global _trim_bytes, and it works whether a bag has 0 or 4 trailing bytes. Keep the existing 0/4/8 probe only as a fallback for other message types.
  • Keep a 4-byte footer as a float32 depth_units on the sample (depth only; color is 0.0) instead of discarding it.
  • Also check non-image connections (StreamInfo, CameraInfo) for trailers; not yet checked.

Depth units API (design agreed in principle, open to discussion)

New arguments ROSBag(..., depth_units=None | "auto" | float, invalid_is_nan=True), where depth_units is metres per unit (the librealsense convention; note this is the reciprocal of Open3D's and TUM RGB-D's units-per-metre depth_scale, so document the 1000 / 5000 mapping).

Sources of the scale, in order of precedence: a user-supplied float, then the per-message footer, then the bag's .../option/Depth_Units/value topic if recorded, then the scale implied by the encoding under REP 118 (16UC1 = millimetres = 0.001; 32FC1 = already metres), then unknown.

  • Default (None): native dtype (uint16) returned unchanged, with the best-known scale attached to the sample as depth_units metadata.
  • "auto" or a float: convert to float32 metres; where the result is float and invalid_is_nan is true (the default), raw 0 becomes NaN. 32FC1 input is already metres, so a user scale acts as a gain.
  • The dtype never silently depends on which SDK recorded the bag.

Also use logging rather than print in this code path. Part of the wider clean-up in the Sources.py tracking issue linked in the checklist at the end.

Tracking issue for the rest of the file: #150.

Langage dominant
Python
Étoiles
224
Forks
31
Merge moyen
1 j 20 h
PR mergées (30 j)
28

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de petercorke/machinevision-toolbox-python

Toutes les issues de petercorke/machinevision-toolbox-python

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.