Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JAB Code – A high-capacity 2D color bar code

github.com

Post reply on HN
Print view View original

171–180 of 183 posts

Re: JAB Code – A high-capacity 2D color bar code

#171

Post by naikrovek »

aaaaaaaaaab wrote: post #66
ygra wrote: post #55

Earlier quoted context omitted.

QR codes printed on thermal paper also fade over the course of a year and would be unreadable. There are always uncorrectable adverse conditions.

Sure. And if you light the paper on fire even 24pt Helvetica becomes unreadable. But I’m sure you too feel that the failure modes of this colored barcode form a proper subset of the failure modes of its monochromatic counterpart.

Well, if your machine-readable color key fades as well, maybe it's not so much of a showstopper if the colors fade.

The primary problem I see is that so many industrial cameras today are black and white. B&W cameras can send at a higher framerate and you don't need to convert to greyscale as your first step in your algorithm, so it saves time to use b&w cameras.

Re: JAB Code – A high-capacity 2D color bar code

#172

Post by kbaker »

lettergram wrote: post #89

Seems similar to my ChromaTags approach from 2015: https://austingwalters.com/chromatags/ My post goes a bit into more detail on how it works, and why for instance - the given colors were chosen. It appears they too use the Lab color space for instance.

I don't think they use the Lab color space, except if you define your own colors to use in the palette, did you see a reference to it?

From their encoding spec: > In order to optimize the decoding of JAB Code, the used colors shall be so distinguishable as possible. Therefore, the used colors shall keep a distance from each other in the RGB color space cube

> In case of 256-color-mode, the color channel R and G take eight values, 0, 36, 73, 109, 146, 182, 219 and 255, and the color channel B takes four values, 0, 85, 170 and 255, which will totally generate 256 colors.

Which is too bad, because your idea of using Lab with ChromaTags to enable quick and accurate finding of the symbol was a really insightful technique. The decoding algorithm they suggest seems like it would be slow, and their use of RGB seems like a whole bunch of issues due to color-selective fading, shadows, damage, lighting, incorrect printer calibration, etc.

Re: JAB Code – A high-capacity 2D color bar code

#173

Post by klohto »

divan wrote: post #56

I wonder what throughput it can give when used as an animated sequence of codes? I experimented with animated QRs for data transfer last week and the real maximum I’ve achieved was around 9KB/s. https://divan.github.io/posts/animatedqr Using colored high-capacity encoding should yield much better results, given the decoder is as fast as QR one.

What if you used high capacity code like HCCB or CQR Code-9. CQR has a capacity of 3KB per square inch [1], based on your formula of 11 frames per second, you could easily do 33KB/s.

And that is just a square inch, I think you could reach pretty good transfer speeds with higher resolution and wider dimensions.

[1] - https://pdfs.semanticscholar.org/95c7/fe455a084b0f0ce9923e99...

Re: JAB Code – A high-capacity 2D color bar code

#174

Post by vertex-four »

pjmlp wrote: post #104
vertex-four wrote: post #94

Earlier quoted context omitted.

In the U.K. we actually use Aztec codes for train tickets, rather than QR. Not entirely sure why.

Oh, my mistake. But National Express does them, right?

Yes, I think National Express print QR codes on their tickets but very rarely actually read them.

Re: JAB Code – A high-capacity 2D color bar code

#176

Post by Dylan16807 »

nine_k wrote: post #149
jschwartzi wrote: post #142

Earlier quoted context omitted.

Printing a 400 byte payload is pretty easy, but printing a 400 byte payload that's readable at high-speed(100 scans per second) is quite a different story. You'll find that in many usage scenarios the practical upper limit for a data payload is determined less by the symbology and more by the speed and reliability at which the symbology can be read by the equipment. Many thermal printers can do 200dpi or better which…

> encode a unique key which points to a record of the desired size in some database I'm sure you understand why this is not going to work the same way as reading the actual public key. Not only it needs a network, but it also is susceptible to stealing the values from the database by just generating the (short) unique keys.

> it also is susceptible to stealing the values from the database by just generating the (short) unique keys

