Compiling pyrealsense2 binding in 'OFF' directory

[HerrmannM]

Required Info
Camera Model	D400
Firmware Version	SDK 2.54.1 and associated firmware
Operating System & Version	Ubuntu 22.04
Kernel Version (Linux Only)	5.19.0-45
Platform	PC/docker
Language	Python

When compiling with the following flags:

RUN cmake \ -DCMAKE_INSTALL_PREFIX=/opt/realsense2\ -DCMAKE_BUILD_TYPE=Release\ -DFORCE_RSUSB_BACKEND=true\ -DBUILD_EXAMPLES=false\ -DBUILD_TOOLS=true\ -DBUILD_EASYLOGGINGPP=true\ -DBUILD_WITH_TM2=false\ -DBUILD_GLSL_EXTENSIONS=false\ -DIMPORT_DEPTH_CAM_FW=false\ -DBUILD_PYTHON_BINDINGS=true\ -DPYTHON_EXECUTABLE=/usr/bin/python3.10\ .. RUN make RUN make install

Creates a folder '/opt/realsense2' with the following content
`
/opt/realsense2# ls *
OFF:
pybackend2.cpython-310-x86_64-linux-gnu.so pybackend2.cpython-310-x86_64-linux-gnu.so.2.54.1 pyrealsense2.cpython-310-x86_64-linux-gnu.so.2.54 pyrsutils.cpython-310-x86_64-linux-gnu.so pyrsutils.cpython-310-x86_64-linux-gnu.so.2.54.1
pybackend2.cpython-310-x86_64-linux-gnu.so.2 pyrealsense2.cpython-310-x86_64-linux-gnu.so pyrealsense2.cpython-310-x86_64-linux-gnu.so.2.54.1 pyrsutils.cpython-310-x86_64-linux-gnu.so.2.54

bin:
rs-convert rs-embed rs-enumerate-devices rs-fw-logger rs-fw-update rs-record rs-terminal

include:
librealsense2

lib:
cmake librealsense-file.a librealsense2.so librealsense2.so.2.54 librealsense2.so.2.54.1 librsutils.a pkgconfig
`

i.e. the python bindings are put in an 'OFF' folder. I suspect a CMake bug (a switch ON/OFF put in a path?) but could not find it.

[MartyG-RealSense]

Hi @HerrmannM Does it make a difference if you use -DBUILD_PYTHON_BINDINGS:bool=true (adding the 'bool' command)

You could also try a more basic CMake instruction to see whether one of your build flags may be affecting the installation of pyrealsense2.

RUN cmake \ -DCMAKE_BUILD_TYPE=Release\ -DFORCE_RSUSB_BACKEND=true\ -DBUILD_PYTHON_BINDINGS=true\ -DPYTHON_EXECUTABLE=/usr/bin/python3.10\ .. RUN make RUN make install

[HerrmannM]

Hi @MartyG-RealSense and thank you for you quick reply!

I tried both, did not make a difference.
When building without the prefix, I have the 'OFF' directory in the '/usr/local' folder:

root@23df1f4fb82c:/usr/local# ls OFF/
pybackend2.cpython-310-x86_64-linux-gnu.so         pyrealsense2.cpython-310-x86_64-linux-gnu.so         pyrsutils.cpython-310-x86_64-linux-gnu.so
pybackend2.cpython-310-x86_64-linux-gnu.so.2       pyrealsense2.cpython-310-x86_64-linux-gnu.so.2.54    pyrsutils.cpython-310-x86_64-linux-gnu.so.2.54
pybackend2.cpython-310-x86_64-linux-gnu.so.2.54.1  pyrealsense2.cpython-310-x86_64-linux-gnu.so.2.54.1  pyrsutils.cpython-310-x86_64-linux-gnu.so.2.54.1

Note that the 2.53.1 release installed the bindings in the system dist-packages

root@c59c7693a896:/usr/lib/python3/dist-packages# ls pyrealsense2/
pybackend2.cpython-310-x86_64-linux-gnu.so    pybackend2.cpython-310-x86_64-linux-gnu.so.2.53.1  pyrealsense2.cpython-310-x86_64-linux-gnu.so.2.53
pybackend2.cpython-310-x86_64-linux-gnu.so.2  pyrealsense2.cpython-310-x86_64-linux-gnu.so       pyrealsense2.cpython-310-x86_64-linux-gnu.so.2.53.1

[MartyG-RealSense]

I have highlighted your case to my Intel RealSense colleagues to seek their advice. Thanks very much for your patience!

[HerrmannM]

Thanks!

[MartyG-RealSense]

My colleagues were able to replicate the issue that you experienced with 2.54.1 and we will discuss it.

[MartyG-RealSense]

After discussion, an internal Intel ticket has been created so that the issue can be investigated. I have added an Enhancement label to this case to signify that it should be kept open whilst the internal report is active, but you do not need to take further action. Thanks again for your report of the issue!

[Nir-Az]

@HerrmannM I think we found the cause.
One question, I see it is being installed to dist-packages as expected.
But if we import it from other path it can be imported but we cannot access the internal components like:

import pyrealsense2 as rs
rs.__version__

I installed 2.53.1 and it looks same.
Only if I am inside the path itself

/usr/lib/python3/dist-packages/pyrealsense2

I can access all attributes and modules.

Is it the same for you?

Update : Now I see this work, is this how you import it?

[MartyG-RealSense]

Hi @HerrmannM Could you provide feedback about the advice provided by @Nir-Az in the comment above, please? Thanks!

[Nir-Az]

Fix merged: See #11959

Please update if it fix your issue, sorry for the inconvenience :)

[HerrmannM]

Thanks for the fix!
Sorry for the late reply, I got sidetrack with ther things, will test ASAP and let you know =)

Cheers,
Mat

[HerrmannM]

Hi,

I tested with the current dev branch (https://github.com/IntelRealSense/librealsense/tree/7b4adccdb61887e0a6b2f032289c48ebf10fcd07 for the specific commit) and it indeed built the binding where expected.
Thanks!

On our production side of things, we'll wait for a new release tag to update :)

Cheers,
Mat

[MartyG-RealSense]

It's excellent news that the fix worked for you. Thanks very much for the update. As the fix was merged into the SDK and your issue was resolved, I will close this case. Thanks again!

[IamShubhamGupto]

@HerrmannM I think we found the cause. One question, I see it is being installed to dist-packages as expected. But if we import it from other path it can be imported but we cannot access the internal components like:

import pyrealsense2 as rs
rs.__version__

I installed 2.53.1 and it looks same. Only if I am inside the path itself

/usr/lib/python3/dist-packages/pyrealsense2

I can access all attributes and modules.

Is it the same for you?

Update : Now I see this work, is this how you import it?

I am having a similar issue with dusty-nv/jetson-containers#281 (comment)

is the fix to just update the import as

from pyrealsense2 import pyrealsense2 as rs

Thank you

[HerrmannM]

Hi @IamShubhamGupto

Apologies for the delay, I just changed job and I don't have access to the code anymore.
Sorry I can't help more!

Cheers,
Mat

[nakai-omer]

This is still happening in 2.54.2

[Nir-Az]

Please try development branch and update

[nakai-omer]

@Nir-Az Thanks for the quick reply, indeed it works as expected in latest development branch. Are there any plans to release a stable release with this fix?

[Nir-Az]

It will take some time as we are currently working on a set of features and bug fixes for the release, but it is coming :)