출처 : http://www.brekel.com/?page_id=671

Kinect SDK에 대하여 찾던 중 OpenNI라는 것을 알게 되었다.
MS에서 공개한 SDK 베타버전과 OpenNI에 대한 비교는 다음과 같다.

둘다 각각 장단점이 존재 한다.
Kinect SDK와 OpenNI를 연동시키는 것도 존재한다고 하니 좀 더 찾아봐야 겠다.

Microsoft’s Kinect SDK (Beta)
pro:

  • support for audio
  • support for motor/tilt
  • full body tracking:
    • does not need a calibration pose
    • includes head, hands, feet, clavicles
    • seems to deal better with occluded joints
  • supports multiple sensors
  • single no-fuss installer
  • SDK has events for when a new Video or new Depth frame is available

con:

  • licensed for non-commercial use only
  • only tracks full body (no mode for hand only tracking)
  • does not offer alignment of the color&depth image streams to one another yet
    • although there are features to align individual coordinates
    • and there are hints that support may come later
  • full body tracking:
    • only calculates positions for the joints, not rotations
    • only tracks the full body, no upperbody or hands only mode
    • seems to consume more CPU power than OpenNI/NITE (not properly benchmarked)
  • no gesture recognition system
  • no support for the PrimeSense and the ASUS WAVI Xtion sensors? (can anyone confirm this?)
  • only supports Win7 (x86 & x64)
  • no support for Unity3D game engine
  • no built in support for record/playback to disk
  • no support to stream the raw InfraRed video data
  • SDK does not have events for when new user enters frame, leaves frame etc

 

PrimeSense OpenNI/NITE

pro:

  • license includes commercial use
  • includes a framework for hand tracking
  • includes a framework for hand gesture recognition
  • can automatically align the depth image stream to the color image
  • full body tracking:
    • also calculates rotations for the joints
    • support for hands only mode
    • seems to consume less CPU power than Microsoft Kinect SDK’s tracker (not properly benchmarked)
  • also supports the Primesense and the ASUS WAVI Xtion sensors
  • supports multiple sensors although setup and enumeration is a bit quirky
  • supports Windows (including Vista&XP), Linux and Mac OSX
  • comes with code for full support in Unity3D game engine
  • support for record/playback to/from disk
  • support to stream the raw InfraRed video data
  • SDK has events for when new User enters frame, leaves frame etc

con:

  • no support for audio
  • no support for motor/tilt (although you can simultaneously use the CL-NUI motor drivers)
  • full body tracking:
    • lacks rotations for the head, hands, feet, clavicles
    • needs a calibration pose to start tracking (although it can be saved/loaded to/from disk for reuse)
    • occluded joints are not estimated
  • supports multiple sensors although setup and enumeration is a bit quirky
  • three separate installers and a NITE license string (although the process can be automated with my auto driver installer)
  • SDK does not have events for when new Video or new Depth frames is available

posted by deviAk

Kinect for Windows Architecture

The SDK provides a sophisticated software library and tools to help developers use the rich form of Kinect-based natural input, sensing and reacting to real-world events.

The Kinect sensor and associated software library interact with your application, as shown in Figure 1.

Figure 1.  Figure 1. Hardware and software interaction with an application

The components of the SDK are shown in Figure 2.

Figure 2.  SDK Architecture

Components for the SDK shown in Figure 2 include the following:

  • Kinect hardware - The hardware components, including the Kinect sensor and the USB hub, through which the sensor is connected to the computer.
  • Microsoft Kinect drivers - The Windows 7 drivers for the Kinect sensor, which are installed as part of the SDK setup process as described in this document. The Microsoft Kinect drivers support:
    • The Kinect sensor’s microphone array as a kernel-mode audio device that you can access through the standard audio APIs in Windows.
    • Streaming image and depth data.
    • Device enumeration functions that enable an application to use more than one Kinect sensor that is connected to the computer.
  • KinectAudio DirectX Media Object (DMO) - The Kinect DMO that extends the microphone array support in Windows 7 to expose beamforming and source localization functionality.
  • Windows 7 standard APIs - The audio, speech, and media APIs in Windows 7, as described in the Windows 7 SDK and the Microsoft Speech SDK.
