Child pages
  • OpenNI and PCL Recording Codes
Skip to end of metadata
Go to start of metadata

vona 7/20/13

BOTTOM LINE: there appear to be at least 8 ways to record live RGB+depth images from an OpenNI device to disk in OpenNI 1.x and PCL. However, if you want to record in real time without dropping data then your best bet is pcl_openni_image. It uses a circular buffer to avoid hiccups and saves in pclzf format which doesn't peg the cpu or the disk. At the time of this writing it did have some quirks (most notably lag in the visualizer) but it was usable.

Note about "synchronization": all codes that use the PCL OpenNIGrabber have software synchronization (pcl-trunk/common/include/pcl/common/synchronizer.h) to get a single timestamp for depth and rgb per frame. The timestamps used are 64-bit integer (microsecond?) values that percolate up from OpenNI. IDK whether these are actually hardware timestamps or whether they are host-based timestamps generated in the OpenNI middleware or driver. It does appear that the hardware transmits some kind of 32-bit timestamp with every image coming up the USB wire.

Apparently some OpenNI devices also implement lower level synchronization. The Kinect does not. Primesense reference devices are supposed to, but I'm not sure if that includes the Carmine or Xtion Pro. Also IDK whether the referred to "synchronization" is in terms of the depth and RGB camera shutters or the sequencing of data transmitted over USB; i.e. requesting "synchronization" could mean that extra effort is made to transmit corresponding depth/RGB image pairs with low relative latency, not that anything different is done to synchronize the shutters.

In PCL code the function openni_wrapper::OpenNIDevice::setSynchronization() seems to turn this lower-level synchronization on or off. It is always off by default. OpenNIGrabber::startSynchronization() is a red herring (unless you are writing a class that extends OpenNIGrabber) because it's protected and it is never called in the OpenNIGrabber code as of PCL SVN revision 8485 on 1/12/2013 because "it leads to inexplicable crashes".



  • writes compressed data to an oni file
  • uses about 4MB/s disk write bandwidth (iotop)
  • does not seem to explicitly buffer data
  • I did observe hiccups where roughly 1s of frames were dropped after about 30s of recording on my desktop machine
  • timestamps depth and rgb separately (no internal synchronization)


  • does record to a circular buffer in memory
  • but not designed for continuous streaming
  • no live preview
  • timestamps depth and rgb separately (no internal synchronization)



  • pcl-trunk/visualization/tools/openni_image.cpp
  • saves pclzf frames ~400k/frame, ~12MB/s disk write bandwidth (iotop)
  • uses a boost circular buffer of depth/rgb image pairs, defaults to use half available memory (I suggest argument -buf 200 instead)
  • maintains full framerate on my desktop machine and a laptop
  • includes live preview
  • also saves an xml for each frame
  • for some reason also buffers frames just for visualization, can cause visual lag, uses same amount of memory as write buffer
  • for some reason uses a producer thread ("Driver") that mostly does nothing


  • pcl-trunk/io/tools/openni_pcd_recorder.cpp
  • saves binary compressed PCDs, ~1.8M/frame, ~50MB/s disk write bandwidth (iotop)
  • uses a boost circular buffer of clouds, default size fills available memory
  • does not seem to be able to keep up with full framerate on my desktop machine, queue size seems go keep growing
  • probably disk bound
  • no live preview


  • pcl-trunk/gpu/kinfu_large_scale/tools/record_maps_rgb.cpp
  • no live preview
  • saves PNGs with pcl::io::saveRgbPNGFile, pcl::io::saveShortPNGFile which use vtk
  • uses a boost circular buffer of 1000 depth/rgb image pairs
  • only manages about 17FPS on my desktop machine, seems CPU bound
  • spawns three consumer threads to compress and write data, but they all seem to peg one of the four cores on my machine
  • uses only about 3MB/s disk write bandwidth per consumer thread (9MB/s total)
  • starts dropping a lot of frames (of course) after the buffer fills, takes some 10s of seconds


  • pcl-trunk/apps/src/openni_organized_compression.cpp
  • writes compressed organized pointclouds to ".pcc" file
  • uses about 4MB/s disk write bandwidth
  • don't see any explicit buffering, not sure about hiccups
  • uses libpng to compress rgb and depth maps to a single file
  • does not explicitly report framerate, but size of saved data divided by runtime indicates only about 10FPS
  • probably CPU bound, seems to peg one core, which is probably the writer thread


  • not built by default
  • saves tiff images using vtk
  • no buffering
  • has live preview
  • not tested


  • not built by default
  • saves binary, binary compressed, or ascii pcds
  • no buffering
  • has live preview
  • not tested
  • No labels