Интересно как много информации можно впихнуть в QRCode при сохранении возможностей
распознавания?

В вики https://en.wikipedia.org/wiki/QR_code#Standards пишут что V40 размером (177x177 пикс) со служебной
инфой и контрольными кодами может затянут в себя порядка 3килобайт.

Допустим я наплевал на стандарты. И просто беря во внимание возможность своей камеры телефона
передавать инфу чуть потолще чем URL-s. Ну допустим хотя-б 1000х1000 пикселов. Это грубо будет
1 мегапиксел черно белых или 1 000 000 / 8 = 125 000 K и с учотом служебной инфы в 25% как там в вики
пишут, выходит 93 000 байтов. Уже неплохо.

Время распознавания меня не волнует. Пускай хоть 5 минут работает.
Для алгоритма растеризации кода тоже по большему счету всё равно сколько там пикселов. Главное
чтоб алгоритм был тот-же.

Что думаете?

Значит 1000 - много? Но мне 177 - мало. Есть компромиссный вариант? Так чтоб штаны не рвались.

Да это была самая первая идея. Шел от FideReader к QRCode scanner.

Несколько интересных наблюдений которые я понял в экспериментах.

QRCode не обязательно должен печатсться квадратиками. Я прогонял его
через фильтры гаусса (ФНЧ) и потом threashold по 50% и получал соседние пикселы
как-бы смазанные в овал или кляксу в зависимости от соседства. Но даже
в этом случае мобила уверенно распознавала ссылку.

В рекламных буклетах я часто находил этот дизайнерский прием.

Я повреждал пикселы. Инвертировал несколько штук. Мобила уверненно
распознавала.

Один фреймворк QRCodeGen различает 4 уровня коррекции.




Насколько я понял чем выше уровень коррекции ((H)igh) тем больше технической инфы в QR
коде но тем больше возможности по восстановлению.

В некоторых рекламах рекламщики как-бы издеваясь помещали в центр QRCode логотип своей
маркетинг акции и ... такая сломаная картинка тоже распознавалась.

Вот генерилка где можно поэкспериментировать.

https://www.the-qrcode-generator.com/

Фотоны шумят...

Тебе повезло еще. Могло и не распознаться.

P.S. А мог бы ножичком полоснуть.... (анкедот)

Если взять скрин моника (1920 х 1080) и самым мелким растрвоым шрифтом (5х5) напечатать текст.
То будет. С учотом межстрочного интервала в 1 px.

320x180 знакомест. Далее файл - печатаем в кодировке base64 (там полезная нагрузка 6/8 или три четверти)
итого получается 43200 или 42 килобайта полезной инфы.

Далее фоткаем мобилой и пытаемся распознать каким-нибудь FineReader или Tesseract. Здесь я не уверен
что FineReader осилит. У него слишком много кастомизаций на классический текст и base64 поток он может
воспринимать как ошибку. И знесь я не уверен как будет наведена резкость мобилы. Для моего Xiaomi 9 Pro
пишут следующую инфу по камерам 64 Мп + 8 Мп + 5 Мп+ 2 Мп. Знать бы что это такое. Разрешение каждой
камеры? А как тогда узнать какая камера была активна на съемке? Если перемножить исходник то получается
примерно 2 Мб. Но здесь старик Котельников неодобрительно ворчит. Надо бы хотя-бы в 2 раза выше чтоб
дискретность матрицы перекрывала оригинал. Тоесть камера в 5Мп - самое оно.

Правильно ли я понимаю что если я буду снимать на расстоянии примерно 20 см с экрана - то
буду с большой вероятностью использовать макро-камеру в 5мп?

Спасибо. Интересно.

Посмотрел это.



Здесь всё - во много раз хуже. Я имею в виду пересъёмку мобилой видео.
Современные видео-кодеки неспособны передавать отдельные пикселы.
В этом их суть. Поэтому надо заложить ... не знаю может 10 кратный запас
по разрешению и по частоте кадров.

Сама идея передчи анимированного QRCode или цветового кода наподобие Jabber - хороша.
Я тоже о ней думал. Но это будет 2 фаза моего investigation. И я хотел задействовать
видеокодк avi с высоким разрешением на весь скрин но без сжатия и с низким fts.
У меня уже был опыт создания презентаций (теч-демо алгоритма) где нужно было по
сути медленно переключать кадры как будто я в PowerPoint медленно кликаю next-next e.t.c.

Я проводил эксперименты с Photoshop еще в 2000х и тогда для моих тестовых картинок
JPEG всегда превносил разрушения даже когда я указывал quality = 100%. Тестовые картинки
содержали нечто похожее на настроечную таблицу. Тонкие линии. Горизонтальные. Вертикальные.
Сеточка шахмат. И цветовые контрастные переходы.

Кстати даже если-бы DCT вывести на точность близкую к оригиналу - там еще есть YUV subsampling
который в разных режимах просто прореживает цвет. Тоесть черно-белый канал 1:1 а цвето-разностные
с низким разрешением.