Hi,
I’m using a Raspberry Pi CM4 with Picamera2 and Hailo for object detection. My pipeline uses the Picamera2 lores stream for inference and the main stream for streaming/recording. The issue is that Picamera2 lores currently outputs frames as YUV420, which is not directly compatible with my RGB-trained Hailo model. Right now I need to perform a CPU-side color conversion using OpenCV (cv2.cvtColor(..., cv2.COLOR_YUV2RGB)) before inference. On the CM4, this extra conversion increases CPU and memory bandwidth usage, which I would like to avoid for performance and efficiency reasons. I know Hailo supports some input conversions such as nv12_to_rgb during model compilation, so I’m wondering if there is any supported way to “bake” the YUV420 to RGB conversion inside the HEF/model itself.
Hi @dgarrido,
Yes, the Hailo Dataflow Compiler does support baking YUV-to-RGB conversion directly into the HEF so inference accepts raw YUV frames without CPU-side conversion. Since Picamera2’s YUV420 lores output is typically I420 (planar), you might try recompiling your model with the hybrid input conversion flag - if you’re using the Hailo Model Zoo, it could be as simple as hailomz compile <model_name> --hw-arch hailo8 --input-conversion i420_to_rgb which chains the format rearrangement and color conversion on-chip in a single step. If your lores stream happens to be NV12 (semi-planar) rather than I420, you’d use nv12_to_rgb instead. According to the DFC docs, an RGB calibration dataset should still work with these hybrid conversions, so you likely won’t need to regenerate your calibration set in YUV format. This does require access to the Dataflow Compiler to recompile - you can’t patch an existing pre-compiled HEF after the fact.
Please also see here: