Skip to main content
Output tensors produced by inference models typically require post-processing to render results usable for downstream components or interpretable by applications. For instance:
  • Classification outputs are arrays of confidence scores that must be interpreted, such as by selecting the top classes exceeding a specified threshold.
  • Raw tensor data may need conversion into formats expected by subsequent plugins or processing stages.
Post-processing ensures that output data is appropriately structured, filtered, and formatted for purposes such as visualization, logging, or further inference. Within the QIM SDK, the qtimlpostprocess plugin manages post-processing tasks. This plugin converts raw model outputs into GStreamer ML metadata, which may include:
  • Label strings (e.g., “cat”, “car”, “person”)
  • Confidence scores
  • Color information (for visualization overlays)
  • Bounding boxes
  • Key points and their connections
  • Segmentation masks
  • Tensors (for cases where subsequent AI stages require modified outputs from previous models)
This metadata facilitates display, logging, and decision-making in downstream components. Given the diversity of model architectures and output tensor types, each requires specific logic to interpret and convert raw data into meaningful results. To accommodate this, parsing logic is not embedded directly within the plugin; instead, it is provided as loadable modules tailored to individual models. Postprocess sample diagram with mobile-softmax module Each post-processing module implements parsing logic tailored to a specific class of models. For example, dedicated modules are available for MobileNet, YOLOv5, YOLOv8, and others. The QIM SDK provides a comprehensive set of modules supporting object detection, image classification, semantic segmentation, super resolution, audio classification and pose estimation models. The list of supported post-processing modules:
  • mobilenet-softmax
  • mobilenet
  • ocr-recognizer
  • ocr
  • qfr-softmax
  • qfr
  • easy-textdt
  • easy-ocr-detector
  • mediapipe-pose
  • qfd
  • qpd
  • ssd-mobilenet
  • yolo-nas
  • yolov5
  • yolov8
  • palmd
  • deeplab-argmax
  • yolov8-seg
  • midas-v2
  • hrnet
  • lite-3dmm
  • posenet
  • hlandmark
  • mediapipe-pose-landmark
  • srnet
  • wave2vec
  • yamnet
  • tensor
The supported models for all the above categories can be found in the Supported Models section. You can also list all available modules on device by running:
If a suitable pre-integrated module is not available for a particular model, developers can create custom modules and load them into the pipeline. These custom modules encapsulate model-specific parsing logic and can be adapted to handle unique tensor formats or specialized post-processing requirements. The module interface is implemented in pure C++ without dependencies on GStreamer or GLib, resulting in a lightweight and easily integrable solution. To develop a custom module, only the interface header file supplied by the QIM SDK and an ARM64-compatible compiler are required. Please refer to the custom postprocessing plugin page for more details.

​
Plugin Configuration Options

The qtimlpostprocess plugin offers several configuration options to control how model outputs are interpreted and prepared for downstream use:
  • Module: Specifies the post-processing module to load. Each module contains parsing logic for a particular model class (e.g., classification, object detection, segmentation). The actual interpretation of the output tensor occurs within the selected module.
  • Labels File: Path to a file containing class labels. Supported formats include:
    • Newline-separated labels (commonly used in the ML community)
    • JSON format (supports additional metadata such as display color and class filtering)
    The QIM SDK includes a built-in parser capable of auto-detecting these formats.
  • Settings: A JSON object containing module-specific configuration parameters. These settings vary by model type. An example could be confidence_threshold which is applicable to classification and detection models.
  • Results: Specifies the maximum number of results to return. This option is useful for limiting the number of top predictions in classification scenarios and ensuring compatibility with downstream plugins that may only support a fixed number of results.
The diagram below shows the AI pipeline used in this example — face detection with bounding box overlay: Image of AI pipeline using face detection The decoded video frames pass through qtimlvconverter (preprocessing) and qtimltflite (inference), then into qtimlpostprocess, which parses the output tensors and produces GStreamer ML metadata containing bounding boxes and confidence scores. The qtivoverlay plugin then renders those results directly onto the video frames for display.

​
Run example on device

1

Download Required Files

If any downloaded file is a .zip archive, extract it on your host machine before copying: unzip filename.zip
2

Copy files to device

Create the required directories and transfer the downloaded files to your device.
3

Connect to device

4

Set environment variables

5

Run example on device

​
External postprocessing

The pre-integrated modules cover the most common model families. However, when you have a model whose output tensors are not handled by any existing module — a custom architecture, an experimental head, or a proprietary decoding scheme — you can parse the raw tensors directly in your application instead of writing a loadable C++ module. qtimlpostprocess exposes a set of process-* signals that hand the inference output tensors to a callback in your application, which then produces the ML results (detections, classifications, poses, segmentations, depth maps) or writes new output tensors. Unlike a loadable module, this path keeps the parsing logic inside your own application process — convenient for prototyping, for logic that depends on application state, or when you prefer Python over a compiled module. It is engaged by leaving the module property unset and connecting a handler to the process-* signal that matches your model.
The full list of signals, the result-structure field reference, and complete C/C++ and Python examples are documented in Guidelines for Writing an External Post-Processing Callback.