Even a very small QR code fits enough bits to prevent that.

> it needs a network

It depends on what the key is for. For many purposes a hash of the public key is sufficient.

Re: JAB Code – A high-capacity 2D color bar code

#177

Post by JdeBP »

Confiks wrote: post #54

To copy a comment from a Github issue [1], comparing the different implementations: - CRONTO, PM-Code and HCCB and AuthPaper are proprietary. CRONTO has attracted some usage mainly by banks, PM-Code looks like vaporware, AuthPaper seems inactive and HCCB is dead [2]. - CobraKing seems to be a 2012 research project, unmaintained - HCC2D seems to be mainly academic exploration Papers and results similar to HCC2D pop up…

Outwith the free software world, there is at least one .NET implementation.

* https://neodynamic.com/barcodes/JAB-Code-Barcode.aspx

Re: JAB Code – A high-capacity 2D color bar code

#178

Post by dwild »

jackfraser wrote: post #166
dsl wrote: post #148

Earlier quoted context omitted.

It is already in the works. In 3-5 years every big box store product will have UV QR codes on every side of external packaging that encode the existing product barcode plus a unique per item ID. This is being done to improve self check out speed (no more having to find the bar code) and help with tracking receipt-less returns (this box of cereal was purchased at our store).

> (this box of cereal was purchased at our store). Think of the impact on forensics when every single article contains its source of origin. Time to start a company selling an invisible privacy spray for your cereal box that coats it in UV ink and obscures the original invisible barcode...

There's already invisible barcode on some backaging. I had a UV light and used it over a Pringle can and there was a code there!

Re: JAB Code – A high-capacity 2D color bar code

#179

Post by jschwartzi »

nine_k wrote: post #149
jschwartzi wrote: post #142

Earlier quoted context omitted.

Printing a 400 byte payload is pretty easy, but printing a 400 byte payload that's readable at high-speed(100 scans per second) is quite a different story. You'll find that in many usage scenarios the practical upper limit for a data payload is determined less by the symbology and more by the speed and reliability at which the symbology can be read by the equipment. Many thermal printers can do 200dpi or better which…

> encode a unique key which points to a record of the desired size in some database I'm sure you understand why this is not going to work the same way as reading the actual public key. Not only it needs a network, but it also is susceptible to stealing the values from the database by just generating the (short) unique keys.

I'm not talking about cryptographic keys, I'm talking about unique keys. Like a UUID or a serial number.

A barcode is not often used as the sole storage medium in an application. Typically it's used in conjunction with a piece of software that can connect to a database. In a manufacturing setting this could be a piece of shop floor control software. In that setting the barcode doesn't encode any information that could change in the database. It is instead used to encode a machine-readable identifier for the material that it is labeling.

Re: JAB Code – A high-capacity 2D color bar code

#180

Post by neetdeth »

qume wrote: post #167
neetdeth wrote: post #78

Earlier quoted context omitted.

This is an interesting point, but it assumes perfect optics. If the image is slightly out of focus, I think three lower resolution images in different spectral regions is a big win.

I think it depends on the context - if you're designing the whole system from bar code to camera, I'm not sure that the color will help. But in that case you can assume close to perfect optics and I'm not sure if you would find an improvement or the opposite over a monochrome setup with better SNR. On the other hand if you're stuck with things like mobile phone cameras, and can only control the bar code side, then Id…

I don't want to represent myself as one of the inventors! I just saw this on HN, skimmed the technical report, and found a bunch of comments on HN that could be answered with my cursory knowledge thus gained.

What I can offer is that it is now possible to get memory buffers containing "raw" sensor data from mobile phones. I've only done it on iPhone so far, but the "camera2" API on Android looks to support this as well. It only works in single-shot photo mode - I suspect there isn't the bandwidth to do 30 fps streaming, and they rely on the ISP for debayering and color space conversion in video mode.

iPhones seem to have negligible chromatic aberration in their raw output, weirdly, so that isn't a blocker for full sensor resolution grayscale imaging. Someone could exploit this to write the world's greatest mobile phone QR reader app.

Post reply on HN