The NUI API

The NUI API is the core of the Kinect for Windows API. It supports fundamental image and device management features, including the following:

  • Access to the Kinect sensors that are connected to the computer.
  • Access to image and depth data streams from the Kinect image sensors.
  • Delivery of a processed version of image and depth data to support skeletal tracking. 
This SDK includes C++ and C# versions of the SkeletalViewer sample. SkeletalViewer shows how to use the NUI API in an application to capture data streams from the NUI Image camera, use skeletal images, and process sensor data. For more information, see “Skeletal Viewer Walkthrough” on the SDK website.

NUI API Initialization

The Microsoft Kinect drivers support the use of multiple Kinect sensors on a single computer. The NUI API includes functions that enumerate the sensors, so that you can determine how many sensors are connected to the machine, get the name of a particular sensor, and individually open and set streaming characteristics for each sensor.

Although the SDK supports an application using multiple Kinect sensors, only one application can use each sensor at any given time.

Sensor Enumeration and Access

C++ and managed code applications enumerate the available Kinect sensors, open a sensor, and initialize the NUI API in one of the following ways:

To initialize the NUI API and use only one Kinect sensor in a C++ application

  1. Call NuiInitialize. This function initializes the first instance of the Kinect sensor device on the system.
  2. Call other NuiXxx functions to stream image and skeleton data and manage the cameras.
  3. Call NuiShutdown when use of the Kinect sensor is complete.
To initialize the NUI API and use more than one Kinect sensor in a C++ application
  1. Call MSR_NuiDeviceCount to determine how many sensors are available.
  2. Call MSR_NuiCreateInstanceByIndex to create an instance for each sensor that the application uses. This function returns an INuiInstance interface pointer for the instance.
  3. Call INuiInstance::NuiInitialize to initialize the NUI API for the sensor.
  4. Call other methods on the INuiInstance interface to stream image and skeleton data and manage the cameras.
  5. Call INuiInstance::NuiShutdown on a sensor instance to close the NUI API when use of that sensor is complete.
  6. Call MSR_NuiDestroyInstance to destroy the instance.
To initialize the NUI API and use one Kinect sensor in managed code
  1. Create a new Runtime object and leave the parameter list empty, as in the following C# code: nui = new Runtime(); This constructor creates an object that represents the first instance of the Kinect sensor device on the system.
  2. Call Runtime.Initialize to initialize the NUI API for the sensor.
  3. Call additional methods in the managed interface to stream image and skeleton data and to manage the cameras.
  4. Call Runtime.Shutdown when use of the Kinect sensor is complete.
To initialize the NUI API and use more than one Kinect sensor in managed code
  1. Call MSR_NuiDeviceCount to determine how many sensors are available.
  2. Create a new Runtime object and pass the index of a sensor, as in the following C# code:
       nui = new Runtime(index);
  3. This constructor creates an object that represents a particular instance of the Kinect sensor device on the system.
  4. Call Runtime.Initialize to initialize the NUI API for that device instance.
  5. Call additional methods in the managed interface to stream image and skeleton data and to manage the cameras.
  6. Call Runtime.Shutdown when use of that device instance is complete.

Initialization Options

The NUI API processes data from the Kinect sensor through a multistage pipeline. At initialization, the application specifies the subsystems that it uses, so that the runtime can start the required portions of the pipeline. An application can choose one or more of the following options:

  • Color - The application streams color image data from the sensor.
  • Depth - The application streams depth image data from the sensor.
  • Depth and player index - The application streams depth data from the sensor and requires the player index that the skeleton tracking engine generates.
  • Skeleton - The application uses skeleton position data.

These options determine the valid stream types and resolutions for the application. For example, if an application does not indicate at NUI API initialization that it uses depth, it cannot later open a depth stream.

NUI Image Data Streams: An Overview

The NUI API provides the means to modify settings for the Kinect sensor array, and it enables you to access image data from the sensor array.

Stream data is delivered as a succession of still-image frames. At NUI initialization, the application identifies the steams it plans to use. It then opens those streams with additional stream-specific details, including stream resolution, image type, and the number of buffers that the runtime should use to store incoming frames. If the runtime fills all the buffers before the application retrieves and releases a frame, the runtime discards the oldest frame and reuses that buffer. As a result, it is possible for frames to be dropped. An application can request up to four buffers; two is adequate for most usage scenarios.

An application has access to the following kinds of image data from the sensor array:

  • Color data
  • Depth data
  • Player segmentation data 

Color Image Data

Color data is available in the following two formats:

  • RGB color provides 32-bit, linear X8R8G8B8-formatted color bitmaps, in sRGB color space. To work with RGB data, an application should specify a color or color_YUV image type when it opens the stream.
  • YUV color provides 16-bit, gamma-corrected linear UYVY-formatted color bitmaps, where the gamma correction in YUV space is equivalent to sRGB gamma in RGB space. Because the YUV stream uses 16 bits per pixel, this format uses less memory to hold bitmap data and allocates less buffer memory when you open the stream. To work with YUV data, your application should specify the raw YUV image type when it opens the stream. YUV data is available only at the 640x480 resolution and only at 15 FPS. 
Both color formats are computed from the same camera data, so that the YUV data and RGB data represent the same image. Choose the data format that is most convenient given your application's implementation.

The sensor array uses a USB connection to pass data to the PC, and that connection provides a given amount of bandwidth. The Bayer color image data that the sensor returns at 1280x1024 is compressed and converted to RGB before transmission to the runtime. The runtime then decompresses the data before it passes the data to your application. The use of compression makes it possible to return color data at frame rates as high as 30 FPS, but the algorithm that is used leads to some loss of image fidelity.

The sensor array uses a USB connection to pass data to the PC, and that connection provides a given amount of bandwidth. The Bayer color image data that the sensor returns at 1280x1024 is compressed and converted to RGB before transmission to the runtime. The runtime then decompresses the data before it passes the data to your application. The use of compression makes it possible to return color data at frame rates as high as 30 FPS, but the algorithm that is used leads to some loss of image fidelity.

Depth Data

The depth data stream provides frames in which each pixel represents the Cartesian distance, in millimeters, from the camera plane to the nearest object at that particular x and y coordinate in the depth sensor's field of view. The following depth data streams are available:

  • Frame size of 640×480 pixels
  • Frame size of 320×240 pixels
  • Frame size of 80×60 pixels 
Applications can process data from a depth stream to support various custom features, such as tracking users' motions or identifying background objects to ignore during application play.

The format of the depth data depends on whether the application specifies depth only or depth and player index at NUI initialization, as follows:

  • For depth only, the low-order 12 bits (bits 0?11) of each pixel contain depth data and the remaining 4 bits are unused.
  • For depth and player index, the low-order 3 bits (bits 0?2) of each pixel contain the player index and the remaining bits contain depth data. 
A depth data value of 0 indicates that no depth data is available at that position, because all the objects were either too close to the camera or too far away from it.

Player Segmentation Data

In the SDK , the Kinect system processes sensor data to identify two human figures in front of the sensor array and then creates the Player Segmentation map. This map is a bitmap in which the pixel values correspond to the player index of the person in the field of view who is closest to the camera, at that pixel position.

Although the player segmentation data is a separate logical stream, in practice the depth data and player segmentation data are merged into a single frame:

  • The 13 high-order bits of each pixel represent the distance from the depth sensor to the closest object, in millimeters.
  • The 3 low-order bits of each pixel represent the player index of the tracked player who is visible at the pixel's x and y coordinates. These bits are treated as an integer value and are not used as flags in a bit field. 
A player index value of zero indicates that no player was found at that location. Values one and two identify players. Applications commonly use player segmentation data as a mask to isolate specific users or regions of interest from the raw color and depth images.

Retrieving Image Information

Application code gets the latest frame of image data by calling a frame retrieval method and passing a buffer. If the latest frame of data is ready, it is copied into the buffer. If your code requests frames of data faster than new frames are available, you can choose whether to wait for the next frame or to return immediately and try again later. The NUI Image Camera API never provides the same frame of data more than once.

