updated flip realsense

[ste93]

Added option rotateImage180 in order to rotate the image when the realsense is flipped upside down

[ste93]

@traversaro

[traversaro]

If this new parameter is suggested (not specifying it results in a warning) can you update the README to cover it, and add a line to the changelog about it? Thanks!

[ste93]

Thanks for the review @traversaro, I think that the best way is to remove the warning. Under the suggestion of @elandini84 I've put a warning when the parameter is enabled.

[Nicogene]

If the nested for loops are not affecting too much the performance, lgtm
I think you already looked if there is something in the configuration of the device or native functions for flipping in the sdk

[ste93]

If the nested for loops are not affecting too much the performance, lgtm I think you already looked if there is something in the configuration of the device or native functions for flipping in the sdk

On the sdk they're saying to use opencv, so I think this is the best way. Also if this option is not enabled the behavior is the same as before

[Nicogene]

If the nested for loops are not affecting too much the performance, lgtm I think you already looked if there is something in the configuration of the device or native functions for flipping in the sdk

On the sdk they're saying to use opencv, so I think this is the best way. Also if this option is not enabled the behavior is the same as before

I would give a try in order to see if the improvement in performance with OpenCV is worthy adding the dependency. But if you already tested it and you have solid fps we can merge it

[ste93]

If the nested for loops are not affecting too much the performance, lgtm I think you already looked if there is something in the configuration of the device or native functions for flipping in the sdk

On the sdk they're saying to use opencv, so I think this is the best way. Also if this option is not enabled the behavior is the same as before

I would give a try in order to see if the improvement in performance with OpenCV is worthy adding the dependency. But if you already tested it and you have solid fps we can merge it

I've not tested it with big fps, since on the robot we're using low fps. But I can open an issue to track it and check it

[randaz81]

If the nested for loops are not affecting too much the performance, lgtm I think you already looked if there is something in the configuration of the device or native functions for flipping in the sdk

On the sdk they're saying to use opencv, so I think this is the best way. Also if this option is not enabled the behavior is the same as before

I would give a try in order to see if the improvement in performance with OpenCV is worthy adding the dependency. But if you already tested it and you have solid fps we can merge it

I think it does not worth adding opencv dependency for such a simple processing...

[ste93]

@traversaro do you want me to squash the commits? otherwise for me it can be merged

[traversaro]

Thanks for the remainder and for the PR, I simply forgot.

[ste93]

no problem, thank you