• Hardware Platform = Jetson and dGPU • DeepStream Version = 4.0.2 • TensorRT Version = 6 • NVIDIA GPU Driver Version = 440.82
I’m getting an issue with either the tracking or the post-processing of the object coords. Let me explain:
Primary inference sees the object as
Left: 100, Top: 50, Width: 200, Height: 200
This is cropped and passed to the secondary inference, which then detects another object within it’s own reference at:
Left: 50, Top: 25, Width: 100, Height: 100
The end result I get is:
Left: 50, Top: 25, Width: 100, Height: 100
The final result for the object should be:
Left: 150, Top: 75, Width: 100, Height: 100
This results in bounding boxes appearing at incorrect locations in the image and incorrect data.
I should note that the back-to-back detectors sample application does not experience this issue. The objects are positioned correctly in the OSD and examining the object metadata is good also.
Here is the pipeline output of the back-to-back detector:
I’ve evaluated the variables for the coords at just about every location. From inside the gst-nvinfer plugin to the all_bbox_generated method.
And yes I’ve added code to print out from the back to back detector sample, but it’s not necessary as the bbox’s are in the back to back sample (using my modified version of the gst-nvinfer as the second detector) works fine.
So the if statement “if (nvinfer->process_full_frame)” will always evaluate to true as both modes are a non-zero value, so it will always process in full frame mode.
If I throw in the following in front of line 1642 then it works as desired (in object only mode) as the if statement evaluates to false and calls “gst_nvinfer_process_objects”:
nvinfer->process_full_frame = 0;
However, I must be missing something since the back-to-back detector does seem to be working properly.
My custom application is based off of the deepstream-app example. So I’m also using the config parser within that sample. Maybe something isn’t being parsed correctly there?
Could you share your sgie config file with us?
In addition, if you want us to help check your modification, pls share the diff file with us instead of telling the number.
As for the line numbers, I was not sharing my modified version. I was referencing the original gst-nvinfer plugin code. Although the numbers may be off as I usually reformat the code with Jetbrains’ Clion.
Complete side note: I do this because I prefer:
void function () {
// do something
}
instead of:
void
funtion ()
{
// do something
}
As I find it neater and more compact. This is why the line numbers might not line up.
I didn’t get, is above logic executed?
BTW, are you thinking the value of process-mode the same as nvinfer->process_full_frame? obviously they are not the same thing, could you check the code again, nvinfer is open sourced.
does not execute. (I’m trying to be very explicit with what we are referring to, to avoid miscommunication).
BTW, are you thinking the value of process-mode the same as nvinfer->process_full_frame?
I understand they are different, but maybe where I’m confused is that I thought “process-mode” was what determines whether the SGIE operates on full frame or objects only. I actually tried looking for documentation on the config group settings for the [property] group, but I couldn’t find it. The closest thing I could find is a comment in the “secondary_detector_config.txt” from the back-to-back detector sample where it says “process-mode (Default=1 i.e. primary)”
So maybe a lot of what’s going on is some confusion with the settings. If so, can you please help clarify that for me?
Right now I have a working solution by forcing the value of “nvinfer->process_full_frame” to be 0 in my custom gst-nvinfer plugin. But naturally that’s not ideal.