Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#151 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@theluckystrike ci sta già lavorando.

Dal 17/10/2026.

  • #155 di @theluckystrike — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
python
Ambito
backend, computer-vision

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
224
Fork
31
Merge medio
1g 20h
PR unite (30g)
28

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di petercorke/machinevision-toolbox-python

Tutte le issue di petercorke/machinevision-toolbox-python

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.