New numbers, and they are quick

8-color probably needs higher ECC... 🤔

PERFORMANCE.md

@@ -9,22 +9,26 @@
 	* There are 4 or 8 possible colors, encoding an additional 2-3 bits per tile.
 	* These 6-7 bits per tile work out to a maximum of 9300-10850 bytes per barcode, though in practice this number is reduced by error correction.
 	* The default ecc setting is 30/155, which is how we go from 9300 -> 7500 bytes of real data for a 4-color cimbar image.
-		* Reed Solomon is not an ideal for this use case -- specifically, it corrects byte errors, and cimbar errors tend to involve 1-3 bits at a time. However, since Reed Solomon implementations are ubiquitous, I used it for this prototype.
+		* Reed Solomon is not perfect for this use case -- specifically, it corrects byte errors, and cimbar errors tend to involve 1-3 bits at a time. However, since Reed Solomon implementations are ubiquitous, it is currently in use.
 
 ## Current sustained benchmark
 
 * 4-color cimbar with ecc=30:
-	* 2,980,556 bytes (after compression) in 36s -> 662 kilobits/s (~82 KB/s)
+	* 2,980,556 bytes (after compression) in 31s -> 769 kilobits/s (~96 KB/s)
 
 * 8-color cimbar with ecc=30:
-	* 2,980,556 bytes in 31s -> 769 kilobits/s (~96 KB/s)
+	* 2,980,556 bytes in 29s -> 822 kilobits/s (~102 KB/s)
 
 * details:
-	* these numbers are use https://github.com/sz3/cfc, running with 4 CPU threads on a Qualcomm Snapdragon 625
+	* these numbers are using https://github.com/sz3/cfc, running with 4 CPU threads on a Qualcomm Snapdragon 625
 		* perhaps I will buy a new cell phone to inflate the benchmark numbers.
-	* the sender commandline is `./cimbar_send /path/to/file -s`
-		* the `shakycam` option allows cfc to quickly discard ghosted frames, and spend more time decoding real data.
+	* the sender is the cimbar.org wasm implementation. An equivalent command line is `./cimbar_send /path/to/file -s`
+		* cimbar.org uses the `shakycam` option to allow the receiver to detect/discard "in between" frames as part of the scan step. This allows it to spend more processing time decoding real data.
 	* burst rate can be higher (or lower)
 		* to this end, lower ecc settings *can* provide better burst rates
-	* 8-color cimbar is considerably more sensitive to lighting conditions. Notably, decoding has some issues with dim screens.
+	* 8-color cimbar is considerably more sensitive to lighting conditions and color tints. When in doubt, fall back to 4-color.
 
+* other notes:
+		* having better lighting in the frame often leads to better results -- this is why cimbar.org has a (mostly) white background. cfc uses android's auto-exposure, auto-focus, etc (it's a very simple app). So good ambient light -- or a white background -- can lead to more consitent quality frame capture.
+		* cfc currently has a low resolution, so the cimbar frame should take up as much of the display as possible (trust the guide brackets)
+		* similarly, it's best to keep the camera angle as straight-on as possible, to decode the whole image successfully. Decodes should still happen at higher angles, but the "smaller" part of the image may have more errors than the error correction can deal with.

TODO.md

@@ -31,9 +31,10 @@ Performance optimizations aside, there are a number of paths that might be inter
 	* a smaller grid would be less information dense, but more resilient to errors. Probably.
 * optimal grid shape?
 	* it's a square because QR codes are square. That's it. Should it be?
+	* I'm strongly considering 4:3 for the next revision
 * more efficient ECC?
-	* LDPC?
-	* Reed Solomon operates on bytes. Most decode errors tend to average out at 1-3 bits. It's not a total disaster, because it works. However, it would be nice to have denser error correction codes.
+	* QC-LDPC?
+	* Reed Solomon operates on bytes. Most decode errors tend to average out at 1-3 bits. In the pathological case, such a bit error will span two bytes. It's not a total disaster, because it works. However, it would be nice to use state of the art ECC.
 * proper GPU support (OpenCV + openCL) on android?
 * ???
 	* still reading? Of course there's more! There's always more!

web/index.html

@@ -40,7 +40,7 @@
 	margin: 0 auto;
 	z-index: -1;
 	color: #F0F0F0;
-	outline: 10px solid black;
+	outline: 8px solid black;
 }
 
 #dragdrop::before {