Adjusting size

[Anonymous3-a]

What if the cimbar size could be adjusted (like a QR code)?

I admit this is mostly because I like working algorithms out on paper and this would make it easier, but it could have uses. There could be bigger cimbars for bigger screen+camera to make file transfer faster or smaller ones for smaller screen/camera.

[sz3]

Perhaps.

Like QR codes, we could do multiple configurations -- and in fact, I've kind of already introduced this concept ("mode B" vs the initial "4C" -- the size is the same, but other parameters are slightly different).

Unlike QR codes, there's not a good way for the code to describe what it is mid-decode. So we have less flexibility in that regard -- the decoder needs to assume it knows what the config is, or try them all.

With that said: I've been experimenting with non-square configurations over the past months, and hopefully will end up with two -- one for 720p cameras, and one for maximum 1080p performance.

(there's also the matter of the tileset choice itself -- but for the purposes of this conversation we'll say it's the current set of 8x8 tiles)

finally: there are some tricks to finding the right numbers to create a valid cimbar config, small or large. I wrote up a bit in this older issue: #72 (comment)

[Anonymous3-a]

For describing parameters: you could try making the tracking square alignment things

change color, so white is default, and the other colors have different size/shape/etc. They seem recognizable no matter what size/color they are. EDIT: Changing shape could work too, but at that point you end up using big versions of the tiles for tracking the code...

Other option: make the user choose what parameters there are.

[sz3]

The user choosing parameters would 100% work, but definitely introduces complexity. I suspect that'll be necessary at some point, but it's easy to imagine it getting out of control and turning into a big mess.

But in regards to the other ideas to change the alignment "anchors"... there are concerns:

• changing the shape doesn't really work with the scanning algorithm. I played around with this when I was getting started, but in short: the anchors are used to find the barcode, and are subject to a different set of rules than the rest of the decode. The algorithm for finding anchors is very similar to the QR code's algorithm -- we look for a 1:1:4:1:1 pattern, give or take error margin. The pattern we expect to see -- the upright square -- is the output of the extraction, and the input could be in any weird orientation. So needs to be fully symmetric, i.e. layered geometric primitives.
• furthermore, most things that aren't a square (maybe a circle would be fine) is going to sacrifice grid space to achieve similar detection success rates, due to being a more complex shape. Maybe something like an octagon would be ok? I haven't tried that. Not sure if it's worth it...
• colors also seem like trouble to me. Basically the options are yellow, cyan, and green, in order of likely success. As we get to lower contrast colors we again lower the success rate of the (threshold+) scan. There's also no real hope of color correction for this part of the scan, which has proven to be something of a necessity. (color correction is the motivation for the "mode B" change)

One idea I've had is to put a sort of metadata area around one or more anchors, and have it follow a different set of decoding rules than the other tiles. The requirement would be to successfully decode the metadata section even if we guess the size wrong, so we can re-run the extract with the right size and move onto the next step of the decode.

tl;dr: having the user choose will always work. The other simple option (not discussed above) is cycling through the valid configurations (the "auto-detect" idea), but that doesn't imply the number of accepted configurations is low.