COMtype compatibility issue :
As we know mediapipe works well with higher versions of python. i.e., 3.x and higher.
I am looking a for ways to implement features of mediapipe into pikinect2 for hand tracking and currently stuck at comtype errors.
Current suitable version of comtype for pykinect2 is v1.1.4
Kindly provide solutions to any one problem below.
An alternative solution to mediapipe at python version 2.7
Alternative way to make use of pykinect2 library for python 3.5 or higher versions without getting comtype errors.
Thanks
Related
I have a project that uses Python.Net for which I specify to customers that they need 'Python 3.6 or later'. However, when for example, Python 3.10 becomes the current default download from Python.org, does this mean that there will be a period of time where my applicaion won't work because Python.Net hasn't been updated to work with Python 3.10?
Or do I have to tell customers an upper bound value for the required Python verion?
That strongly depends on how are you distributing Python.NET.
If you are shipping Python.NET before 3.0 (3.0 has not been released yet) with your .NET app, it can only work with the specific python version it has been built for.
If you are asking users to install Python.NET using pip, I think it is possible to do it from source, in which case it should work with any Python 3.6+. You can check that by installing Python 3.10 preview and trying from there. Wheels of course are only built for existing python versions.
Python.NET 3.0 should be able to support future Python 3.x versions once released. But right now it is in flux, and the next release might take 6-12 months: many features are still being developed and/or reworked.
I've written a program on the python version 3.5.2, because i need a 64 bit version of python for my tensorflow-gpu library.
Its also possible to use the normal tensorflow library, which doese'nt require a 64 bit python, but in my case i wanted to use my gpu.
My question is: If some users have a higher version installed (of python) and use the normal tensorflow library, will they still be able to execute it?
Fabian
It all depends on what code you used, and if the syntax was changed in later versions. For example, if your version of Python uses print "Hello World!" and the user's version is print("Hello World"), then you would have to change it to the later versions specification.
I have NVIDIA driver v 378.92 installed, and according to the nvidia website since driver version 377.14, driver supports vulkan api 1.0.42.1. My vulkan SDK api version is 1.0.42.2. However when I check for my device support info, using vkjson_info.exe in the vulkan SDK, there's stated that only apiVersion 1.0.37 is supported.
I'm a bit confused how this works, can anyone enlighten this?
The reported version could be limited by the Vulkan Loader/Runtime it finds. First is this Windows or Linux?
If you have the Vulkan SDK 1.0.42.2 installed, can you run the VIA tool? It should generate an HTML output. If you look at the "Runtimes" section, you should see which ones are available and which one it's using. For best results, try running it from the same folder as vkjson_info.exe. But, it should give you a good idea if you just run it anywhere.
"1.0.42.1" is not a Vulkan version. Vulkan only has three levels (i.e. major.minor.patch). So the "1.0.37" is likely correct and the "1.0.42.1" is likely the version of some LunarG Vulkan SDK or possibly Vulkan Runtime that comes with it.
There are usually several types of versions flying around:
The Vulkan driver version. It is of the major.minor.patch format and it is in VkPhysicalDeviceProperties::apiVersion or can be obtained by a tool such as VHCV.
Optionally SDK/Layers version on the runtime machine. LunarG Vulkan SDK versioning of the form vulkan_major.vulkan_minor.vulkan_patch.optionally_SDK_patch.
Vulkan Runtime of the runtime machine — It is basically The Vulkan Loader dll (if the application uses that). Both SDK and drivers install this (and coexist) and they use their own versioning scheme. The SDK version also installs the Validation Layers to the system.
SDK/Header on the application developer machine. Versioning as described above. The vulkan.h header is always 1.0 and so has only single number version — VK_HEADER_VERSION (which matches the Vulkan patch version — but does not have to in the future)
SDK/Header on the driver developer machine. Versioning as described above. Should really be the same as Vulkan driver version. And most likely the Vulkan RT installed by the driver will be the same version. But I think I have seen this to differ.
It should not matter, because all patch versions are supposed to be both-ways compatible (in reality not really — there were some changes, but driver makers seem to keep up so far providing updated drivers, so it is not an issue). And in fact that is the only thing I could find in the driver documentation: "Vulkan 1.0" support.
I hope you are so enlightened now that you reached the ultimate state of boredom.
377 is a beta version driver from https://developer.nvidia.com/vulkan-driver . There is no guarantee that beta feature will be carried over to the subsequent release version. And according to http://vulkan.gpuinfo.org/listreports.php it didn't (378 indeed have 1.0.37 and 377 have 1.0.42 and more importantly has the extensions you want to try). Continue to use the beta for now if you want the features within it. As for Layers and other SDK features you should not need newer drivers — in fact you should always use the latest to benefit from Validation Layer bugfixes and improvements.
I am currently working from Mono Version 3.2.8 and am running into trouble finding any documentation on this version. I have no idea what code will run until after I get the exceptions. Either a compatibility list to what works or an idea of what version I can compile that works would be great. Any one have experience with this?
You can manually install the latest version. I was easily able to install
Mono version 4.6.2 on Raspbian.
The http://www.mono-project.com/docs/ site gives a general answer for which major libraries work. Letting you know when there isn't full compatibility but doesn't give specifics.
I recently installed the AC6 System Workbench in order
to work with the STM32 OSXMotionFX Library
and I'm experiencing some troubles related
to the sample application shipped with this library.
Let me know if there is a better place to post such question.
It seems that the sample project works with a different
version of the STM32 Cube expansion drivers for the
X-Nucleo-IKS01A1 expansion board of the base
STM32 Nucleo-F401RE board I have.
In particular the sample project links to driver files
that are missing, some of them seem with different names
compared to the existing ones, that's why I guess
the sample project is referring to an old version of the drivers.
Any one does know how to get the previous versions of the
STM32CubeExpansion_MEMS1_V1.4.0 software ?
I did already search the ST Microelectronics web site
but to no avail, the X-CUBE-MEM1 software
is only shipped at version 2.0.0
and it seems I need the previous version.
Thanks in advance for redirecting me to the correct site in case.
You can download the sample application in the software package osxMotionFX v1.4.0. It is aligned to the new version of the X-CUBE-MEMS1 drivers (v2.0.0). Unfortunately osxMotionFX v1.3.0 is not compatible with the new version of the X-CUBE-MEMS1 drivers.
You mean that osxMotionFX v1.4.0 does not work with X-CUBE-MEMS1 v2.0.0? It is very strange. I'm able to use them without any issue. So probably, you are using osxMotionFX v1.4.0 with an old version of X-CUBE-MEMS1 package. Try to uninstall your current osxMotionFX package, download again the X-CUBE-MEMS1 package v2.0.0 and reinstall the osxMotionFX v1.4.0 over the new X-CUBE-MEMS1 package v2.0.0. Let me know if it fixes your issue.
I use sample application of osxMotionFX v1.4.0 with X-CUBE-MEMS1 v2.0.0. I'm sure that you are not using X-CUBE-MEMS1 v2.0.0 because "x_nucleo_iks01a1_accelero.h" and "x_nucleo_iks01a1_gyro.h" are only defined in X-CUBE-MEMS1 v2.0.0 and not in the previous version of the package. You can also cross-check it looking at the installation folder that you are using for osxMotionFX; if it is not "STM32CubeExpansion_MEMS1_V2.0.0", then you are using a previous version of X-CUBE-MEMS1. Please, try to download again X-CUBE-MEMS1 software package.