Recently [mit41301] wondered about increasing the data capacity of QR codes, and was able to successfully triple the number of bits using color. He chose the new rectangular micro QR code (rMQR) standard which was adopted last year as ISO/IEC 23941:2022. This rectangular-shaped QR code is designed to be used on narrow spaces, with an aspect ratio similar to that of a traditional 1D bar code. There are quite a few variations of rMQR, but the largest can hold 361 bytes. The basic idea is to generate three different rMQR codes, coloring them as red, green, blue, and merging the result. Decoding is performed by separating the color image into its RGB components and then decoding the resulting three images.
To do these experiments, [mit41301] took advantage of readily available tools. Generating rMQR codes can be done with this Python module by [Takahiro Tomita], who also makes the generator available online. Or if you’re more comfortable with Go, check out this repository by [Ichinose Shogo]. As a proof-of-concept, [mit41301] takes the first 449 digits of pi, plus the decimal point, and splits them into three each 150 byte chunks. Then he uses the image manipulation program ImageJ, an open-source Java program developed at the National Institutes of Health, to implement the combination and deconstruction processes.
There might be a few pitfalls if you want to do this outside the laboratory, however. First of all, this standard is reasonably new, and after a brief search this author couldn’t find any decoder that would recognize rMQR codes, nor any software modules or libraries. Research into colorization of QR codes, known as HCC2D (High Capacity Colored 2-Dimensional) codes has been ongoing. One issue is that correcting for arbitrary chromatic abnormalities in a scanner’s lens requires a baseline color palette in the code, which eats up some of the newly-gained data capacity.
Nonetheless, we really do like this concept. Do you have any applications of QR codes in your projects where coloring could be helpful? Is anyone using (monochrome) rMQR codes and if so, how are you scanning them? Check out our overview of barcodes, their history, and their future, in this recent article.
It should be obvious that it probably makes more sense to use Cyan Magenta and Yellow instead of Red Green Blue for a multicolor code that’s printed on paper.
Yeah but you gotta scan it with an rgb camera
So any 1970s+ camera?
considering factor of existing/legacy devices.. it is as silly to say lets mix barcodes too on top of this idea n further on top of that colored barcodes in these said colors..
with CMYK you could encode 4 bits instead of 3, but K might actually be hard to pull off. with CMY and typical printing inks you would mix an average of 1 1/2 inks per pixel to make a simple 3-bit code. With RGB with typical CMYK printing inks, you’d mix … an average of 1 1/2 inks per pixel to make a simple 3-bit code. Red(2^0) = Magenta+Yellow; Green(2^1) = Cyan + Yellow; Blue(2^2) = Cyan + Magenta. … those RGB combinations for 0th, 1st, and 2nd bit respectively. get you combinations like red bit + green bit looks yellow on paper. so you only need 1 ink to represent 2 set bits. this ends up being a very simple transformation for a binary color scheme, I think it might just be an XOR to convert between the systems in that case and thus the same average amount of ink.
The difference is essentially notation only: black on the red barcode becomes cyan without other chanels, green magenta, blue yellow. CMY is just negative RGB. And most printers convert from an RGB color space because it doesn’t have redundant degrees of freedom like CMYK anyway.
You could use brightness like the way video signal uses it. Also would require a baseline test pattern but would probably allow it to contain more data with enough opacity segments
You could be right! Maybe that’s why the maker discussed CMYK printing in the project description.
This isn’t the first colourisation. And as far as I can tell those three are the popular choices.
Not sure why you’d use RGB except to be different?
If most of these codes will be printed using a home inkjet printer maybe, but otherwise RGB makes way more sense as most every CCD scanning these codes will be using RGB sensors. Any sort of scale production of QR codes won’t be done with InkJets methinks, they’ll be printed on vinyl plotters, ordered from a print service(like menus), displayed on screens(scan my code to get RAID:Shadow Legends with 3 free heroes and 1,000 premium Gold), etc.
For home users where majority is using inkjet CMYK, I don’t think the savings in ink would outweigh the extra color information needed to be stored to help RGB CCDs translate CMYK accurately. Beyond easily sharing your WiFi guest password there’s not much Inkjet printing of QR codes and black handles that just fine as is.
I actually use a laser printer for printing barcode. And it supports actual RGB. Guess I had a crash in my bio hard drive there.
I guess a picture is worth a thousand bytes.
Pretty funny seeing this. Years ago I had a project on here (IP over qrcode) maybe some remember it. Some comments were saying I should use RGB qrcodes to increase throughput. A few weeks ago I actually implemented it but haven’t posted it anywhere yet, but it does work. One thing I had a lot of trouble with is that cameras in general have a harder time separating RGB colors than you might expect, so you get bleedthrough in the blue channel from green, green channel from red etc. Anyway, switching to a better qrcode decoding library (zbar) solved it mostly. Hopefully I will get around to posting it soon!
I’d love to see it !
+1
Now that they’re getting up to some serious storage I cannot wait for the first direct QR Code malware to hit. “Hey everybody! Let’s point our devices at this completely unreadable image and just trust that it’s ok!”
somewhere in my pile of ‘old shit on my computer’ is a page of QR code stickers that would take you to goatse.cx
Hell, they’ve been putting worms into picture files for a while now. It’s why I never open images on email.
As you noted, colorizing barcodes has been looked at for quite a while. The paper you linked to cited Microsoft’s 2012 work in this space, the color “Microsoft Tag” 2D code which survived for a little while but is now discontinued.
https://en.wikipedia.org/wiki/High_Capacity_Color_Barcode
Couldn’t the fiducial marks be used to provide the baseline palette, thus not losing any data capacity?
That was my thought too: even if the lens bends R, G, and B light differently, the individual QR codes in each color — including those marks — should be distorted evenly.
I doubt that the lens induced chromatic abberation mentioned is evenly distributed across all areas of the lens, or at least not the kind I’m thinking of which occurs more often at the edge of elements within a multi-element lens system.
That said, given the quality of modern phone optics, would CA really be a huge issue at low bit rates? Wouldn’t applying some simple level filters be enough to compensate for CA, especially if there are color references in the image, i.e. similar to how monitor/tv calibration gels or reference images are used? What about a grey reference like photographers use?
I would think the bigger challenge for non-professional use would be in the code printing more so than the imaging. Inkjet printing challenges such as print head alignment, clogged jets, dirty rollers, ink levels, etc. come to mind. Laser printers would be better but not immune to all of those, especially at higher bit rate codes. Color fading is perhaps the greatest risk to either.
But if all of that can be overcome, why stop at just three colors? In some ways this is conceptually similar to encoding multiple data streams into a fiber using different wavelengths of light. Why not pre-compress or develop a customized encoding scheme to squeeze more “channels” before qr encoders input? I did some limited work in using color channelsfor compression in the mid-2000s and it was challenging enough at the time without needing to worry about the print/scan effects.
Obviously any of those items will challenge the ability of the QR code to protect from damage.
Over here in Europe they already use colored ‘QR’ codes for years now, that is to say a square of colored tiny squares to represent data that you can scan.
Not on products you buy at the supermarket/real shops though – AFAIK.
Colored 2D codes are used in Germany by some banks for transaction authorization. You enter the details for the transaction on the bank website. The website generates a 2D code. You use a dedicated photoTAN device (or a mobile phone with the bank’s app if you don’t care about security) to capture the 2D code. The device displays the transaction information and a number. If the displayed transaction is correct, you enter the number on the bank’s website.
https://www.wikibanking.net/onlinebanking/verfahren/phototan/
That’s what they do in other EU countries too.
I wonder if some US bank in some state also uses that.
Mind you, one of the reasons they use it is because the EU mandates increased security from banks, and of course in the US they don’t have that new mandate.
The Dutch bank of ING uses it as well, and when I researched it, it was indeed a German invention.
They don’t have issues with color because obviously it’s only shown on screens, not in printed media. (It’s used for 2FA)
Good concept buy silly idea. If a color QR code on say a manual is left in storage for a couple years I am sure the color will fade and probably not be picked up properly. Or if gets wet it will fade. whereas black and white will always work. If you want more data just increase the QR code size.
Not to mention the different lights under which you can view the code. Will it distinguish between white and yellow under a 2700K bulb? How about a sodium vapor lamp?
I have the similar concerns. The monochrome QR code was robust, because of high contrast. That’s why it was (is) so useful.
Adding more colours will weaken the signal-to-noise ratio, so to say. It’s like using multiple tones/frequencies in a radio link on shortwave. Decoding becomes increasingly more difficult the more different tonal pairs are being used. At some point the error correction is so demanding that data rate goes down.
now I’m picturing an unreasonably large QR code with various shades of color precisely calibrated so that pointing a camera at it in situ automagically reveals the QR code of settings the camera should use under those lighting conditions…
Yeah… My immediate thought was that this is going about it the wrong way. QR code is monochrome on purpose, and intentionally doesn’t explicitly define which color is foreground and which is background. The whole point is robustness and quick recognition. Adding colors means you lose much of the benefits, just to retrofit color density into a format that was explicitly designed to not use it.
A better solution would be to use one of the 2d codes that are multi color by design. You want your image to be resistant to color substitution and stuff.
This is not a new concept.
I remember seeing triangular versions of this over a decade ago.
Although I do wonder, recalling the prior HaD article on cramming snake into a regular b+w 2D barcode, what could be squeezed into its colour counterpart.
Microsoft’s Tag, as mentioned above. I also remember there was a full page version for some reason, not sure if that was MS Tag or not.
The colored snow on our CRTs could have been an early QR code. ;-)
Turns out aliens have been trying to communicate with us for years. The snow you would see on an analog crt before tv went digital was just a very large continuously changing qr code with none of the corner squares.
I think they could legit learn from video compression in refining this
Seems like it could be problematic depending on the lighting, especially for yellow.
In regard to the yellow/white issue: The corners have the markers, that are surrounded by white, to which you can calibrate.
There’s still the fading issue of course, but you know there is plenty of packaging that seemingly never fades, and besides, if something is so old or left in the sun so long maybe it’s better to not buy it at all :)
this is not a new idea. It’s quite old actually…
Ive been a bar code nerd for a while, even wrote up a simple spec based on top of colorized qrcodes with zpaq compression a while back that used simple shapes inside the blocks where the block color and the shape color were high contrast from each other. It could use circles, and triangles (in 4 orientations offset by in 90° (inspired by MS HCCP)). Did a PoC with opencv, and imagemagick. It worked, i fit the whole text of Moby Dick on a few sheets of A4, but it was very, very slow. Mixing contrasting colors on top of embedded shapes increased the capacity tremendously.
I didnt attempt to tackle parity, my PoC was barely useable, just a fun exercise to determine how much data i could print, and then recover via a scanner.
One of my bank still use this for mobile signed logging in.
Would be much better to use grayscale instead of color.
The QR code spec by the same company (Denso Wave) has been public for many years, and is a world standard. But strangely the other QR standards (iQR, rMQR, secure QR) have been sitting like a chicken-egg problem with them. I like the idea of rMQR, which offers more data in less space compared to DMRE. However without READERS, what’s the point ? It was so bad that even their OWN applications could not read the rMQR. I mean, you make standard X, which nobody in the world can seem to read. How would they expect to sell anything.
I asked them this when they tried to sell the solution to our company (working with barcodes etc). No response since.
Hopefully they are now starting to open up.
Scandit appears to recognise some layouts for it.
I guess it’s worth pointing out that a bayer filter camera has far from equal sensitivity to each color, (having twice the area dedicated to green as is dedicated to red or blue) and ambient light isn’t uniformly distributed either, so even before the image processing kicks in, you may not have an optimal split between each channel in lower light levels. But by choosing to match RGB to RGB, at least you’re just using the channels that actually exist in the camera, instead of trying to differentiate between other colors. And if the resolution needed to carry the same data in black and white is too much, then hey there you go.
The idea suggested in the blog is exactly the “channel-wise” barcodes idea that our group has proposed and developed for achieving three times the data rate in the same spatial footprint. We have developed the idea oth for print using CMY channels and for display using RGB channels, where we have also come up with appropriate methods for modeling and canceling inter-channel interference between print/display and capture. Interested folks can find details in the following two papers:
H. Blasinski, O. Bulan, and G. Sharma. Per-colorant-channel color barcodes for mobile applications: An interference cancellation framework. IEEE Trans. Image Proc., 22(4):1498-1511, Apr. 2013.
http://dx.doi.org/10.1109/TIP.2012.2233483
https://hajim.rochester.edu/ece/sites/gsharma/papers/HenrykColorMobileBarcodesTIP0413.pdf
Karthik Dinesh, Jiangfeng Lu, Shingirai Dhoro, and Gaurav Sharma. Channel-wise barcodes for color display applications. J. Electronic Imaging, (3):033021-1-18, May/Jun. 2019.
http://dx.doi.org/10.1117/1.JEI.28.3.033021
https://hajim.rochester.edu/ece/sites/gsharma/papers/DineshChlwiseBarcodesColorDisplayJEI2019.pdf
-Gaurav Sharma
Great use of Division Multiplexing : This same technique is used in fiber-optics laser signaling. Excellent hack.