Closed arturoc closed 12 years ago
since libfreenect supports calibrated millimeter data, depthPixelsRaw is now 0..10000 mm (0 to 10 meters)
distancePixels is just a floating point version of depthPixelsRaw, and is more for convenience. it should have exactly the same range (0..10000) and i think if you do it the way you suggest with the equals operator then it will be converted to the wrong range.
mmh, yes i guess it makes sense for calculations in meters, i was actually using it to get float images so you can record the depth or do analisys over a float image instead of the unsigned char one. if you pass the current one to opencv and try to do operations with it then convert to unsigned char it freaks out. same if you try to draw it.
what if we had to versions that are lazily initialized (so it doesn't consume too much resources), one for meters the other for analisys/saving?
El 16/03/12 17:08, Kyle McDonald escribió:
since libfreenect supports calibrated millimeter data, depthPixelsRaw is now 0..10000 mm (0 to 10 meters)
distancePixels is just a floating point version of depthPixelsRaw, and is more for convenience. it should have exactly the same range (0..10000) and i think if you do it the way you suggest with the equals operator then it will be converted to the wrong range.
Reply to this email directly or view it on GitHub: https://github.com/ofTheo/ofxKinect/issues/91#issuecomment-4542536
if you want to record raw depth images, you should be using the unsigned short version, not the float version. the unsigned short version will be half the file size.
if you want to do opencv operations, it depends on the kind of operations, but i would probably use the 8-bit depth image unless i was doing something like gaussian blur. for gaussian blur i would use the floating point image, and then convert it to 0-1 just before visualizing it. the conversion to 0-1 should always be the last step, otherwise you can never get a meaningful value in millimeters, and all your operations are using arbitrary numbers.
in general i think it sounds like this is stuff you should be doing outside of ofxKinect. giving ofImage_ a normalize() function might be a better direction to take :)
in line 504 https://github.com/ofTheo/ofxKinect/blob/master/src/ofxKinect.cpp#L504 when getting the depth data it's doing:
so the range of the float image is 0..65535 or whatever is the max in the raw input. shouldn't this be 0..1?
just changing these lines to:
does the trick since the = operator in ofPixels transforms the short pixels to float correctly.