So I was hanging out this cold and dreary Saturday afternoon and being the geek that I am... :)... was just browsing around catching up on 2D bar coding developments.
I happened to stumble across this link about a new 2D encoding standard called "MoseyCode"
(in the first breath I went - Oh brother just what we need yet another 2D encoding standard.....even if he Tom Gibra is releasing it without any patent encumberances).
Have a read below
What was interesting however is this
Although Peter's blog post doesn't explain it very well what you are seeing is the the introduction of a 3rd axis.
Instead of 2d codes just having X & Y axis information, the Moseycode can tell when the information is 'tilted' and introducing a Z axis.
The Cube in the video above is being superimposed on the Moseycode Card itself, allowing for a 'visual superimposement' on the Android display of any object you decide to 'upload' (I have questions about this as per my post reply below-so looking forward to understanding the limitations).
Now whilst I have very big concerns about the 'functionality' of this and the usefulness in a number of situations about this - there are certain areas where this has some very neat uses.
I wanted to post on my blog the reply I sent to Peter. I will also be sending Tom Gibara some questions and will post below in the comments further information as it comes to hand but like I said.....interesting and I thought it might interest a few of you out there.
At first I was prepared to dismiss this as yet another proprietary 2d code.
I read Tom's documentation (as brief as it is) and whilst it has some interesting points there I think (honestly it's only a guess as the information provided at the moment isn't enough to actually make a conclusion) that what is occurring in these videos is the android OS is downloading visual information from a web server and inserting it into the x,y,z axis.
Whilst this is neat and 'nice' (particularly the 3 dimensional cube demonstration- for reasons too lengthy to go into here), it doesn't allow for 'inbuilt' coding of any more information at 96 bits than other standards.
2d codes are often about providing information 'on the spot' in a self contained situation without needing to go 'out elsewhere' to gather information.
I love that Moseycode is going to be free of patent constraints and I love the 3d (really the Z axis) component but wonder if this is going to be enough......would also be very interested in understanding the ramifications of moving the code to other backward mobile OS (and what kind of physical constraints are required for the camera hardware).
Thanks for bringing it to my attention, will be looking with interest as this is further developed.