Applications can use either of the following two usage models:

  • Polling Model The polling model is the simplest option for reading data frames. First, the application code opens the image stream. It then requests a frame and specifies how long to wait for the next frame of data (between 0 and an infinite number of milliseconds). The request method returns when a new frame of data is ready or when the wait time expires, whichever comes first. Specifying an infinite wait causes the call for frame data to block and to wait as long as necessary for the next frame.

    When the request returns successfully, the new frame is ready for processing. If the time-out value is set to zero, the application code can poll for completion of a new frame while it performs other work on the same thread. A native C++ application calls NuiImageStreamOpen to open a color or depth stream and omits the optional event. Managed code calls ImageStream.Open. To poll for color and depth frames, native C++applications call NuiImageStreamGetNextFrame and managed code calls ImageStream.GetNextFrame.

  • Event Model The event model supports the ability to integrate retrieval of a skeleton frame into an application engine with more flexibility and more accuracy.

    In this model, C++ application code passes an event handle to NuiImageStreamOpen. When a new frame of image data is ready, the event is signaled. Any waiting thread wakes and gets the frame of skeleton data by calling NuiImageGetNextFrame. During this time, the event is reset by the NUI Image Camera API.

    Managed code uses the event model by hooking a Runtime.DepthFrameReady or Runtime.ImageFrameReady event to an appropriate event handler. When a new frame of data is ready, the event is signaled and the handler runs and calls ImageStream.GetNextFrame to get the frame.

NUI Skeleton Tracking

The NUI Skeleton API provides information about the location of up to two players standing in front of the Kinect sensor array, with detailed position and orientation information.

The data is provided to application code as a set of points, called skeleton positions, that compose a skeleton, as shown in Figure 3. This skeleton represents a user’s current position and pose. Applications that use skeleton data must indicate this at NUI initialization and must enable skeleton tracking.

Figure 3.  Figure 3. Skeleton joint positions relative to the human body

Retrieving Skeleton Information

Application code gets the latest frame of skeleton data in the same way that it gets a frame of image data: by calling a frame retrieval method and passing a buffer. Applications can use either a polling model or an event model, in the same way as for image frames. An application must choose one model or the other; it cannot use both models simultaneously.

To use the polling model:

  • A native C++ application calls NuiSkeletonGetNextFrame to retrieve a skeleton frame.
  • Managed code calls SkeletonEngine.GetNextFrame.
To use the event model:
  • C++ application code passes an event handle to NuiSkeletonTrackingEnable.

    When a new frame of skeleton data is ready, the event is signaled. Any waiting thread wakes and gets the frame of skeleton data by calling NuiSkeletonGetNextFrame. During this time, the event is reset by the NUI Skeleton API.

  • Managed code uses the event model by hooking a Runtime.SkeletonFrameReady event to an appropriate event handler. 
When a new frame of skeleton data is ready, the event is signaled and the handler runs and calls SkeletonEngine.GetNextFrame to get the frame.

The skeletal tracking engine processes depth frame data to calculate the floor clipping plane, which is described in “Floor Determination,” later in this document. If the application indicates at initialization that it uses skeleton tracking, the skeletal tracking engine signals a skeleton frame each time it processes the depth data, whether or not a skeleton currently appears in the frame. Applications that use the floor clipping plane values can retrieve the skeleton frame. The returned skeleton frame includes the timestamp of the corresponding depth image so that applications can match skeleton data with depth image data.

Active and Passive Skeletal Tracking

The skeletal tracking engine provides full skeletal tracking for one or two players in the sensor's field of view. When a player is actively tracked, calls to get the next skeleton frame return complete skeleton data for the player. Passive tracking is provided automatically for up to four additional players in the sensor's field of view. When a player is being tracked passively, the skeleton frame contains only limited information about that player's position. By default, the first two skeletons that the skeletal tracking system finds are actively tracked, as shown in Figure 4.

Figure 4.  Figure 4. Active tracking for two players

