[G-API]: Performance tests for BackgroundSubtractor#19542
[G-API]: Performance tests for BackgroundSubtractor#19542alalek merged 7 commits intoopencv:masterfrom
Conversation
|
@anna-khakimova please review |
alalek
left a comment
There was a problem hiding this comment.
Please take a look on existed OpenCV performance tests for this functionality first.
| // Processing `testNumFrames` amount of frames without measurements: | ||
| while (frames++ <= testNumFrames && cap.grab()) | ||
| { | ||
| cap.retrieve(frame); | ||
| c.apply(frame, gapiForeground); | ||
| pOCVBackSub->apply(frame, ocvForeground, learningRate); | ||
| EXPECT_TRUE(cmpF(gapiForeground, ocvForeground)); | ||
| } |
There was a problem hiding this comment.
Accuracy checks must be removed from the performance tests. Use accuracy tests for that.
"OCV" code must gone from all perf tests.
There was a problem hiding this comment.
Yes, a lot of comparison was excess; comparison was removed from the cycle.
However, by design of G-API performance tests, it is necessary to be sure the kernel is working properly while measuring the performance.
It's really not my call to change it in this PR.
I left a single comparison for the validation.
| // ...and then measuring the G-API subtractor performance on the single frame | ||
| TEST_CYCLE() | ||
| { | ||
| c.apply(frame, gapiForeground); |
There was a problem hiding this comment.
Is c stateless?
- if yes, the just 1 frame is not enough (code measures "initialization" code which doesn't make sense)
- if no, then it is just wrong. Performance samples must measure the same code.
There was a problem hiding this comment.
You are right, thanks! The measuring was refactored and now a performance of the kernel on a sequence of the same n frames (with resetting the state between iterations) is measured.
|
Looks good for me. |
| frames.push_back(frame); | ||
| } | ||
| } | ||
| testNumFrames = frames.size(); |
There was a problem hiding this comment.
Another change of value, it is curiously. testNumFrames = warm_up_frames + perf_test_work_frames, is it?
There was a problem hiding this comment.
This line is to avoid termination in case the video has less frames than it was required. So at this point testNumFrames is the real number of frames read
There was a problem hiding this comment.
This variable independent of test parameter. What if read() returns false (some problem) and we receive part of frames? Is it correct behavior for this case?
There was a problem hiding this comment.
Yes, exactly, this line handles the case when, for example, a video is too short and there are not enough frames. If so, I decided that the expected behaviour would be to process the obtainable amount of frames.
In the case when everything is all right the variable wouldn't change
There was a problem hiding this comment.
I hope "everything isn't right" case doesn't relate to this test and this step is just in case.
There was a problem hiding this comment.
What if frames.size() is zero?
There was a problem hiding this comment.
Yes, absolutely, this step is just in case.
If size is 0.. it's extremely unlikely, as video should have no frames despite the fact it have been read successfully.
But if it actually happened, nothing would be processed, so output Mats would remain empty. And then validation either would or would not pass. Which is not the expected behaviour
I'll add assert to have speakable error
There was a problem hiding this comment.
Assertion check must be here.
We can't have "flexible" scope for performance sampling. Test code must be fixed instead if error occurs.
There was a problem hiding this comment.
I see. Added termination in case frames.size() is not testNumFrames after reading instead of re-assignment
|
@alalek Are the Jenkins builds important to be green for merging? |
|
Jenkins builders are optional for now (there are several infrastructure issues not related to any patch) |
|
@alalek please check if this is mergeable |
[G-API]: Performance tests for BackgroundSubtractor * Perf.Tests for BackgroundSubtractor kernel * Fix CI * Addressing comments * Addressing a comment * Test cycle and validation changes * Addressing comment * Added assert
Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
Patch to opencv_extra has the same branch name.