cv2.waitKey bug

I was trying a Grabcut sample code (don't use this version) written in Python by abid rahman and stuck at a strange problem: the cv2.waitKey() didn't work normally!

Yesterday I searched the problem on Google and found nothing useful (according to my skill level, I might overlooked something that could be hints), so I decided to ask in the G+ Python community [1].

Based on Brett Ponsler's helpful suggestion, I tried to rewrite my test code and also went to download the Grabcut sample code again (this version is fine). This time, the sample code was running successfully.

Then I noticed a magic word ``0xFF'' in the new downloaded sample code. Using the hint, I finally found the bug report about cv2.waitKey() and came up with a tiny test code:

import cv2
import numpy as np

cv2.namedWindow('test')

while True:
    #key = cv2.waitKey(33) #this won't work
    #key = 0xFF & cv2.waitKey(33) #this is ok
    key = np.int16(cv2.waitKey(33)) #this is ok [2]

    if key == 27:
        break
    else:
        print key, hex(key), key % 256

cv2.destroyAllWindows()

---
[1] The question I posted in the Python community: https://plus.google.com/117911423781149907976/posts/CdvQ3vWVV19
[2] http://jiaxihu.blogspot.tw/2013/02/opencv-python-64bit-waitkey.html

Test Kinect in Win7 x64 using x86 driver

In the previous posts [1][2] I tried to rebuild a VS project using Kinect given by my colleague and encountered some problems. Because my Win7 is the x64 version but the project had been built for x86 (Win32) platform, the rebuilding work in my Win7 machine cost me and my colleague almost a whole working day (without my colleague's help, I may give up the rebuilding).

Although I changed the project configuration to x64 [2], there were still problems with other libraries, for instance, OpenCV, built along with the project for x86 platform. When I was wondering the next step, my colleague suggested me to try the x86 driver of Kinect and if it works, just keep sticking on the Win32 setting of the project configuration.

Hmm, it seemed I had taken a long route and headed back to the origin... XD

Okay, the happy news is the x86 driver really worked in the x64 Win7, and here is a working log of the test.

Change VS2005 project from Win32 to x64

I was rebuilding a Win32 project in my x64 Win7 PC. The online sources [1][2] told me just to change the active project configuration from Win32 to x64, but my VS2005 has no x64 option. Then it occurred to me that maybe I didn't install something related to x64 modules when installing the VS2005, so I checked it by using the installation package.

'WIN32': No such file or directory

I was rebuilding a project given by my colleague and encountered strange error message:

c1xx : fatal error C1083: Cannot open source file: 'WIN32': No such file or directory

This error was caused by an empty path variable [1] $(OPEN_NI_INCLUDE) which (I guess) indicates the directory containing the installed OpenNI SDK. It was empty because I forgot to restart Visual Studio after install the SDK... :-p

So the solution is simple: restart Visual Studio and the path variable will be set.

---
Edit:

After solving the previous problem, I got another similar problem which related to the Linker path.

I used the set command [2] in cmd of Windows to the list environment variables about OpenNI:

OPEN_NI_BIN64=C:\Program Files\OpenNI\Bin64
OPEN_NI_INCLUDE=C:\Program Files\OpenNI\Include
OPEN_NI_INSTALL_PATH64=C:\Program Files\OpenNI\
OPEN_NI_LIB64=C:\Program Files\OpenNI\Lib64

Then I changed $(OPEN_NI_LIB) to $(OPEN_NI_LIB64) and the new error message said the file OpenNI.lib cannot be found, and the reason was it should be  OpenNI64.lib in my system. The right place to change the library file name is in the following path:

Properties -> Configuration Properties -> Linker -> Input -> Additional Dependencies

---
Ref:
[1] Cannot open source file: 'WIN32': No such file or directory
[2] How can I display the contents of an environment variable from the command prompt in Windows 7?