The runtime returns skeleton data in a skeleton frame, which contains an array of skeleton data structures, one for each skeleton that the skeletal tracking system recognized. Not every skeleton frame contains skeleton data. When skeleton tracking is enabled, the runtime signals a skeleton event every time it processes a depth frame, as described in the previous section.

For all returned skeletons, the following data is provided:

  • The current tracking state of the associated skeleton:
    • For skeletons that are passively tracked, this value indicates position-only tracking.
    • For an actively tracked skeleton, the value indicates skeleton-tracked.
  • A unique tracking ID that remains assigned to a single player as that player moves around the screen.

The tracking ID is guaranteed to remain consistently applied to the same player for as long as he or she remains in the field of view. A given tracking ID is guaranteed to remain at the same index in the skeleton data array for as long as the tracking ID is in use. If the tracking ID of the skeleton at a particular index in the array changes, one of two things has happened: Either the tracked player left the field of view and tracking started on another player in the field of view, or the tracked player left the field of view, then returned, and is now being tracked again.

  • A position (of type Vector4) that indicates the center of mass for that player. This value is the only available positional value for passive players.
  • For the actively tracked players, returned data also includes the current full skeletal data.
  • For the passively tracked players, returned data includes only basic positional and identification data, and no skeletal data. 
NUI Transformations

This section provides a brief overview of the various coordinate systems that are used with skeleton tracking and the API support that is provided for transformations between these spaces.

Depth Image Space

Image frames of the depth map are 640x480, 320×240, or 80x60 pixels in size. Each pixel represents the Cartesian distance, in millimeters, from the camera plane to the nearest object at that particular x and y coordinate, as shown in Figure 5. A pixel value of 0 indicates that the sensor did not find any objects within its range at that location.

Figure 5.  Figure 5. Depth stream values

The x and y coordinates of the image frame do not represent physical units in the room, but rather pixels on the depth imaging sensor. The interpretation of the x and y coordinates depends on specifics of the optics and imaging sensor. For discussion purposes, this projected space is referred to as the depth image space.

Skeleton Space

Player skeleton positions are expressed in x, y, and z coordinates. Unlike the coordinate of depth image space, these three coordinates are expressed in meters. The x, y, and z axes are the body axes of the depth sensor. This is a right-handed coordinate system that places the sensor array at the origin point with the positive z axis extending in the direction in which the sensor array points. The positive y axis extends upward, and the positive x axis extends to the left (with respect to the sensor array), as shown in Figure 6. For discussion purposes, this expression of coordinates is referred to as the skeleton space.

Figure 6.  Figure 6. Skeleton-space coordinate system for the sensor array

Placement of the sensor array affects the images that the camera records. For example, the camera might be placed on a surface that is not level or the sensor array might be vertically pivoted to optimize the sensor's field of view. In these cases, the y-axis of the skeleton space is usually not perpendicular to the floor or parallel with gravity. In the resulting images, people that are standing up straight could appear to be leaning.

Floor Determination

Each skeleton frame also contains a floor clip plane vector, which contains the coefficients of an estimated floor plane equation. The skeleton tracking system updates this estimate for each frame and uses it as a clipping plane for removing the background and segmentation of players. The general plane equation is:

  
Ax + By + Cz + D = 0

where:

  A = vFloorClipPlane.x 
  B = vFloorClipPlane.y 
  C = vFloorClipPlane.z 
  D = vFloorClipPlane.w

The equation is normalized so that the physical interpretation of D is the height of the camera from the floor, in meters. It is worth noting that the floor might not always be visible. In this case, the floor clip plane is a zero vector. The floor clip plane can be found in the vFloorClipPlane member of the NUI_SKELETON_FRAME structure in the native interface and in the SkeletonFrame.FloorClipPlane field in the managed interface.

Skeletal Mirroring

By default, the skeleton system always mirrors the user who is being tracked. For applications that use an avatar to represent the user, such mirroring could be desirable if the avatar is shown facing into the screen. However, if the avatar faces the user, mirroring would present the avatar as backwards. Depending on its requirements, an application can create a transformation matrix to mirror the skeleton and then apply the matrix to the points in the array that contains the skeleton positions for that skeleton. The application is responsible for choosing the proper plane for reflection.

