Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix kinect recording oni for NiTE 2.2 #80

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

KHeresy
Copy link

@KHeresy KHeresy commented May 21, 2014

The ONI file recorded from Kinect sensor can't work with NiTE 2.2 because leak the property XN_STREAM_PROPERTY_PARAM_COEFF.

This patch fix this issue.

@KHeresy
Copy link
Author

KHeresy commented May 21, 2014

The pre-build dll could be download here
https://github.com/KHeresy/OpenNI2/releases/tag/KinectOniFix

Just replace original kinect.dll in OpenNI2\drivers
It should works for both OpenNI 2.2 and 2.3

@piedar
Copy link

piedar commented May 21, 2014

I think this repo has been abandoned. You should also make a pull request to occipital/OpenNI2.

@KHeresy
Copy link
Author

KHeresy commented May 23, 2014

Here is a small program to fix existed ONI files

https://github.com/VIML/oniFixer

It use the VirtualDeviceForOpenNI2 project (https://github.com/VIML/VirtualDeviceForOpenNI2), open the exist ONI file and create a virtual device to record it again with all required properties.

@huangfuyang
Copy link

Why ignored by primesense? It is a critical bug which causes corruption each time when you play an ONI file under NITE. Previously, I just manually set XN_STREAM_PROPERTY_PARAM_COEFF to 4.
PS. Thank you Hersey. I learn a lot from your tutorial.

@tomoto
Copy link
Collaborator

tomoto commented May 23, 2014

See #83 . What do you think, Heresy, Benn?

@KHeresy
Copy link
Author

KHeresy commented May 23, 2014

to piedar

Thanks for reminding.
I know occipital start to handle the OpenNI C++ code.
I didn't make pull request to them just because I didn't merge there updated code first.

@davudadiguezel
Copy link

hi,
I managed to get your VirtualDevice running on Linux (kubuntu 14.04), but Nite2 seems to have a hard time finding users in recordings. Sometimes it doesn't find any, sometimes it takes half the recording to find some and sometimes it loses them right after finding them. I guess, the problem is somewhere in the VirtualDevice, because I found a .oni file somewhere in the internet and Nite2 is tracking fine on it. But when I send the same file through the VirtualDevice no user is found.
Does somebody have any ieda to that problem?

@KHeresy
Copy link
Author

KHeresy commented Nov 3, 2015

When using VirtualDevice , it may make the duration between frame and frame increase, depend on what you do with each frame.
This may make NiTE hard to tracking.

I think you may try to reduce the computational complexity, and check if it work better.

@davudadiguezel
Copy link

hey heresy, thanks for the replay.
Right know I am using the UserViewer Sample that comes with Nite2 and combine it with your Nite Sample and the virtual device. I feed Nite with a virtual device that comes with properties copied from a real device and depth data from the actual .oni file that I want to run with nite.
I also have an .oni file from somewhere in the internet that I can give directly to nite and it's working like a charm. When I pipe it through your virtual device no skeleton is tracked at all.
I tried to find complexity, that I could eliminate, without any real success. All I am doing is load the devices and copy parameters and data.
I also use this function to copy framedata:
openni::DepthPixel* pImg1 = reinterpret_cast(rF1.data);
openni::DepthPixel* pImg2 = reinterpret_cast(rF2.data);

int dataSize=rF1.dataSize;
memcpy(pImg2,pImg1,(size_t)dataSize);
I found it here:
https://getsatisfaction.com/openni/topics/nite2_usertracker_crashes_when_reading_from_oni_files
The function that came with your samples didn't work unfortunatly. Do you have any other idea why the tracking performance is so bad on recordings for me?

@davudadiguezel
Copy link

ok. previously I fetched the .oni file from my network and was a bit slower than data from the kinect. now I get it from local files, that is even a little faster than kinect, but still not tracking.

@davudadiguezel
Copy link

Also tried to get it the framerate at the same speed as with kinect, but didn't improve tracking either. Do you have any other ideas on why it's not working?

@KHeresy
Copy link
Author

KHeresy commented Nov 6, 2015

If what you need is just make ONI work with NiTE, I would recommend try use KinectOniFix to process the ONI file before use it.
https://github.com/KHeresy/OpenNI2/releases/tag/KinectOniFix
In this way, you don't need to use VirtualDevice in your code.

@davudadiguezel
Copy link

I tried that, too, but when it reaches the point where it wants to close the physical device it stops without any error message. Just doesn't do anything anymore.
Furthermore I need not to do only .oni files, but also .bmp recorded with the old kinect. I used your virtual device for this and it worked partualy.
Lately I found out, that these old kinect .bmp - files where recorded with only 7 fps. Sorry, that late information, but I learned about it myself just the other day. Could this be the reason for the bad performance and can I somehow cope with it? I already tried to reduce fps on my virtual device and any other stream without any success.

@KHeresy
Copy link
Author

KHeresy commented Nov 9, 2015

NiTE is a black box, it has lots of usage limits.
For example, it only accepts some resolutions(VGA, QVGA).

I am not sure what would happen if you give it 7fps depth data.

@davudadiguezel
Copy link

ok. thanks anyway.

SebasRatz pushed a commit to SebasRatz/OpenNI2 that referenced this pull request Aug 29, 2018
…devel

Add a simple roswtf plugin that checks the number of connected devices
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants