Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#151 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@theluckystrike ya está trabajando en esto.

Desde el 17/10/2026.

  • #155 de @theluckystrike — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
python
Área
backend, computer-vision

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
224
Forks
31
Merge medio
1 d 20 h
PR fusionados (30 d)
28

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de petercorke/machinevision-toolbox-python

Todos los issues de petercorke/machinevision-toolbox-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.