Conversation
651280a to
ce4267f
Compare
|
Various build issues in the last build.. Also failures detected |
6e25e93 to
50a7c5e
Compare
50a7c5e to
4521894
Compare
TolyaTalamanov
left a comment
There was a problem hiding this comment.
The changes looks good but invasive. I'm not sure that OpaqueKind was ever designed to contain such specific detail as TrackingStatus.
Perhaps we can avoid exposing TrackingStatus into python and just use int instead. For improving readability we still can define TrackingStatus enum but on python side (__init__.py) and use it like that:
rois, labels, ids, status = cv.gapi.ot.track(img, rect, labels, delta)
if status == TrackingStatus.NEW.value:
pass
In that case the status is int but you may compare it with enum:
class TrackingStatus(Enum):
NEW = 1,
TRACKED = 2,
LOST = 3
| #include <opencv2/gapi/garg.hpp> | ||
| #include <opencv2/gapi/gopaque.hpp> | ||
| #include <opencv2/gapi/render/render_types.hpp> // Prim | ||
| #include <opencv2/gapi/ot_tracking_status.hpp> // TrackingStatus |
There was a problem hiding this comment.
Should it be just a part of ot.hpp?
There was a problem hiding this comment.
It couldn't be that time, as was included in gcommon.hpp. Now, it is removed from gcommon,hpp and returned back to ot.hpp
Need to discuss this, since it's not the better solution and in some extent even worse :) |
|
|
||
| cv.gapi.wip.GStreamerPipeline = cv.gapi_wip_gst_GStreamerPipeline | ||
|
|
||
| class TrackingStatus: |
There was a problem hiding this comment.
(Optional)
What type is used for NEW, LOST, TRACKED? I assume int, will there be just 0,1,2 when we print it into console?
Perhaps we can leverage python enum module to improve that.
TolyaTalamanov
left a comment
There was a problem hiding this comment.
@AsyaPronina Could you add a couple of python test cases, please?
| return is >> l.color >> l.lt >> l.pt1 >> l.pt2 >> l.shift >> l.thick; | ||
| } | ||
|
|
||
| IIStream& operator>> (IIStream& is, cv::gapi::ot::TrackingStatus& status) { |
There was a problem hiding this comment.
Why not just static_cast<int>?
| CV_SCALAR, // cv::Scalar user G-API data | ||
| CV_MAT, // cv::Mat user G-API data | ||
| CV_DRAW_PRIM, // cv::gapi::wip::draw::Prim user G-API data | ||
| CV_OT_TRACKING_STATUS // cv::gapi::ot::TrackingStatus user G-API data |
There was a problem hiding this comment.
I doubt if we need to know about this type at the Opaque level.
| #include <opencv2/gapi/garg.hpp> | ||
| #include <opencv2/gapi/gopaque.hpp> | ||
| #include <opencv2/gapi/render/render_types.hpp> // Prim | ||
| #include <opencv2/gapi/ot_tracking_status.hpp> // TrackingStatus |
| return is >> l.color >> l.lt >> l.pt1 >> l.pt2 >> l.shift >> l.thick; | ||
| } | ||
|
|
||
| IIStream& operator>> (IIStream& is, cv::gapi::ot::TrackingStatus& status) { |
| std::string statusStr; | ||
| is >> statusStr; | ||
| status = cv::gapi::ot::from_string(statusStr); | ||
| return is; |
There was a problem hiding this comment.
Please don't do this. It is binary serialization, no the formatted input/output
| GAPI_EXPORTS IOStream& operator<< (IOStream& os, const cv::gapi::ot::TrackingStatus& status); | ||
| GAPI_EXPORTS IIStream& operator>> (IIStream& is, cv::gapi::ot::TrackingStatus& status); |
There was a problem hiding this comment.
Is it required now for status? I believe s11n can be omitted for the tracking status.
| reference_trackings_tr_ids[frame_no].push_back(int(fn_tracked_box["tracking_id"])); | ||
| reference_trackings_tr_statuses[frame_no].push_back( | ||
| from_string(fn_tracked_box["tracking_status"])); | ||
| cv::gapi::ot::from_string(fn_tracked_box["tracking_status"])); |
There was a problem hiding this comment.
it shouldn't be an API function.
| return false; | ||
| return value != (uint64_t)-1 || !PyErr_Occurred(); | ||
| } | ||
| }; |
1a52653 to
bf5c877
Compare
Fixed! |
Fixed! |
ab17bed to
87b6096
Compare
TolyaTalamanov
left a comment
There was a problem hiding this comment.
Great! Looks much better and less invasive. There a couple of thoughts how it can be improved:
- Do we really need to use
uint64_tas return value forot::track? Can we just useint? - Since both
int64_tanduint64_tare used only as return values we don't need to expose them into pythonGArray&GOpaquetypes. (e.gcv.GArray.Int64()- never used)
| * | ||
| * Tracking status twin for vas::ot::TrackingStatus | ||
| */ | ||
| enum class TrackingStatus: int32_t |
There was a problem hiding this comment.
It looked fine, why we decided to change this?
There was a problem hiding this comment.
to be automatically convertable to int
| def test_skip(): | ||
| pass | ||
|
|
||
| pass |
There was a problem hiding this comment.
Why this one is needed there?
| float delta); | ||
| GAPI_EXPORTS_W std::tuple<cv::GArray<cv::Rect>, | ||
| cv::GArray<int>, | ||
| cv::GArray<uint64_t>, |
There was a problem hiding this comment.
I actually doubt if we even need uint64_t there...
There was a problem hiding this comment.
This is what inner VAS function operates with. I don't think that reinterpret_cast or copying are the best options to deal with it to return another type.
| def __new__(self): | ||
| return cv.GOpaqueT(cv.gapi.CV_INT) | ||
|
|
||
| class Int64(): |
There was a problem hiding this comment.
I don't see any usage of both Int64() and UInt64() propose to remove this unless it's really needed
There was a problem hiding this comment.
One of the return types of OT I guess.
There was a problem hiding this comment.
UInt64 will be used if we want to create custom kernel in python and accept output from track operation.
| type2str = { | ||
| cv.gapi.CV_BOOL: 'cv.gapi.CV_BOOL' , | ||
| cv.gapi.CV_INT: 'cv.gapi.CV_INT' , | ||
| cv.gapi.CV_INT64: 'cv.gapi.CV_INT64' , |
There was a problem hiding this comment.
Where do we use int64_t? I can only see uint64_t
There was a problem hiding this comment.
It was exposed in the bindings already. I decided to just add it here also.
| GAPI_EXPORTS_W std::tuple<cv::GArray<cv::Rect>, | ||
| cv::GArray<int>, | ||
| cv::GArray<uint64_t>, | ||
| cv::GArray<int>> track(const cv::GMat& mat, |
There was a problem hiding this comment.
minor: please put track() on a new line after its monstrous return value type
| def __new__(self): | ||
| return cv.GOpaqueT(cv.gapi.CV_INT) | ||
|
|
||
| class Int64(): |
There was a problem hiding this comment.
One of the return types of OT I guess.
| def test_skip(): | ||
| pass | ||
|
|
||
| pass |
| res = comp.apply(cv.gin(in_image, in_rects, in_rects_cls), | ||
| args=cv.gapi.compile_args(cv.gapi.ot.cpu.kernels())) |
There was a problem hiding this comment.
Should the output be tested somehow? How the LOST/NEW/TRACK status look in Python now?
be67f3c to
9911ac9
Compare
|
Hello Dear Alexander (@asmorkalov), Dear Alexander (@opencv-alalek), Dear Maksim (@mshabunin), could you please merge this PR? |
|
@asmorkalov @mshabunin can we merge it today pretty please? |
9911ac9 to
d20727a
Compare
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.