I was wondering, in what direction is going the opensource kinect
community? How are libfreenect/OpenNI going to interact ? Will
libfreenect keep including new features, taken from OpenNI source
code? Do they have a focus that is different enough to justify two
different projects, or will the two projects end up merging into a
single one ?
I must admit that right now it is unclear to me whether as developers
we should keep using libfreenect or start switching to OpenNI (letting
the skeleton tracking part aside).
Any insights?
Cheers,
Nicolas
I was wondering the same thing. In my opinion, there is a lot of value in
having both projects exist in parallel. OpenNI is significantly larger and
more complex than libfreenect, and depending on the application, that may
either be an advantage or not. I think that having libfreenect as a lightweight
HAL layer and OpenNI as a more full-featured alternative is fine.
Ideally, I would hope that the new features from OpenNI get merged into
libfreenect over time, making an integration at some point down the road
easier (i.e., libfreenect as the low-level access library and OpenNI as
the dataflow system on top).
Florian
--
SENT FROM MY DEC VT50 TERMINAL
On 12/10/2010 08:29 AM, Nink wrote:
> Libfreenect is apache2 with an option of gpl2. Please do not take any code from openni and merge with libfreenect. You are welcome to fork the code and create a new version under gpl but to merge openNI into Libfreenect would not be possible.
>
> Libfreenect is not far behind openNI and has support for motor etc. The project is still very valid especially if you want to develop a commercial product and not have to release your source code.
OpenNI is not GPL :) It's LGPL on purpose, so that it can be used in commercial products.
Cheers,
Radu.
--
http://pointclouds.org
Complete the part companies like about LGPL !
But if you dynamically link to the library, you can have you code in
any license you want.
Even closed and proprietary ones.
So just modifications to the library itself should be published.
i
The skeleton extraction is the most important thing in all "OpenNI",
so with having it closed source, that library should change its name
to ClosedNI which reflects better the state.
(Freeware != GNU's Free Software)
Otherwise, what are the things that are really open source and not
available in libfreenect?
(I really wish here I am wrong...)
i
From a technical standpoint, OpenNI's driver doesn't have much to offer
over libfreenect. Although it supports many other features, it turns out
most of those either are useless (e.g. the compressed YUV format that
barely compresses and doesn't buy us anything) or aren't implemented on
the Kinect firmware (as far as I can tell neither frame sync nor
registration nor JPEG are implemented, etc.). I suspect we're at about
85% functionality for the video portion of the Kinect in libfreenect at
this stage. We'll figure out if we can sanely get some reasonable images
in the higher-res modes, interpret the calibration data and other
parameters, maybe make initialization more reliable... and that's about
it as far as things that OpenNI/Sensor does. The PrimeSense firmware
really has a very different feature set from the Kinect, even though
they both come from the same base.
The two projects are definitely not going to merge, as their focus is
entirely different: libfreenect aims to provide a simple,
straightforward C interface to the Kinect, while Sensor is a heavyweight
driver attempting to implement all features of the PrimeSense reference
design and plug into OpenNI, a complex C++ framework. However, we'll
probably see some places where they complement each other. Specifically,
libfreenect might end up taking advantage of the Windows kernel driver
portion of Sensor, and/or OpenNI might gain a libfreenect backend.
It's worth noting that the OpenNI/Sensor license is more restrictive
than the libfreenect license and as such no code will be taken directly.
We'll just reimplement whatever features we find useful using Sensor as
hardware documentation.
From a personal standpoint, I don't see much of a point to OpenNI. It's
(yet another) framework, but it does no actual processing that's useful
to us. The interesting bit (skeletal tracking) is closed source, so the
only real point to using OpenNI right now is to be able to plug into
that closed source blob. And heck, reading Sensor code just isn't fun.
--
Hector Martin (hec...@marcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc
- if one wants to get access to raw sensor data from a kinect, then
use the lightweigth libfreenect.
- if you want to get access to skeleton tracking and "natural
interface features", then use Open_Natural_Interface.
Hopefully one day the skeleton tracking part will also be a simple
self-contained module on top of libfreenect, since I guess most people
don't actually want a full framework at that low-level stage, but just
pick up the features they need for their own app.
So I'll stick with libfreenect for the moment, hopefully with windows
support in the master branch soon :-)
Cheers,
Nicolas
"NITE is indeed PrimeSense's OpenNI compliant middleware product and asfor now it is not released as open source. The supported systems areWindows and Linux and the R&D team at PrimeSense is now evaluating OSXdue to community requirements.The license for NITE allows re-distribution of the redist version andalso free usage of the NITE SDK.OpenNI compliant NITE can be downloaded from PrimeSense's website:http://www.primesense.com/?p=515 and a free to use key for thecommunity can be found on www.openni.org.That key is:0KOIk2JeIBYClPWVnMoRKn5cdY4=hope this helps!TamirBOpenNI Forum Manager"
"The current license for NITE allows distribution of the redist! (which will be available later on) the only requirement is that you make sure the redist’s EULA is signed by the end user (which happens automatically if you use our installer)"