Paper Mode?

[Anonymous3-a]

According to https://github.com/sz3/cimbar#how-it-works, there's a mode for paper printing. How would I do that with the tools provided in this repo (preferably with the cimbar --encode tool)?

[sz3]

Unfortunately, I haven't implemented that (yet?) in this repo -- the sad truth can be seen here. (since it's constant, there are probably other places that need to be updated as well)

It's probably not too much work to add a basic version, though there are some interesting questions about how the color decodes should work.

How were you thinking of using it?

[Anonymous3-a]

I was thinking of trying it on printed paper (although color ink is pretty expensive, so I'd probably not do much testing). It might be a nice concept, like offline e-menus or something like that.

[sz3]

Well, if it'll fit into 5000 bytes, black and white might suffice. Though that's not too different from a max-capacity QR code at that point. cimbar does have zstd built in though...

Maybe the high-level note here is that I haven't dug too hard into what a paper-based version of cimbar should look like. There are some fundamental questions:

• do we prioritize putting multiple codes on the page? We could... maybe we should?!
• does the reduced need for encode/decode speed allow changes to the character set to increase data density? It seems like it might, which probably implies a wholly different "alphabet" with more symbols? (see also: Towards 6-bit tiles? #69)
• how much are colors really worth? We could conceivably do 1 "color" bit just using grey and black, and not use color ink at all. Notably, for the current design (notwithstanding all this pie in the sky stuff) that'd get us to 6250 bytes, which is not 7500 but also not too shabby.

I'm probably going to be working on the cimbar format change I'm calling "0.6.x" for a bit longer -- it's getting close but still isn't there. Once that's done I might wire up a "light mode" configuration. (if you or anyone else wants to experiment in the meantime, feel free!)

[mihaigalos]

how much are colors really worth? We could conceivably do 1 "color" bit just using grey and black, and not use color ink at all.

There are 2 dimmensions that make cimbarcodes unique - at the moment:

• shapes (tiles) - 4 bits.
• color (reliably 2 bits of colors, mostly not surviving the analog journey with 3 bits).

I would like cimbar to focus on these. QR-codes already support what you need for black-and-white usecases.
Support for BW would strip 1 bit of color at least because "color is expensive".

The 1 extra bit in comparison to BW makes all the difference in carrier capacity, effectively doubling it.

[Anonymous3-a]

The 1 extra bit in comparison to BW makes all the difference in carrier capacity, effectively doubling it.

Unfortunatly, the companies that sell ink sell it at incredible prices (also, they mix color into B/W prints, but that's better than full color at least). This makes it give more data per <currency> to print with B/W, from my estimates.

[mihaigalos]

What kind of data are you after for encoding? It' a couple of kB per code anyway.

[Anonymous3-a]

I was trying to encode the first ~1M digits of pi. I've decided not to do that for now, but paper mode would still be cool.

[sz3]

Ha!

I've been looking at "light mode" color schemes briefly (something more usable against a white -- or paper -- background), but it'll probably be pretty bare bones using the new mode B. I'll soon have one of those fancy color e-ink screens for faster experimentation... (ok, it's really because I want a color e-ink screen to preserve my eyes)

Color choice aside, mode B will degrade nicely to decoding the symbol component on a black/white print, but at reduced data capacity (5000 bytes per code). Possibly still be useful for fun novelty projects, not sure.

What I haven't made time for (unfortunately) is progress on the general "what does a paper cimbar mode really look like". I'm still inclined to think a much bigger 8x8 symbol set (64 tiles??? e.g. the venerable issue #69) would be ideal.