posted by deviAk
http://support.microsoft.com/kb/238187/ko

작업PC(32비트)에서는 문제가 없다가 64비트 PC에서 컨테이너를 가져오지 못하는 문제가 발생하였다.

원인은 CryptAcquireContext 에서 컨테이너를 기본컨테이너(NULL)로 사용을 하였는데 이 부분이 64비트 컴퓨터에서는 제대로 정상 작동을 하지 않았던 모양이다.

해결책은 기본컨테이너를 사용하지 않으면 된다.
나는 유니크한 문자열을 얻기 위해서 GUID를 생성해서 생성한 GUID를 컨테이너로 넘기는 방법으로 처리 했다.
posted by deviAk

[VB] CyToday

Develop/CyToday 2008.09.12 18:02

[VB] CyToday Ver.1.1.3

CyToday?
+ 싸이월드 투데이 증가 프로그램 입니다..-_-;;
+ 악용하지 말아주세요...
+ 공부하다 어쩌다가 만든겁니다..-_-;;

디지털정보학 VB시험 대비 공부하다가 만든 프로그램
시험에 관련된 부분이 거의 쓰이지 않았지만...-_-;;
아무튼 VB공부도 할겸 만들어 본 프로그램
제작시간 약 2시간 30분

+ 프로그램 실행시 최신버전 확인
+ 인터넷 필히 설치 되어야 함
+ 악용 금지

[v1.1.3 - 2008/09/12]
+ 임시패치
(업데이트 확인 서버 변경)
+ 창열기를 누르면 제작자 싸이월드 오픈


[v1.1.3 - 2008/02/10]
+ 임시 패치
(업데이트 확인 서버 변경)


[v1.1.2 - 2007/01/19]
+ 버그 수정
(웹페이지 스크립트 오류가 뜨지 않도록 하였습니다.)


[v1.1.1 - 2007/01/18]
+ 버그 수정
(김학현님의 버그 리포트에 따라 오류가 낳던 부분을 수정하였습니다.)


[v1.1.0 - 2006/12/23]
+ 설정 자동저장 추가
(프로그램 종료시 자동저장 및 실행시 자동 로드)
+ 설치파일로 변경
(vb6ko.dll, msinet.ocx 포함 배포)
+ 제목표시줄에 버전표시


+ 버그리포트 및 건의사항은 댓글로 문의
 


+ 다운로드



 

'Develop > CyToday' 카테고리의 다른 글

[VB] CyToday  (20) 2008.09.12
[메뉴얼] Cytoday  (0) 2006.12.09
posted by deviAk

[VB] 택배조회 프로그램

Develop/VB 2006.12.10 16:43
사용자 삽입 이미지

[VB] 택배조회 프로그램 Ver1.0.1

택배조회?
+ 택배조회 프로그램입니다..-_-;;
+ 공부하다 어쩌다가 만든겁니다..-_-;;

디지털정보학 VB시험 대비 공부하다가 만든 프로그램
시험에 관련된 부분이 거의 쓰이지 않았지만...-_-;;
아무튼 VB공부도 할겸 만들어 본 프로그램
제작시간 약 1시간 30분



업데이트내역


Ver.1.0.2 - 2006/12/11

+ 로젠택배 추가
+ CJ  GLS 추가
+ KGB택배 추가
+ 옐로우캡 추가
+ 삼성택배 추가
+ 아주택배 추가
+ 운송장 저장기능 추가 예정


Ver.1.0.1 - 2006/12/10

+ 현대택배 추가
+ 한진택배 추가
+ 운송장 저장기능 추가 예정


Ver.1.0.0 - 2006/12/10

+ 프로그램 실행시 최신버전 확인
+ 인터넷 필히 설치 되어야 함
+ 운송장 저장기능 추가 예정



+ 버그리포트 및 건의사항은 댓글로 문의
 


+ 다운로드

'Develop > VB' 카테고리의 다른 글

[VB] 택배조회 프로그램  (6) 2006.12.10
[VB] 까보기  (0) 2006.12.09
posted by deviAk