search

toinsson / pyrealsense

Cross-platform ctypes/Cython wrapper to the librealsense library (v1.x)
http://pyrealsense.readthedocs.io
Apache License 2.0
121 stars 46 forks source link

librealsense 2.0 #55

Closed cedricjeanty closed 4 years ago

cedricjeanty commented 7 years ago

What is the plan with respect to the new librealsense python wrapper? The developers at intel released a basic python wrapper in the their development branch recently, however it is in the early stages. Thanks!

papr commented 7 years ago

Understanding their bindings is kinda difficult since it is very low level. I will have to take a bit more time to read into their code to understand where they are going with it.

toinsson commented 7 years ago

Thanks for pointing this out. I think it would be good for this project to support the new release, but I am not sure yet how much work that implies as it looks like quite a big change from v1.x. About the new python wrapper provided, it is based on pybind11 - which might make it very close to the C++ code. (by opposition pyrealsense is based on ctypes)

cedricjeanty commented 7 years ago

Maybe we can help impact the development of the 2.0 python wrapper? The intel developers have been very responsive and helpful to me so far.

papr commented 7 years ago

This should definitely be a long term goal.

zivsha commented 6 years ago

Hi there! I'm working with the RealSense SDK team on the new librealsense library. I would be happy to assist with whatever I can to help bring this project up to speed with SDK 2.0 Feel free to contact me, or open a new discussion on our GitHub page :)

papr commented 6 years ago

Hey @zivsha Great to hear from you! I have multiple questions regarding SDK 2.0:

  1. Will SDK 2.0 be backwards compatible (hardware-wise) with all previous devices (especially the R200)?
  2. I saw that the new SDK includes its own Python bindings. What is your plan for those? Are these meant as low level bindings or are you planning on a more pythonic API in the future?
  3. Could you point us to a document that includes the most important API changes?
  4. Where do you usually announce new upcoming releases? I had difficulties finding information when I saw your development branch towards SDK 2.0.
zivsha commented 6 years ago

Hey @papr , Would it be possible to move this discussion to our GitHub so that maybe more individuals could participate, share ideas and also maybe share other python helpers such as your repo?

  1. Currently no, SDK 2.0 only supports the D400 series and the SR300 (see our Overview).
  2. The bindings are meant as low level binding, but expose regular python API (with some additional stuff like the __repr__ functions). I'm not sure what you mean by "more pythonic" since it is a broad concept, but we can discuss that in the discussion I mentioned above.
  3. See our Wiki for API Changes and API How To for that.
  4. Releases are under the Releases tab
toinsson commented 6 years ago

Hello @zivsha, thanks for reaching out.

The issue you linked refer to a user expecting to install python bindings to librealsense v2 through pip. Issue #62 was the same problem. To limit confusion, we could try to improve the error and warning messages raised at install from pyrealsense, like here for example: https://github.com/toinsson/pyrealsense/blob/1b327915ee8e7a28d17c0446a720a59356fc8a40/pyrealsense/extlib.py#L26 Maybe you have some other suggestions?

You are also asking to move the discussion to your Github. Please feel free to do so. Hopefully this will motivate individuals to get involved? As you can see from the list of contributors, this wrapper has been developed by relatively few people. You might need to be explicit on your github about what you are looking for.

I am also still using the SR300 and do not plan to move to D400 in the coming months. So developing another wrapper is not on top of my priorities right now. @papr, are you using R200 only?

Regarding point 2 from @papr, more pythonic would mean using Python data structures and idioms to interact with the underlying API. That could be using context managers, properties, Python's own naming guidelines and maybe more importantly Python's own package manager pip (and conda if you want to please everybody : ) ).

zivsha commented 6 years ago

Hi guys, I've started some initial work for a PyPI package for the new SDK. Python packaging is new to me but I'm hoping that what I have so far is a good start. I would appreciate comments and suggestions on the go (this is not a top priority task but I would love to make it work). This is a PR I created on my fork to start using the CI system for creating a wheel. Hope to get some feedbacks :)

Oh and Happy New year !! 😃 🎉

toinsson commented 6 years ago

Glad you got going on this! I'll give some feedback asap.

toinsson commented 6 years ago

@zivsha, I have been looking quickly at the PR. Seems like you have been automating the building of the wrapper (appveyor + travis)? And there is a setup.py too, which a user should execute to get the wrapper?

I am not sure what kind of feedback you would like though.

In term of pushing version to PyPI, I used to do it manually. Not sure it is possible to automate that process with every new releases.

zivsha commented 6 years ago

@toinsson, first of all thanks for the effort. The purpose of adding steps to the CI was the same as adding tests to a project-it is just for making sure no one breaks anything and that a package can be created whenever new PRs come in. Uploading the wheel to PyPI will be automated probably on our release automation which is not public.

As I'm not a python expert, I would like to know what are the best methods for creating these packages, and if what I have is the way to go. I'm actually on hold with this one currently, since I'm not sure how to upload multiple builds types of the same version (I want to put a 32 bit and x64 versions for both Windows, Linux and MacOS) and also a python2 and python3 version for each build type.

toinsson commented 6 years ago

It seems like you will not be able to build the bindings without having access to the sources, due to pybind11 ways of working (correct?). In pyrealsense case, we use ctypes to bind directly to binaries and parse the headers which let users build their bindings during pip install.

These two ways are quite different. And I am not personally an expert in cross-platform compilation. But it seems that is what you will have to do if you want to provide a "one-clic" install.

zivsha commented 6 years ago

It seems like you will not be able to build the bindings without having access to the sources, due to pybind11 ways of working (correct?).

Correct, I intend to build all variations of the SDK with Python on our build machines and take the wheel will contain a binary only version of the library. (Build machine will compile and each .so or .pyd file will be packaged into the wheel). pip install will just unpack the wheel and place the binaries in the right place.