You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After adding the library pyrealsense2 to the environment, compilation fails at "import pclpy" with the error "type object 'DimensionInfo' has no attribute 'from_dtype'" (possibly related to Laspy)
#92
Open
Chris45215 opened this issue
Jul 16, 2021
· 2 comments
We are using PCLpy for our project and it was working successfully, until recently. We got some Intel Realsense sensors and imported the pyrealsense2 library into our environment (python 3.6). After we did this, the project fails to run, and the IDE (Visual Studio) throws the error "type object 'DimensionInfo' has no attribute 'from_dtype'" at the line "import pclpy", which is the first line in the project. We have removed the pyrealsense2 library, but compilation still fails. We have also uninstalled and reinstalled, and "pip --force-reinstall"-ed, both pclpy and pclpy-dependencies.
When we dig into the error, the DimensionInfo class is in Laspy (at [Python environment]\Lib\site-packages\laspy\point\dims.py), and from_dtype is an attribute in that class. So, the code is in the project and it shows that attribute. If we remove the Laspy library, then the code fails at the same line except the failure is "No module named laspy".
I have an environment and project that is identical, as far as I can tell, on a 2nd computer. It runs perfectly on the 2nd computer; the only difference is that I have not installed the pyrealsense2 library onto the 2nd computer. A third computer (my coworker's) also had pyrealsense2 installed and hits the exact same problem. I don't want to add the pyrealsense2 library to the working computer to test further, as we can't figure out how to reverse whatever changes are made.
My best guess at what's happening is that pyrealsense2 includes some PCL components, so there might have been some overlapping dependencies or a naming conflict. But we removed the pyrealsense2 library and reinstalled all the pclpy libraries, so any such issue should be resolved
The only other differences between the computers is that when I run a search in Visual Studio and set it to search the entire solution, the computer with the problem finds those Laspy files; while the computer without the problem does not find them via that search. But I checked the filesystem of the working computer, and those same files are still there; they just don't appear in Visual Studio's search (so this may simply be a difference in some setting in search depth). Otherwise, the broken computer uses Visual Studio v16.9.2 while the working one uses v16.7.4, and they both have the exact same .net framework 4.8.04084 - so I expect the search result difference is from the slightly different versions of Visual Studio.
Any help with this would be great. My final plan is to copy the entire environment from the working computer to the broken computers - but that also means we cannot use the RealSense library, which we intended to use.
The text was updated successfully, but these errors were encountered:
Chris45215
changed the title
After adding the library pyrealsense/2.0 to the environment, compilation fails at "import pclpy" with the error "type object 'DimensionInfo' has no attribute 'from_dtype'" (possibly related to Laspy)
After adding the library pyrealsense2 to the environment, compilation fails at "import pclpy" with the error "type object 'DimensionInfo' has no attribute 'from_dtype'" (possibly related to Laspy)
Jul 16, 2021
We are using PCLpy for our project and it was working successfully, until recently. We got some Intel Realsense sensors and imported the pyrealsense2 library into our environment (python 3.6). After we did this, the project fails to run, and the IDE (Visual Studio) throws the error "type object 'DimensionInfo' has no attribute 'from_dtype'" at the line "import pclpy", which is the first line in the project. We have removed the pyrealsense2 library, but compilation still fails. We have also uninstalled and reinstalled, and "pip --force-reinstall"-ed, both pclpy and pclpy-dependencies.
When we dig into the error, the DimensionInfo class is in Laspy (at [Python environment]\Lib\site-packages\laspy\point\dims.py), and from_dtype is an attribute in that class. So, the code is in the project and it shows that attribute. If we remove the Laspy library, then the code fails at the same line except the failure is "No module named laspy".
I have an environment and project that is identical, as far as I can tell, on a 2nd computer. It runs perfectly on the 2nd computer; the only difference is that I have not installed the pyrealsense2 library onto the 2nd computer. A third computer (my coworker's) also had pyrealsense2 installed and hits the exact same problem. I don't want to add the pyrealsense2 library to the working computer to test further, as we can't figure out how to reverse whatever changes are made.
My best guess at what's happening is that pyrealsense2 includes some PCL components, so there might have been some overlapping dependencies or a naming conflict. But we removed the pyrealsense2 library and reinstalled all the pclpy libraries, so any such issue should be resolved
The only other differences between the computers is that when I run a search in Visual Studio and set it to search the entire solution, the computer with the problem finds those Laspy files; while the computer without the problem does not find them via that search. But I checked the filesystem of the working computer, and those same files are still there; they just don't appear in Visual Studio's search (so this may simply be a difference in some setting in search depth). Otherwise, the broken computer uses Visual Studio v16.9.2 while the working one uses v16.7.4, and they both have the exact same .net framework 4.8.04084 - so I expect the search result difference is from the slightly different versions of Visual Studio.
Any help with this would be great. My final plan is to copy the entire environment from the working computer to the broken computers - but that also means we cannot use the RealSense library, which we intended to use.
The text was updated successfully, but these errors were encountered: