You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Documentation regarding the exported YOLOv9 ONNX model #973
I am currently in the process of training my own YOLOv9 model on a custom dataset. The environment i pan to use this model tho does not support python, so i plan to export the trained model to ONNX and run it in the plan ONNXRuntime. Getting this to work i need to write my own special Encoder/Decoder, since i can not rely on this library's implementation. For this i need to know the layout (format) of the input and output layers.
I found the documentation of the resulting output layer shape and what each number represents here (its [batch_sitze, max_predictions, results] where results are encoded as [x1, y1, x2, y2, confidence, object_class]). However is struggle to comprehend the input side of things. When i inspect the resulting input shape i get: [batch_sitze, num_channels, image_size, image_size]. While i could pinpoint the patch and channel order (its channels first) based on the numbers, i struggle to find:
Color Format: The input uses 3 channels. But in what order does it expect these 3 channels to be. Is it using the common RGB format or is it using the typical OpenCV BGR format?
Image Orientation: Even if the input dimensionality seems to be square (640x640) it is still a question how the X and Y dimensions are laid out respectively. Commonly used it the [width_X, height_Y] format, but again OpenCV likes to turn things on there heads by using the height as first dimension [height_Y, width_X]. How is this handled in the LibreYOLO implementation?
I would appreciate id someone who is familiar with the code or architecture can answer me this. Tanks a lot in advance!
It now covers the core models. I wrote it with AI help.
But to answer your questions quickly:
Colors are RGB
The input is batch, channels, height, width, so height comes before width.
Pixel values are divided by 255, with no other normalization.
Images are letterboxed: resized keeping the aspect ratio and padded with gray (114). The padding goes either on the right and bottom, or split evenly on both sides. Which one your model uses is written in the ONNX file's metadata, under letterbox_pad.
Hope this helps, and let me know if anything doesn't match what you see :)
Thank you for the clarification. I suspected a [batch, channels_RGB, height_Y, width_X] format of the input tensor after some long trial and error yesterday, because it was the only format which produced readable results. But again, nice from you to confirm this to me. Pixel
Images are letterboxed: resized keeping the aspect ratio [...]
This is new to me. I wrote the encoder for the exported ONNX model in C++ using the Lanczos4 algorithm for scaling the image to the input dimensions, essentially squeezing or stretching the image until it fits. I did not notice any degradation in prediction quality using this over the letter boxing variant. however i will rewrite the encoder using letterboxed scaling with the padding value of [114, 114, 114]. I was able to extract the letterbox_pad from the ONNX artifact, so i might handle this programmatically.
However thanks for pointing this out. You can consider this issue solved. 😄
Activity
EHxuban11 commentedon Nov 1, 2026
Hello @isja-krass,
Thank you for your question and for the detail. Following your issue I took the opportunity to improve the documentation and now it has much more detail : https://www.libreyolo.com/docs/models/yolov9#onnx-inputs-and-outputs
It now covers the core models. I wrote it with AI help.
But to answer your questions quickly:
Hope this helps, and let me know if anything doesn't match what you see :)
isja-krass commentedon Nov 2, 2026
Thank you for the clarification. I suspected a
[batch, channels_RGB, height_Y, width_X]format of the input tensor after some long trial and error yesterday, because it was the only format which produced readable results. But again, nice from you to confirm this to me. PixelThis is new to me. I wrote the encoder for the exported ONNX model in C++ using the Lanczos4 algorithm for scaling the image to the input dimensions, essentially squeezing or stretching the image until it fits. I did not notice any degradation in prediction quality using this over the letter boxing variant. however i will rewrite the encoder using letterboxed scaling with the padding value of
[114, 114, 114]. I was able to extract theletterbox_padfrom the ONNX artifact, so i might handle this programmatically.However thanks for pointing this out. You can consider this issue solved. 😄
EHxuban11 commentedon Nov 3, 2026
Hello @isja-krass ,
Happy to hear that it works now, if you need anything else or have other improvements for the library don't hesitate to open other issues !