Coordinates {x, y, z} - what is the z value?

[martincox]

Hey

Messing around with coordinates and wondering what the z value denotes? It's either -1.0 or 1.0. I thought that it might be an indicator of the LED being picked up by the camera mapping, as in the app it displays a message along the lines of "N out of 250 lights detected".

Anybody have any ideas? I've looked through the protocol and library docs, but can't see that it explains anywhere.

Apologies for raising as an issue, not sure where else to ask questions without discussions.

Thanks :)

[Anders-Holst]

As far as I have managed to figure out, I make the same guess as you: For two dimensional mappings the z-coordinate appears to be reused for marking if it has a reliable position from the camera or not. 1 means reliably detected, -1 means that it is not so reliable, but somehow it is estimated anyway because it still has x,y-values although often not so good. (I was even able to manually correct the -1:s coordinates through the use of the rest protocol calls, by relating them to nearby leds - a painful manual process but fortunately it was only a handful of them.)

For three-dimensional mappings it is of course the z ("depth") coordinate. There seem to be no extra coordinate corresponding to a similar "accuracy flag" in the 3D case.

By the way, the aspect-xy and aspect-xz seem to have disappeared in the protocol at some version. Does anyone know when this happened? I think of writing an update to the docs to this effect. The aspect would be needed to get accurate slants of patterns, and the x and z coordinates ar always normalized to [-1, 1] whereas y is normalized to [0, 1].

[JLOrwell]

As far as I have managed to figure out, I make the same guess as you: For two dimensional mappings the z-coordinate appears to be reused for marking if it has a reliable position from the camera or not. 1 means reliably detected, -1 means that it is not so reliable, but somehow it is estimated anyway because it still has x,y-values although often not so good. (I was even able to manually correct the -1:s coordinates through the use of the rest protocol calls, by relating them to nearby leds - a painful manual process but fortunately it was only a handful of them.)

For three-dimensional mappings it is of course the z ("depth") coordinate. There seem to be no extra coordinate corresponding to a similar "accuracy flag" in the 3D case.

By the way, the aspect-xy and aspect-xz seem to have disappeared in the protocol at some version. Does anyone know when this happened? I think of writing an update to the docs to this effect. The aspect would be needed to get accurate slants of patterns, and the x and z coordinates ar always normalized to [-1, 1] whereas y is normalized to [0, 1].

They are still there but you can't read them. You still need to set them though if you are writing layouts to the string. The only source to get this data is the web api.