ReconstructMe 0.4.0-188 preview

[Christoph Heindl]

Hi,

I have silently uploaded 0.4.0-188 and like the experienced user to this test first since I don't have a documentation yet. Here's the link

http://reconstructme.wordpress.profactor.at/?wpdmact=process&did=MzcuaG90bGluaw==

This version

 - adds Kinect for Windows support through MS Kinect drivers

 - adds support for selecting a specific sensor device

 - adds support for Near Mode when using the MS Kinect interface

 - fixes a couple of OpenNI related bugs.

First, this version is build against visual studio 10, so you need these runtimes

http://www.microsoft.com/download/en/details.aspx?id=5555 

If you like to test the MS Kinect drivers, you need to install the KinectSDK redistributables. It has 122MB in size which i find kinda huge, therefore I haven't uploaded it yet. Either download the SDK

http://www.microsoft.com/en-us/kinectforwindows/develop/overview.aspx 

or

try the browser plugin form zigfu (untested)

http://zigfu.com/browserplugin.html 

When running the realtime or record command you can now select the sensor device and driver to use through the '--sensor' switch.  Here are three examples

--sensor openni,0   (would open sensor 0 through OpenNI driver backend)

--sensor mskinect,0 (would open sensor 1 through MSKinect driver backend)

--sensor openni,1   (would open sensor 1 through OpenNI driver backend) 

When using the MSKinect interface ReconstructMe will try to enable the Near Mode feature, which is only available with Kinect for Windows. You can use the MS Kinect backend with XBox Kinect, but it is not officially supported. It will also limit the depth range between 800-4000mm.

My recommendations are

 - use the MSKinect backend if you own a Kinect for Windows

 - use the OpenNI backend in all other cases.

Note that you cannot have OpenNI and MSKinect installed together. OpenNI will stop working, because the MSKinect drivers get priority.

Happy reconstruction and please report back.

Thanks,

Christoph

[Christoph Heindl]

Am Dienstag, 6. März 2012 08:27:54 UTC+1 schrieb Christoph Heindl:

--sensor mskinect,0 (would open sensor 1 through MSKinect driver backend)

Oops, this would of course open sensor 0 through  MSKinect  driver backend.  Btw if you leave the --sensor switch away it defaults to openni,0

 

[Mark Schafer]

I get runtime error. I think I have vcredist_x86 installed.
Runtime Error !
R6030
- CRT not initialized

[Christoph Heindl]

Am Dienstag, 6. März 2012 08:56:20 UTC+1 schrieb Mark Schafer:

I get runtime error. I think I have vcredist_x86 installed.
Runtime Error !

Strange, did you try a reboot after installing the vcredist package?

[parapente]

Hi Christoph,

my new graphic card it's on, but now there is a problem...this is a log file (I installed ultimate driver from AMD;  it's a amd hd 5450 2gb):

[2012/03/06 14:07:11.562500][info ] Welcome to ReconstructMe
[2012/03/06 14:07:11.578125][info ] Running 0.4.0-167
[2012/03/06 14:07:11.578125][info ]
[2012/03/06 14:07:11.593750][info ] Licensed for non-commercial purposes only.
[2012/03/06 14:07:11.593750][info ] See 'License of ReconstructMe.txt'
[2012/03/06 14:07:11.593750][info ]
[2012/03/06 14:07:15.609375][info ] Starting sensor
[2012/03/06 14:07:21.093750][info ] Preparing environment for Device Cedar
[2012/03/06 14:07:21.125000][debug ] Preparing environment for Device Cedar
CL_DEVICE_VENDOR Advanced Micro Devices, Inc.
CL_DEVICE_VERSION OpenCL 1.1 AMD-APP (851.4)
CL_DEVICE_PROFILE FULL_PROFILE
CL_DRIVER_VERSION CAL 1.4.1664
CL_DEVICE_AVAILABLE 1
CL_DEVICE_GLOBAL_MEM_CACHE_SIZE 0
CL_DEVICE_GLOBAL_MEM_CACHE_TYPE 0
CL_DEVICE_GLOBAL_MEM_CACHELINE_SIZE 0
CL_DEVICE_GLOBAL_MEM_SIZE 1073741824
CL_DEVICE_LOCAL_MEM_SIZE 32768
CL_DEVICE_LOCAL_MEM_TYPE 1
CL_DEVICE_IMAGE_SUPPORT 1
CL_DEVICE_MAX_CLOCK_FREQUENCY 600
CL_DEVICE_MAX_COMPUTE_UNITS 2
CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE 65536
CL_DEVICE_MAX_PARAMETER_SIZE 1024
CL_DEVICE_MAX_WORK_GROUP_SIZE 128
CL_DEVICE_MAX_WORK_ITEM_SIZES [128, 128, 128]
CL_DEVICE_EXTENSIONS cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_atomic_counters_32 cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_popcnt

