We never really thought about it before, but a traditional barcode or QR code is pretty two dimensional. A 3D barcode sounds like marketing hype but the JAB (Just Another Barcode) system adds a third dimension in the form of color.
Traditional barcodes assume you have a pretty crude sensor, but a color camera now days is no big deal, so why not take advantage? The JAB system specifies two types of symbols: a master symbol and a slave symbol. A master symbol has four finder patterns at the corner. Slave symbols dock to a master or another docked slave.
If you want to create some JABs, there’s a web interface. If you check advanced, you can change the number of colors used, the size of each “module” (colored box), and the width and height of the master symbol. You can also arrange for error correction. The grid that shows the master and slave symbols will allow you to click on any dockable slave location to create more symbols with different attributes.
You can then save the JAB image and use the scan menu item (at the top) to read the code back. It will also read from a camera.
If you are using a color camera and a computer or phone to read barcodes, this probably is something to check out. After all, you are acquiring color data, why not use it?
You might think of the barcode as something modern, but it has a long strange history going back to the 1930s. Early barcodes looked like bullseyes and were actually inspired by Morse code. We wonder how one of these would look on someone’s arm in ink?
This prior art comes to mind… https://en.m.wikipedia.org/wiki/High_Capacity_Color_Barcode#Microsoft_Tag
Not to mention KarTrak, CrontoSign or many, many other symbologies that make use of colour.
Glad this never took off. Tracking built-in for everything, versus QR codes which are only most of the time tracking you. Plus, one less Microsoft-branded thing spread everywhere.
I see a major problem with this. And that’s that as a human, I just see a random blob of colors. Anyone who sees a QR code, instantly knows, that’s one of those silly scanable things.
Also, information density seems to be quite low, I would expect a JAB code with the same data as a QR code to be much smaller, but it isn’t.
Another problem is color accuracy in printing and even just fading.
Hmm…Just thought of the challenges a bit…
I think limiting to an 8-bit pallet maybe the answer there… also calibration strips around each edge could help both with fading and colour accuracy.
Or just limiting the number of colours for maximum contrast between each colour. Take for example a 6-colour barcode I would think should be a bit more immune than a 256-colour barcode for fadeout issues. Add in calibration bands around the barcode and the immunity to fading goes up.
Now, the downside is I wouldn’t know how to fit number-of-colours to number-of-data-bits. so no data bits are wasted… i.e. a pallet that is half byte aligned or byte aligned, where 2 squares make a byte with higher contrast or one square aligns to a byte with less contrast between colours.
Also, I’m in need of recapping on the VGA mode 13h to know how colour fits in with pixel data as it’s the reverse of what I’m guessing here.
Touched on. Home color printers cost more.
I think if the algo behind this takes into account of color-matching. At least I am sure there is some clever way to make this quite good with good math.
As far as I can tell from a basic test a qr code requires double the resolution in each dimension to record the same message. So I guess it is smaller, just not presented that way on screen.
But, the bayer pattern inside the camera -also- requires double the resolution to get the same resolving pattern. Add to this the influence of extranous light which skews color perception, the fading of colors due to UV light.
Barcodes excel in reliability, not data density.
Once upon a time, printed computer magazines distributed code for games or programs as machine-readable patterns, requiring a reader. I never had the opportunity to use this, but as I recall the reputation was for great density (saving you typing in hundreds of lines of code), but a bit finicky to use.
Remember 3D FAX? That could FAX computer files, in black and white or color. The transmissions could be decoded after reception by a FAX modem or they could be printed from a FAX machine then scanned into a computer with the decoding software. I bet current smartphones could (with software that understands the encoding) decode 3D FAX pages like they can QR and other codes.
The decode only software was free. They had a test/demo send program that could only send one built in file. The full program cost money. Unfortunately the web archive saved none of that.
I’ve been trying to find a copy of 3D FAX for years. Making the encoding it used open source would be a neat thing. Add encryption to it and files like word processing documents could be securely stored in locking file cabinets. One would have to take the pages from a folder then scan/decode with a password to work on them.
One use case would be sending an editable file to some remote place that only has a landline, no internet access by any means. Decode, edit, reencode and FAX back the edited document.
https://en.wikipedia.org/wiki/3D_Fax Version 1.0 could do 40K per page. Version 2.0 could do 110K per page, modem to modem. That was with compression so a file larger than 40K or 110K could only need one page. I wonder how much that could be improved?
Ah, here we go. Intacta.CODE, based on Infoimaging 3D FAX. https://robertianhawdon.me.uk/2015/09/28/releasing-intacta-express-reverse-engineering-story/
“One use case would be sending an editable file to some remote place that only has a landline, no internet access by any means. Decode, edit, reencode and FAX back the edited document.”
If you are using a landline to transfer the data via a fax modem then you could use a computer modem instead and you could transfer far more information and it would be more reliable.
Over here something similar is used in online-banking:
https://nl.wikipedia.org/wiki/Rabo_Scanner
It is a pretty clever system since the device that generates the digital signature is not physically connected to the computer, but does display the transaction information.
But that same bank has now totally blown it by running radio commercials for there phone app, that they claim is just as secure because it uses encryption between the phone and the bank. But it does not make use of the external device to generate the signatures so the security is only similar if you consider your phone (that also runs countess randomly downloaded apps) just as unhackable as the external signature device.
As the author pointed out: it´s a while we have cheap color cameras but this technology never raised. There are a couple of reasons for this:
– lighting: to interpret colors correctly you need a consistent source of light. LED, metal vapor, sun, flu tubes, halogen… all make for a different color rendering, where B&W barcodes can be very reliably read with any illumination.
– then comes the colors themselves: most printed colors fade away in weeks to years, depending mostly how much UVs hit them. While more expensive pigment ink can mitigate this effects, they still mostly change color over the time, unless they get a costly UV filter coating.
So, it´s unlikely that this technology will take up, especially that in a 2D barcode one cn put enough information for almost all uses. Need more? there´s RFID.
office printers monochrome
A bank in the Netherlands uses these for a two-factor wire-transfer reader.
It works pretty wel!
https://www.ikgastarten.nl/sites/default/files/styles/content_top/public/homepage_36.png
Interesting, but this looks, like each dot can only have one of the primary colors (red/green/blue/”white”) whereas above code can even mix the primaries.
commerzbank in germany also uses this method.
Yep, wanted to mention that as well.
The use of only primary colors is simply because they are easier to process. Using more colors means that your algorithm needs to be able to discriminate more colors. Shouldn’t be too hard. But requires a more powerful processor and costs more battery, etc. So it’s just a design choice, not a feature of one QR code type over another.
And to be honest, most likely there is not even an algorithm for color discrimination right now. Because the pixels already come in R G B form from the camera, I’m sure.
But what really struck me, is that the reader in the image is showing a different barcode than the phone is showing. :D
According to wikipedia it’s a different format: CrontoSign (also called photoTAN)
https://en.wikipedia.org/wiki/Barcode#Matrix_(2D)_barcodes
So…
What happens when it scans a Mondrian painting?
You get all the Bitcoin
Colours work worse the less light there is and they tend to fade, especially in sunlight. QR-codes and the likes are great because they work well even in low light and even if they’ve faded in sunlight, and they don’t even care if parts of the code have gotten miscoloured by e.g. a little kid with a pencil. These multicoloured blocks don’t seem nearly as robust.
Won’t bother checking, but how about color fidelity? The only solution of inevitable color infdelity due to pigment fading or display night mode would be through using colors differentially, e.g. not reading absolute RGB values, but rather their differences.
The reader that Michiel145 mentioned (of the Dutch bank), does not survive night-mode. In night-mode, it cannot read the QR code correctly, I have to switch it off before scanning.
But I also feel that there is some additional security by being so strict on color fidelity. For instance, being strict on color fidelity will probably make the device fail to scan from printed paper. The bank’s device is only meant to be used on a computer monitor, through their web application.
what about monitor colour correction? not all monitors display the same shade of white as white.
The difference between emission and reflection.
Traditional barcodes are 1d, the scanner doesnt care how tall you make them, and 2d systems use monochrome camera’s for resolution and speed. which is why something like a cognex brand scanner can pick up a 3mmx3mm data matrix whizzing by on a conveyor a few feet away
the problem with colour is and has always been colour accuracy. Screen fade, lighting, print fade, print medium(paper colour) could all potentially affect the reading of the barcode. This would get worse as you increase the number of colours in the bar code. As mentioned above, some banks are using it with the primary colours, but the more colours that you add the greater that these things will affect the reading of the barcodes. The benifit to black and white (or any other monochrome) barcodes is that they are readable in a great many number of environments (dirty, clean, under waterm etc) because of the high contrast and the ability to make discrete scanners to read said barcodes. This technique seems limited to phones and tablets but i could be wrong.
as long as its well lit its a good idea, if its not well lit those blues are going to be a problem
I’m thinking of the long term stability of the inks used in home printers, and how they fare under sunlight.
It works great, I’m sure when you first print it, but leave it near a sunny window for a few months and will you still be able to get a read from it when colors fade?
I’ll stick to QR’s for now.
I have wondered why use squares instead of hexagons or triangles.
Add some color foil to this to make for a great stegano-encoding :D
Kewl variation of ours . We use png image files, use python code to encode and decode them. A normal phone camera can decode them too, which is what our android app tries to do. We also encrypt the tripplets into 16m variations with rotatinn casacading sequences. Hence pretty much uncrackable.
Mono supports more kinds of printing. Standard was/resin on robust tags; etch onto metal; work with any shade or colour of backing; subtle appearance if desired… The banking examples above are great in their context – showing dynamically on a backlit or OLED screen.
It reminds me in the cartoons whe the TV screen is staticy