From e27511d33faff5c684a60c43cd6acd51af5d22af Mon Sep 17 00:00:00 2001 From: sz Date: Thu, 15 Feb 2024 23:13:07 -0600 Subject: [PATCH] Docs update --- ABOUT.md | 11 +++++------ README.md | 8 ++++---- 2 files changed, 9 insertions(+), 10 deletions(-) diff --git a/ABOUT.md b/ABOUT.md index 41556d7..0de1044 100644 --- a/ABOUT.md +++ b/ABOUT.md @@ -30,7 +30,7 @@ My conclusion was that if I was going to create a proof-of-concept implementatio Not yet. The project is -- at this point -- just a proof-of-concept. It's not clear to me that cimbar is any better for data density + reliability than HCCB, or better than the myriad of unfinished attempts at color QR codes that are floating around, or (...). It could be a technological dead end. But perhaps with more refinement it might be interesting? -## Notable open questions, concerns, and ideas: +## Unresolved design questions, concerns, and ideas: * the symbol set is not optimal. There are 16, and their image hashes are all reasonable hamming distance from each other, and do *ok* when upscaled... but I drew the initial 40 or so candidates by hand in kolourpaint, and paired down the set to 16 by experimentation. * 32 distinct tiles (5 bits) be possible for 8x8 tiles @@ -52,12 +52,11 @@ Not yet. The project is -- at this point -- just a proof-of-concept. It's not cl * 8-color cimbar (3 color bits) is possible, at least in dark mode * probably light mode as well, but a palette will need to be found * 16-color cimbar does not seem possible with the current color decoding logic - * but with pre-processing for color correction and a perceptual color diff (like CIE76), ... maybe? - * this may be wishful thinking. + * ...at least not in the small (sub-8x8) tile sizes we want to use for high data density * Reed Solomon was chosen for error correction due how ubiquitous its implementations are. * it isn't a perfect fit. Most cimbar errors are 1-3 flipped bits at a time -- Reed Solomon doesn't care if one bit flipped or eight did -- a bad byte is a bad byte. - * Something built on LDPC would likely be better. + * Something that cares about bits and not bytes (LDPC? idk) would likely be better. * the focus on computer screens has surely overlooked problems that come from paper/printed/e-paper surfaces * using a black background ("dark mode") came out of getting better results from backlit screens @@ -65,8 +64,8 @@ Not yet. The project is -- at this point -- just a proof-of-concept. It's not cl * curved surfaces are a can of worms I didn't want to open -- there are some crazy ideas that could be pursued there, but they may not be worth the effort * should cimbar include "metadata" to tell the decoder what it's trying to decode -- ECC level, number of colors, (grid size...?) - * the bottom right corner of the image seems like the logical place for this. - * a slightly smaller 4th anchor pattern could give us 11 tiles (44 bits?) to work with for metadata, which is not a lot, but probably enough. + * the bottom right corner of the image seems like the logical place for this. However, differing aspect ratios may be a problem + * example: on 8x8, a slightly smaller 4th anchor pattern could give us 11 tiles (44 bits?) to work with for metadata, which is not a lot, but probably enough to be useful. ## Would you like to know more? diff --git a/README.md b/README.md index 04af0a2..7d08f79 100644 --- a/README.md +++ b/README.md @@ -33,16 +33,16 @@ The main constraints cimbar must deal with are: * all tiles in the tileset must be sufficient hamming distance away from each other, where *sufficient* is determined by whether the decoder can consistently place blurry or otherwise imperfect tiles in the correct "bucket". * all colors in the colorset must be far enough away from each other -- currently as a function of RGB value scaling -- such that color bleeding, reflections, and the like, can be overcome. -In practice, this means that the source image should be around 900x900 resolution or greater, with reasonable color correction handled by the camera -- as you'd find in any modern cell phone. +Cimbar is designed to deal with some lossiness. In practice, the source image should be around 700x700 resolution or greater, in focus, and with *some* color correction handled by the camera -- as you'll hopefully find in any modern cell phone. -This python cimbar implementation is a research project. It works, but it is not very performant, and does not handle error cases with much grace. [libcimbar](https://github.com/sz3/libcimbar), the C++ implementation, has been much more heavily optimized and tested. The target goals of the proof-of-concept were: +This python cimbar implementation is a research project. It works, but it is slow, and does not handle error cases with much grace. [libcimbar](https://github.com/sz3/libcimbar), the C++ implementation, has been much more heavily optimized and tested. The target goals of the proof-of-concept were: 1. achieve data density on the order of _10kb_ per image. 2. validate a theoretical performance (and if possible, an implemented demonstration) of >= _100kb/s_ data transfer (800 kilobits/second) from a computer screen to a cell phone, using only animated cimbar codes and the cell phone camera. ## I want numbers! -* a 6-bit cimbar image contains `9300` raw bytes of data, and `7500` bytes with the default error correction level (30) -* for 7-bit cimbar, the respective numbers are `10850` and `8750` +* a `mode B` (8x8, 4-color, 30/155 ecc, 6-bits-per-tile) cimbar image contains `9300` raw bytes of data, and `7500` bytes with the default error correction level (30) +* for the old `mode 8C` (8x8, 8-color, 7-bit) cimbar, the respective numbers are `10850` and `8750` * error correction level is `N/155`. So `ecc=30` corresponds to a `30:125` ratio of error correction bytes to "real" bytes. * error correction is (for now) done via Reed Solomon, which contibutes to the rather large ratio of error correction bytes. See [ABOUT](ABOUT.md) for more technical discussion.