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

161–170 of 183 posts

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

#161

Post by ryan-c »

bigiain wrote: post #158
nine_k wrote: post #149

Earlier quoted context omitted.

> 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 just made a short (2048 bit) key pair, and made the public key into a QR Code (as ascii armoured text, so it could have been more dense in straight binary) https://flic.kr/p/2cYCwfG I could only get it into a 141x141 by dropping error correction right down to 7%, but under ideal conditions (from my monitor to an iPhone) it reads reliably, as shown. I tried a 4096 bit key, but I couldn't (as text) get it into even a…

Some friends and I experimented with this when running a CTF a few years back. We figured out that setting some of the Chinese Remainder Theorem values in the private key to zero, we could stuff it into a QR code and read it when printed using a receipt printer.

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

#162

Post by ZenPsycho »

fallat wrote: post #146
jf wrote: post #139

Earlier quoted context omitted.

Thanks for doing this research! I've long dreamed of making a "print to binary to paper" backup system, but all the 2D barcodes I considered had patent encumbrances.

This was the motivation behind what I tried to make: https://github.com/lf94/blots

related: https://github.com/cyphar/paperback

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

#163

Post by ZenPsycho »

theclaw wrote: post #108

An eight-colour code does not seem smart for printed codes where most printers use only four inks. A colour code using cyan, magenta, yellow, white and black might be more reliable (although yellow could easily be confused with white). The PDF suggests 256-colour codes are supported, but that would mean luminosity is a factor, and I can't see how that would ever be reliable if the code is intended to be scanned with…

Yellow and magenta are also generally fugitive. Meaning that, over time, due to UV exposure, the yellow will completely fade, followed by magenta, and all you're left with is cyan and black. You'll see this in shops with advertising posters in their front window that haven't been changed in a long time.

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

#164

Post by Faark »

x13 wrote: post #157
neetdeth wrote: post #51

Earlier quoted context omitted.

Technical specification is here: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publicat... Every JAB code has four registration patterns in the corners, as well as multiple color pallets at fixed locations.

Hey on page 29 does anyone see a pattern that resembles.. historical German symbology used by to represent national pride and a government party that rose to power in the 1920's? Am I the only one? Sorry, just popped out at me.

Yeah, but I'd give them the benefit of a doubt unless it's visible on actual codes or there is evidence this was intentional.

You end up with that pattern all the time when you try to efficiently pack rectangles around a different sized rectangle. I remember trying to avoid that back when placing fields in age of empires 2.

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

#165

Post by triangleman »

crazygringo wrote: post #37
omershapira wrote: post #25

I wonder if the 'Master'/'Slave' terminology is necessary here? Aside from being problematic, does it really describe the setup more than 'Primary'/'Secondary'?

Agreed. It's unfortunate but understandable we still use this terminology for existing technologies... but we absolutely should not be propagating it to new ones. Embarrassing story time: I was working in Brazil on a database, and used the Portuguese translations for "master" and "slave" in a technical meeting (I speak Portuguese). The whole room looked at me in shock, and my manager politely corrected me: "um, we ju…

My wife is Brazilian and I showed her this comment. She says the Brazilians were just giving you a hard time and that they don't find those terms offensive.

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

#166

Post by jackfraser »

dsl wrote: post #148
imhoguy wrote: post #100

Earlier quoted context omitted.

What if we add color or even UV/IR to an existing QR code just to increase data redundancy? Backward-compatibility FTW!

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...

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

#167

Post by qume »

neetdeth wrote: post #78
qume wrote: post #65

Cameras only see one colour per pixel (i.e. Bayer colour filter array). Because our eyes are not so acute at resolving colour compared to luminescence this tradeoff works well. But in this context I'm not sure at a pixel level how much 'extra' information is added by _removing_ red/green from the blue pixels, green/blue from the red etc. In other words, if the image came from a digital camera, to actually stuff more…

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 imagine you'd see some improvements as you say.

An interesting middle ground would be if you could get the raw image from the sensor before a generic debayer algorithm gets applied.

Good luck, keep up the good work... i've worked commercially on optical barcode systems and it's a super interesting topic (tho looks like my post has been downvoted out of existence so maybe you wont see this).

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

#168

Post by namibj »

anonova wrote: post #143
nimbius wrote: post #91

for those decrying the limited use of 2d barcodes in the US or in europe, you've never set foot in a manufacturing environment. 2d barcodes are used for cradle-to-grave inventory tracking by systems like Glovia and SAP. everything from transmission gears to soda pop are tagged during manufacture with numerous 2d barcodes that change at different stations, and at different times. it doesnt matter what your new standar…

> ... rely on near/far vision systems developed by Intermec and other companies to read a code the size of a postage stamp from up to 150 meters away. Does anyone know of these super long range scanners (e.g, 150 m)? Looking through Honeywell's products, the Granit 1280i [1] claims 16.5 m, which is impressive but not the 150 m mentioned above. I'm curious how aiming is even possible with what I would assume to be an…

Just remember there are sensors like the CMV12000 that spew out over 3 billion pixels per second @10bit/pixel and, sufficient light assumed, subpixel motion blur down to iirc about 50% linear overlap or so about. (i.e., only about 50% of the captured pixels have not been captured already.)

Assuming 32 by 32 pixels with a size of 1mm by 1mm, you get a field of view of about 2 by 3 meters or smaller if you want to skip exotic monolithic decoders that integrate de-aliasing into the error correction decoder. Below about 1.2 sensor pixel per code pixel it stops being fun and you try to find a way to get more magnification.

So, at 150 meters distance, assuming a cube for simplicity, and 5 square meters FOV. We have a cube of 300 m side length. That cube has a surface area of 540 000 m^2, which is just ~100k times the FOV. The 300 frames per second you could get out of the sensor would get this done in about 20 minutes, so yes, it's a lot, but you can reduce to 30% assuming the height difference is approximately known. Then you can probably get another 10x speed by restricting the angle in which anything interesting could happen, and you get 3% of 20 minutes/1000 seconds. That's half a minute, if you can only tell the scanner that it's about there, with a precision of "between one and two 'o clock, I'm sure".

And that's I deem the number plausible.

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

#169

Post by dang »

tedivm wrote: post #135
tomp wrote: post #72

Earlier quoted context omitted.

I prefer the term "slave" because it implies (hopefully) no free will (and hence no capacity to disobey). At least I hope that's how AI turns out. You're finding offense for the sake of finding offense and being censorious for the sake of being censorious. Please stop.

You're breaking a rule of this site- you should assume good faith when talking to other people on here. There is no evidence that anyone wants to be "censorious for the sake of being censorious"- even if you don't agree with the reasoning behind this discussion it doesn't change the fact that people have put forward reasons.

Yes, but I'd say the GP comment broke that same rule as well.

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

#170

Post by dang »

minikites wrote: post #52
Dirlewanger wrote: post #47

Earlier quoted context omitted.

Yup, it's censorship for the sake of censorship. We've had zero problems with master/slave terminology for decades because everyone dealing with it was cognizant enough to realize we weren't talking about human bondage. Then people who are incapable of compartmentalizing word connotations came in and declared their use "problematic" and demand everyone conform to their worldview and to waste time changing code commen…

[flagged]

Please don't take an HN thread further into pointless flamewar. This is a classic of that hellish genre.
Post reply on HN