-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add opencv compatibility library #1932
Conversation
I guess this is part of what |
Regarding the BGR/BGRA discussion we had earlier, I think that, in order to avoid data loss, the user should receive a The user can eventually perform the conversion he needs of the types is not the one he needs. The same is valid for the CV to yarp conversion, i.e. we can assume that the type is the default for the type of the |
The same should be valid for the |
Actually, I think this is a good pattern for all the compatibility libraries, we should add the right reference overload everywhere, and deprecate the const reference ones. Also because the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some minor comments and suggestions!
Thanks! 🎉
Travis builds with |
I believe it would be convenient to merge this PR before the holidays so that we (at least I) could employ the Christmas break to update the user code. |
Unfortunately we reached a sort of API impasse, maybe someone can help us to overcome it 😉 Here is the problem. Since no copy is involved, the memory is shared between
What do you think about it? @drdanz @traversaro @claudiofantacci @pattacini @vtikha The PR is ready once we solve this API issue! |
69f295e
to
9499692
Compare
Discussing with @claudiofantacci and @aerydna with decided to use |
@Nicogene thanks for the changes. I think they are ok, however test are failing because there are some things to be fixed in YARP. Are you also fixing them (like the |
My hope was to port |
It is always good to see good old @tanismar , even if just in a dataset. : ) |
Deprecation in favour of toCvMat and fromCVMat respectively
3dc120b
to
8da2896
Compare
8da2896
to
514e13b
Compare
Tests are now passed, we can merge it as soon as this PR is approved |
@Nicogene there's also |
For the |
Actually, there are references to |
Also, I would test the functionality carefully before merging. |
I successfully dumped with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks @Nicogene 🎉
|
In late 2018 we have finally a easy way that allow to get a
cv::Mat
from ayarp::sig::ImageOf
🎉Since there is no way to retrieve the Pixel code from the
cv::Mat
and the default coding is BGR, this library assumes that when converting to yarp image, the cv::Mat has to be BGR, and the cv::Mat obtained from the reversed conversion is BGR.Converting from OpenCV to Yarp no copies are involved.
In the other direction is quite tricky to understand when OpenCV performs a copy and when not 😕
@drdanz and me found a sort of rule behind their choice to copy or not, but maybe it is not important.
The argument of
toCvMat()
is a&&
a.k.a a right-reference, this means that after this function call the integrity of the data of the input yarp image is no longer guaranteed. Since we can't actually guarantee it 😅It can be used easily in cmake projects as
cv
component:find_package(YARP REQUIRED COMPONENTS OS conf sig dev cv)
Example of usage:
Lastly, this PR deprecates
getIplImage
andwrapIplImage
since they are now obsolete.It is super WIP and all the suggestions of the CV guys are more than welcome.
It fixes #1672.
It has been tested with different pixel codes (
PixelRgb
,PixelRgba
,PixelMono
,PixelBgr
,PixelBgra
), and it works 😎Please review code