sz3
Adjusting size
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.
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: https://github.com/sz3/libcimbar/issues/72#issuecomment-1579978821
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.
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 does imply the number of accepted configurations is low.
Can we consider having the screen initiate multiple QR codes to be sent in batches, where the failed parts will continue to be resent until the final result on the screen, for example, turns from 8 QR codes into 1, until completion?
Ooh, what about a (smaller?) cimbar of known size/parameters/etc that encodes the parameters of the main one? User scans that, then the rest.
Ooh, what about a (smaller?) cimbar of known size/parameters/etc that encodes the parameters of the main one? User scans that, then the rest.
My concern with a multi-step approach is that it makes things more complicated than I'd like. Basically we're talking about a metadata (or configuration) frame that the receiver has to toggle to and manually verify. Then, when the config has been set properly, we're good to go.
I do think there's something to that idea though...
-
One wrinkle that comes to mind is: interleaving frames could work with this idea. e.g. send 14 of the data cimbar, 1 of the encoding params/metadata. It'll slow down the transfer slightly (if it's 1/15 then... 6.6%!), but there could be heuristic to stop sending the metadata frames after startup.
- For example: I introduced a "pause" to the cimbar.js encoder after the menu is toggled -- it helps with autofocus. Maybe it'd be reasonable to have this metadata frame idea sent periodically on the same event, then after a few passes (5 times?) it'd age out. So we'd have to toggle the menu again if we want our magic decoding to happen?
Yeah, that seems like a good idea. Maybe pressing space, or tapping/clicking could resend the metadata cimbar. I was thinking just adding it on the side.