search

ofTheo / ofxKinect

legacy openFrameworks wrapper for the xbox kinect (OF pre-0.8.0+ only) - ofxKinect is now included and is being maintained in OF releases
MIT License
540 stars 105 forks source link

move depth processing out of ofxKinect into separate addon #39

Closed kylemcdonald closed 12 years ago

kylemcdonald commented 13 years ago

i'm planning on moving the depth processing, registration, manipulation stuff into a separate addon called ofxDepthUtils, and making ofxKinect the absolute minimal code required to get the kinect talking to OF. this way people can swap out ofxOpenNI for ofxKinect and still have all the useful tools for manipulating and rendering stuff. it should clean up of ofxKinect a bunch, too.

i think it's mostly been arturo and i developing this, and he's on board -- but i'd love to hear if anyone else has any ideas.

danomatika commented 13 years ago

How is that cleaner? ... then people have to download 2 addons if they want to do basic stuff. It isn't possible to just be able to disable any of the built in depth processing? Or better yet, have something like an ofxKinectDepthProcessor class that you load into ofxKinect which provides a way to swap out a default processor with an OpenNI or custom processor, etc ...

It makes more sense to me to keep it together unless you plan to make it truly "generic", but I can't think of any other system so far that would use it besides your dual RGB camera setup.

kylemcdonald commented 13 years ago

"unless you plan to make it truly 'generic'" yeah, this is exactly, what i had in mind :) i'd like to encourage people to try different acquisition systems rather than limiting them to the kinect. especially because i have work from ofxStructuredLight that intersects with ofxKinect and belongs in an intermediate space.

downloading multiple addons can be avoided by simply posting a single zip with both included.

danomatika commented 13 years ago

If that's your plan, the I'd suggest that each depth addon takes an ofxDepthProcessor object which can be derived for different processes. This way it's easy for others to add new ones ... and ofxKinect can come with a variant by default so basic users have a working system out of the box.

I33N commented 13 years ago

It's a very good idea, in my opinion, since the release of ofxKinect and ofxOpenNI, I have been using both and had to adapt basic depth processing algorithm for both output. Would be a lot easier to have one class wich take depth map independently of the hardware... then it could be adapted to other time of flight camera, to stereo system, structured light or even more complicated multi-camera setup!

danomatika commented 13 years ago

Kyle, this is done now right? Can we close this issue?

kylemcdonald commented 13 years ago

no, this hasn't even been started yet afaik.

danomatika commented 13 years ago

Oh right, I was thinking just the folder restructuring .. dohh.

danomatika commented 12 years ago

OK, this seems to be a moot point now that we are moving to the updated freenect that has onboard depth processing.