[2012/03/06 14:07:25.109375][error ] THROWING EXCEPTION: Throw in function (unknown)
Dynamic exception type: class LibOpenCLBridge::opencl_error
std::exception::what: Failed to create buffer.
[struct LibOpenCLBridge::opencl_error_code *] = -61
[struct LibOpenCLBridge::opencl_error_name *] = CL_INVALID_BUFFER_SIZE
[struct LibFundament::tag_robvis_message *] = Failed to create buffer.

ty for help

[Christoph Heindl]

Am Dienstag, 6. März 2012 14:11:34 UTC+1 schrieb parapente:

Hi Christoph,

my new graphic card it's on, but now there is a problem...this is a log file (I installed ultimate driver from AMD;  it's a amd hd 5450 2gb):

 

 I don't think this belongs to this thread , you are running version 167, this thread is about 188. Please start a new one.

Best.

Christoph

[parapente]

It's the same, unfortunatly.. I tried with all version!!

[MagWeb]

Having two devices plugged in here (And both Kinect Cameras are shown
in DeviceManager/Primesense)
I can run ReconstructMe using --sensor openni,0
but I cannot get ReconstructMe to find the second device via --sensor
openni,1
"Device id not found"

On 6 Mrz., 08:27, Christoph Heindl <christoph.hei...@gmail.com> wrote:

>  - adds support for selecting a specific sensor device

> When running the realtime or record command you can now select the sensor
> device and driver to use through the '--sensor' switch.  Here are three
> examples
>
> --sensor openni,0   (would open sensor 0 through OpenNI driver backend)
> --sensor mskinect,0 (would open sensor 1 through MSKinect driver backend)
> --sensor openni,1   (would open sensor 1 through OpenNI driver backend)

>

[Christoph Heindl]

Am Dienstag, 6. März 2012 17:07:12 UTC+1 schrieb MagWeb:

Having two devices plugged in here (And both Kinect Cameras are shown
in DeviceManager/Primesense)
I can run ReconstructMe using --sensor openni,0
but I cannot get ReconstructMe to find the second device via --sensor
openni,1
"Device id not found"

Ohh...a dumb bug. Just commited the fix, will have to wait for the build server to cylce and upload a new version in a couple of hours. 

[Christoph Heindl]

Am Dienstag, 6. März 2012 17:07:12 UTC+1 schrieb MagWeb:

Having two devices plugged in here (And both Kinect Cameras are shown
in DeviceManager/Primesense)
I can run ReconstructMe using --sensor openni,0
but I cannot get ReconstructMe to find the second device via --sensor

Hi MagWeg, I've uploaded a new version that should fix this issue

http://reconstructme.wordpress.profactor.at/?wpdmact=process&did=MzguaG90bGluaw==

Could you verify?

Thanks,

Christoph

[Christoph Heindl]

MagWeb I meant...

[MagWeb]

Thanks for the fast fix!

Able to run both devices at the same time using two CommandPrompt
windows.
Let´s check the speed.

[Christoph Heindl]

If you have two gpus, you use the --device switch to distribute work.

[GwebMa]

works also on one GPU - there´s only one :-( but it seems to be powerful - maybe there´s a slight difference in speed, but it is totally ok here.

I moved both devices with one hand, simply holding ones bottom to the bottom of the other (that´s why one window is twisted 180°):

http://img843.imageshack.us/img843/5937/twodevices.jpg

Great! Thanks!

[Mark Schafer]

have rebooted. also have two sensors configured and now using 191.
Same error :-(

The install seems to want to repair an existing install. as there are typically several of these installed for different verisons of visual studio - is there a place I should be putting it so your program picks it up ?
The installer doesn't give me any clues.
I am reluctant to uninstall and do from fresh as I expect other parts of my system will stop working...?

[j.roth...@googlemail.com]

Hi,
I use Kinect for Windows driver / Windows7 32bit and .net developing.
Also connected an Kinect for Windows, ReconstructMe.exe Build 188

I tried to run ReconstructMe.exe with follow command line:

ReconstructMe.exe --realtime --sensor mskinect,0

Got error message:
"xnContextRegisterForShutdown" in "OpenNI.dll" not found

I think the switch --sensor mskinect switch NOT USE OpenNI because openni I have removed from my computer

Any Idea? Thanks
Joerg

[Christoph Heindl]

Am Donnerstag, 8. März 2012 13:50:23 UTC+1 schrieb j.roth...@googlemail.com:

Hi,
I use Kinect for Windows driver / Windows7 32bit and .net developing.
Also connected an Kinect for Windows, ReconstructMe.exe Build 188

I tried to run ReconstructMe.exe with follow command line:
 
ReconstructMe.exe --realtime  --sensor mskinect,0

Could you paste the entire log?

[Joerg Rothballer]

Am Donnerstag, 8. März 2012 13:50:23 UTC+1 schrieb Joerg Rothballer:

Hi,
I use Kinect for Windows driver / Windows7 32bit and .net developing.
Also connected an Kinect for Windows, ReconstructMe.exe Build 188

I tried to run ReconstructMe.exe with follow command line:
 
ReconstructMe.exe --realtime  --sensor mskinect,0

Got error message:
"xnContextRegisterForShutdown" in "OpenNI.dll" not found

Problem solved! On my System was installed an old OpenNI 1.0 driver.
Christoph told me that without OpenNI no Error message.
In my case I removed OpenNI 1.0 and installed OpenNI 1.5
Now works great with "Microsoft Kinect for Windows" !!!
Thanks for Support Christoph 

[geertv...@gmail.com]

Works fine with two command screens openen on one GPU for as well two Xtions or Kinects. I will test it when I have the time with three devices (if reconstructme allows this) but now, as this works fine, the next step is logic:
You can avoid stitching if you can make an extrinsic kalibration possible op the multiple devices you are using. For the moment, there is only the intrinsic calibration for each device that is done by the OpenNi calibration matrix you probably use. The extrinsic calibration allows you to stitch the frames immediately to each other from the two devices. Extrinsic calibration can be done before starting scanning by making a scan from a certain object that is partialy seen by all sensors and the overlap can be used to align the different scans manually. The moment that the scans are aligned, you can automatically calculate the relative positions from the different sensors to each other. You can store these coördinates in an extrinsic calibration file and as long as you keep the relative position from the sensors constant to each other. This file can be used to stich all the frames together, real time or after recording as you will now the positions from the tsdf volumes from each sensor to each other and the voxels in the grid that are overlapping.
Thanks for your nice software and the quick new releases with extending possibilities.

GVdB

[Christoph Heindl]

Am Freitag, 9. März 2012 17:00:50 UTC+1 schrieb Joerg Rothballer:

Problem solved! On my System was installed an old OpenNI 1.0 driver.
Christoph told me that without OpenNI no Error message.
In my case I removed OpenNI 1.0 and installed OpenNI 1.5
Now works great with "Microsoft Kinect for Windows" !!!
Thanks for Support Christoph 

Note, this was a bug and is solved in trunk. If you intend to use KinectSDK there should be no need to install the OpenNI backend. But I'm happy it works now. I've also found an issue in the calibration, that will not allow you to do higher quality scans. Before updating this, I will need to straighten out some other things. 

[geertv...@gmail.com]

Hello Mr. Heindl,

Is there any possibility that my previous remark will be discussed by the devellopers and maybe implemented in one of the next releases?
GVdB

[Christoph Heindl]

Am Mittwoch, 14. März 2012 14:12:04 UTC+1 schrieb geertv...@gmail.com:

   Is there any possibility that my previous remark will be discussed by the devellopers and maybe implemented in one of the next releases?
GVdB

We will keep them in mind, but we don't have an immediate plan to implement them. We consider the system simple as long one sensor is used and preferable a standard calibration  (intrinsics for rgb and depth, and extrinsic between the two sensors). Adding multiple sensor support would require an extrinsic calibration (either manually, or through automatic matching) between them, which a lot of people would not be able to do or perform. I'm sure there are use-cases for such situations (you seem to have one, could you elaborate?), but we are not sure whether they are worth the hassle.

We do have systems in house (PROFACTOR - ROBVIS) that can do partial surface matching under arbitrary transformations, which could help in this respect. If you are interested in such methods, drop me an e-mail. As i said earlier, I doubt that these methods will find their way into ReconstructMe in the near future.

Best,

Christoph

[Mark Schafer]

Oh I am sorry to hear that :-(

[Mark Schafer]

My use cases here: https://groups.google.com/forum/#!topic/reconstructme/288WnqEsB5g