nrocy / processing-openkinect

Processing library for OpenKinect
53 stars 3 forks source link

Pull request #3

Closed dubois closed 13 years ago

dubois commented 13 years ago

Here's the request you asked for. Does github not allow you to pull otherwise? Or is this just the easiest way?

nrocy commented 13 years ago

Thanks! I'm out tonight but will try to get this merged on Thursday :)

nrocy commented 13 years ago

Started looking through this, looking good :)

One question:

The depth data is 11bit I think. While this'll fit into a 16bit short, they're signed (thanks to Java) so the data will run -32,768 to 32,767. I'm guessing your usage in the processing sketch is something like:

short[] depthData = NativeKinect.getDepthMapRaw(); ?

I think it'd be better to use an int so that we can return 11-bit positive numbers, what d'you think?

Have you an example sketch that I can use to test?

Cheers,

nrocy commented 13 years ago

Good lord, don't know what I was smoking when I suggested the int stuff. We only lose a bit to signed numbers.. please ignore.

Must sleep more.

dubois commented 13 years ago

Are you sure? Technically kinect says it can return a depth of 8192. In practice it won't get that high but I have seen depths that must have been > 4096 which is 12 bits. Certainly it can get higher than 11.

That said, my desire for the raw came from me wanting something as unprocessed as possible. Iterating over texels copying and embiggening them takes time (and memory) and isn't necessary as long as the user is aware of what kinect might return. Note that the top bit isn't really "lost"... it just means the high 16 bits should always be masked off after int conversion.

p

On Sunday, April 17, 2011, nrocy reply@reply.github.com wrote:

Good lord, don't know what I was smoking when I suggested the int stuff. We only lose a bit to signed numbers.. please ignore.

Must sleep more.

Reply to this email directly or view it on GitHub: https://github.com/nrocy/processing-openkinect/pull/3#issuecomment-1016606