Skip to content

deblinux-dev/Visual-Transfer-Protocol

Repository files navigation

Visual Transfer

Visual Transfer Logo

GitHub License JS ELECTRON ELECTRON ANDROID WINDOWS 10 WebAssembly ZedIDE Version

QR Code Color QR Cimbar JAB Codes Aruco Color Matrix

Открыть Демо

Визуальная передача данных между устройствами через камеру и экран — без интернета, Bluetooth, NFC или кабеля.

Содержание

  1. Обзор проекта, демонстрация и принцип работы
  2. Фонтанные коды
  3. Какой тип кода выбрать
  4. ArGRID
  5. Зачем это нужно?
  6. Структура проекта
  7. Сборка и развёртывание
  8. Используемые библиотеки и благодарности
  9. Лицензия
  10. Контакты

1. Обзор проекта

Что это такое?

Visual Transferприкладной протокол передачи данных (файлов и текста) между двумя устройствами через визуальные 2D-коды, отображаемые на экране одного устройства и считываемые камерой другого. Никаких сетевых протоколов, никаких парных соединений, никаких предварительных настроек. Одно устройство показывает код — другое снимает.

Это не просто игрушка, а полноценное приложение, позволяющее использовать его в повседневных или профессиональных задачах даже на текущем этапе развития проекта. Протокол ориентирован на удобство и интеграцию, в отличие от аналогичных, более ранних проектов вроде TxQR и подобных, может работать даже в браузере, не требуя внешних зависимостей и установки приложений. Для оффлайн-использования доступна версия Android и Electron (для Windows), см. в Releases.

Примечание: Изначально вместо тяжёлого Electron планировалась сборка на Tauri, но от данной идеи пришлось отказаться из-за аппаратных ограничений разработчика (Core 2 Duo, 6 Gb RAM), так как установка, компиляция компонентов, сборки занимали бесчисленное количество времени и очень сильно нагружали ресурсы ПК.

Демонстрация работы

Получение большого текста (режим QRx1)

Получение большого текста (режим QRx4)

Получение изображения (режим QRx9)

«Скачиваем» книжку «Айболит» через камеру

Возможности:

  • Работа прямо в браузере без установки приложений
  • Множество режимов и параметров. Настраивайте клиент и транслятор так, как вам нужно, под конкретное устройство и задачу.
  • Сохранение кодов в видеофайл для последующего переноса.
  • Трансляция на внешние экраны, потоки (в разработке) — преимущественно только в standalone-версии)
  • Поддержка сжатия текста и различных медиаформатов
  • Автообнаружение типа кода через камеру телефона (в разработке, может быть нестабильным)

Принцип работы

  1. Отправитель кодирует данные (текст или файл) с помощью фонтанных (fountain, LT, коды Луби) кодов — данные разбиваются на блоки, из которых генерируется бесконечный поток кодированных кадров.
  2. Каждый кадр визуализируется в виде выбранного типа 2D-кода: Colored QR, Cimbar, ArGRID, JAB и т.д.
  3. Получатель снимает экран камерой, декодирует каждый видимый кадр и накапливает уникальные блоки.
  4. Когда получено достаточно уникальных блоков (K + ε), исходные данные полностью восстанавливаются.

Ключевое свойство: порядок кадров не важен, пропущенные кадры не мешают, дубликаты автоматически отсеиваются. Достаточно поймать ~K уникальных кадров из бесконечного потока.

Поддерживаемые типы кодов

Тип Ёмкость/кадр Технология Описание
QR ~300 Б qrcode-generator Классический чёрно-белый QR
Color QR ~900 Б 3-канальный QR Три QR-кода в R/G/B каналах, компенсация баланса белого и искажения цветов дисплеями
QR 4× / 9× 800 / 1350 Б Сетка QR Фонтанное кодирование, 4 или 9 QR на экране
Color QR 4× ~3600 Б Сетка Color QR 4 цветных QR с фонтанными кодами, довольно высокая скорость передачи данных даже при сравнительно низком Scan FPS получателя
Cimbar 3300–9300 Б WebGL + WASM (libcimbar) Цветная матрица, высокая плотность данных. Немного улучшенная версия оригинальной библиотеки, самая высокая скорость передачи данных при высоком разрешении камеры принимающего устройства
JAB Code ~387 Б WASM (jabcode) Многослойный цветной 2D-код, слегка улучшенная и исправленная технология. Ранее плохо работала с кириллицей, сейчас данный недостаток устранён, сканер портирован для работы в браузере в режиме реального времени
ArGRID ~169 Б Canvas + ArUco/WASM Авторская разработка, сетка ArUco-маркеров
Color Matrix ~576 Б Canvas + Chunked GIF (mezinster/cimbar) Цветная матрица с Reed-Solomon, улучшенные маркеры детекции на основе Aruco (вместо старых ненадёжных маленьких квадратиков). Не подходит для передачи большого объёма информации — требует оптимизации (не загружайте в него файлы тяжелее ≈100 Кб на слабых устройствах).

Технологический стек

  • Фронтенд: Vanilla JS, HTML5 Canvas, WebGL, Tailwind CSS.
  • WASM-модули: libcimbar (C++ -> Emscripten), aruco-rs (Rust -> wasm-pack), jabcode (C11 -> Emscripten), AprilTag (C -> Emscripten), OpenCV.js.
  • Алгоритмы: Luby Transform (фонтанные коды), Reed-Solomon (ECC), ArUco-детекция, Otsu-порог, Grey-World баланс белого
  • Оболочка: Electron (опционально) с трансляцией видеопотока через HLS/UDP, Capacitor для андроид.
  • Сжатие: Browser-native CompressionStream (Deflate / Gzip). Опционально.

Note

Для оптимизации процессов рефакторинга и документирования кода использовался ИИ-ассистент на базе моделей Qwen. Коммерческие сервисы (Claude, Gemini) в разработке не задействовались.

TODO:

  • Собрать проект под Linux, OS X, IOS (пока отсутствуют ресурсы для тестирования и отладки под платформы Apple).
  • Заменить LT (Luby) Codes на более быструю реализацию Raptor (RAPid TORnado).
  • Улучшить функцию автораспознавания типа кодов.
  • Исправить имеющиеся UI-баги.
  • Выполнить дополнительную оптимизацию производительности.
  • Добавить встроенный просмотрищик таких форматов, как HTML/XML, видеоформаты, Lottie.
  • Улучшить алгоритмы сжатия для ускорения передачи некоторых типов данных.

2. Фонтанные коды

Что такое фонтанные коды

Фонтанные (fountain) коды, или rateless erasure коды — это класс кодов, преобразующих фиксированный набор данных в бесконечный поток кодированных символов. Главное свойство: для восстановления исходных данных получателю нужно собрать любые K + ε уникальных символов, где K — количество исходных блоков, а ε — небольшая избыточность (~5-10%).

Аналогия: представьте, что вы разрезали документ на K кусочков и выбрасываете их с самолёта. Собирающий может поднять любые K кусочков в любом порядке и собрать готовый документ. Если какой-то кусочек унёс ветер — не проблема, просто найдите другой кусочек, в котором есть отсутствующая у вас часть.

Почему фонтанные коды, а не просто «показываем 2D-код один за другим»?

Без фонтанных кодов передача через экран -> камера работает так: данные разбиваются на N кадров, показываются по очереди. Если камера пропустила кадр №7 (моргание, расфокус, рука дёрнулась) — данные потеряны. Придётся ждать, пока цикл дойдёт до кадра №7 снова. При 30-кадровой передаче и большом проценте потерь — цикл может повториться много раз, а чем выше размер файла, тем критичнее будет пропуск хотя бы одного кадра.

С фонтанными кодами каждый показанный кадр равноценен. Пропустили кадр? Не важно — следующий даст новые данные. Никакого ожидания «нужного» кадра. Передача завершается, как только накоплено K уникальных блоков, а это происходит почти сразу (при стабильной съёмке).

Конкретно в нашем проекте:

  • Belief Propagation (BP) — основной декодер. Ищет блоки степени 1 (XOR одного исходного блока) → восстанавливает исходный блок → вычитает его из остальных кодированных блоков → повторяет. Это O(K²) в худшем случае.

  • Gaussian Elimination (GE) fallback — когда BP застревает (нет блоков степени 1, но уже получено ≥ K блоков), строится матрица над GF(2) и решается гауссовым исключением. Это пробивает циклы зависимостей, которые парализуют BP. Комбинация BP + GE снижает требуемый оверхед ε с ~10% до практически оптимальных значений.

  • Детерминированное кодирование через seed — отправитель и получатель используют одинаковый PRNG (Mulberry32) с одним и тем же seed'ом. Получателю не нужно передавать, какие именно исходные блоки были перемножены — он восстанавливает это из сида. Сид передаётся в заголовке каждого кадра (всего 4 байта).

3. Какой тип кода выбрать

Caution

ВНИМАНИЕ! Особая осторожность для людей, страдающих эпилепсией (особенно фотосенсорной эпилепсией). Быстрая последовательность сменяющихся друг за другом кодов разного цвета может спровоцировать приступ. Пожалуйста, перед использованием приложения убедитесь, что вы не находитесь в зоне риска и быстро сменяющиеся образы/паттерны/узоры безопасны для вас. Наименее опасными, теоретически, являются чёрно-белые коды Aruco (ArGRID) и QR-коды, наиболее потенциально опасными — Color QR, Cimbar, Color Matrix, JAB Codes.

QR (одиночный)

Ёмкость: ~300 Б     Скорость: низкая      Надёжность: высокая

Когда использовать: Короткие и средние текстовые сообщения (URL, пароль, Wi-Fi данные, короткие сообщения, одностраничный текст, маленькая иконка). Идеально для демонстрации концепции.

Color QR

Ёмкость: ~900 Б     Скорость: низкая      Надёжность: высокая

Когда использовать: Текст среднего размера. Три QR-кода упакованы в R/G/B каналы одного изображения. Требует корректной цветопередачи экрана и камеры. Декодер автоматически корректирует баланс белого и устраняет взаимное проникновение каналов (color bleeding, размытие цвета).

QR 4× / 9×

Ёмкость: 800 / 1350 Б   Скорость: высокая   Надёжность: высокая

Когда использовать: Текст и небольшие файлы. 4 или 9 QR-кодов отображаются одновременно в сетке, каждый несёт один фонтанный блок. Фонтанное кодирование гарантирует завершение передачи при стабильной съёмке. На тестах показывает скорость передачи вплоть до 15 Кб/с.

Color QR 4×

Ёмкость: ~3600 Б   Скорость: низкая   Надёжность: средняя

Когда использовать: Файлы до ~100 КБ. Комбинация цветных QR и фонтанных кодов. Самая высокая плотность среди QR-based методов, но скорость может быть ниже из-за искажения цветов и затрат на коррекцию входного изображения.

Cimbar (WebGL/WASM)

Ёмкость: 3300–9300 Б   Скорость: высокая   Надёжность: высокая

Когда использовать: Передача файлов и больших текстов. Рендерится через WebGL с помощью скомпилированного из C WASM-модуля libcimbar. Три режима плотности: mini (Bm), reduced (Bu), standard (B). Фреймрейт 8-15 FPS. Поддерживает внутреннее zstd-сжатие и собственные fountain-коды. Лучший выбор для больших данных. Высокая скорость передачи, но требуется камера высокого разрешения, хороший дисплей для отображения.

JAB Code

Ёмкость: ~387 Б   Скорость: низкая      Надёжность: низкая

Когда использовать: Когда нужен цветной 2D-код стандарта (ISO/IEC 23634:2022). До 8 цветов. Работает через WASM-воркер. Невысокая плотность, но стандартизированный формат. Лучше всего работает именно 8-цветный вариант со стандартными настройками, но в целом не стоит ожидать от него чудес.

ArGRID

Ёмкость: ~169 Б/кадр   Скорость: высокая (при меньшей вместимости)   Надёжность: средняя

Когда использовать: Условия с сильными искажениями перспективы, вращениями, частичными перекрытиями. Авторская разработка. Довольно быстро обрабатывается, но имеет невысокую скорость передачи данных.

Color Matrix

Ёмкость: ~576 Б   Скорость: низкая   Надёжность: средняя

Когда использовать: Когда нужна максимальная надёжность при приличной ёмкости. Reed-Solomon (64 байта чётности на 191 байт данных), чередование блоков (interleaving) для защиты от пакетных ошибок, якорный маркер (ArUco), устойчивая к освещению классификация цветов (двухэтапная: относительные разности + хроматичность).

Сравнительная таблица

Критерий QR Color QR QR 4/9× Cimbar ArGRID Color Matrix
Ёмкость ★☆☆ ★★☆ ★★★ ★★★ ★☆☆ ★★☆
Скорость ★☆☆ ★☆☆ ★★☆ ★★★ ★★★ ★★☆
Устойчивость к поворотам ★★★ ★★☆ ★★★ ☆☆☆ ★★☆ ★★☆
Устойчивость к перекрытиям ★☆☆ ★☆☆ ★★☆ ☆☆☆ ★★☆ ★☆☆
Работа при плохом освещении ★★★ ★☆☆ ★★★ ☆☆☆ ★★☆ ★☆☆
Не требует цветной камеры

4. ArGRID (Aruco Grid)

Что это?

ArGRID — авторская разработка, представляющая собой сетку из ArUco-маркеров, где каждый маркер несёт данные. В отличие от всех остальных типов кодов, где данные кодируются в пиксели квадратных ячеек, ArGRID кодирует данные в идентификаторы (ID) уже существующих ArUco-маркеров.

Как это работает

  1. Данные конвертируются из байтов в число в системе счисления с основанием 990 (количество доступных ArUco-маркеров из словаря).
  2. Это число «разворачивается» в последовательность ID маркеров, которые размещаются в ячейках сетки.
  3. Каждый маркер детектируется библиотекой (aruco-rs на Rust/WASM или OpenCV.js) — библиотека возвращает ID и координаты углов.
  4. По углам маркеров восстанавливается перспективная трансформация → определяется, в какую ячейку какой маркер попал → извлекаются данные.

Многомерное кодирование

Один ArUco-маркер может нести до ~10.2 бит данных за счёт комбинации трёх измерений:

  • ID маркера — 990 значений (~9.95 бит). Каждый маркер из словаря 6×6 имеет уникальный ID.
  • Цвет — 4 цвета (чёрный, тёмно-красный, тёмно-бирюзовый, тёмно-фиолетовый), +2 бит.
  • Поворот — 4 ориентации (0°, 90°, 180°, 270°), +2 бит.

Итого: 990 × 4 × 4 = 15 840 комбинаций на ячейку (BASE_FULL = 15840, ~13.95 бит).

Цвета выбраны с расчётом на максимальное межцветовое расстояние при шумах камеры — все четыре цвета имеют одинаковую яркость (~20% от белого), отличаясь только по цветности.

Преимущества ArGRID

1. Устойчивость к перекрытиям. Если палец или тень перекрывает часть кода — теряется один маркер, а не целый «куст» пикселей. Маркеры детектируются индивидуально, и потеря даже нескольких не мешает декодированию остальной сетки (есть brute-force восстановление пропущенных ячеек).

2. Устойчивость к перспективным искажениям. ArUco-маркеры детектируются с точностью до субпикселя, и библиотека возвращает координаты всех 4 углов каждого маркера. Это позволяет точно восстановить перспективную трансформацию даже при сильных углах съёмки — маркер «восстанавливает себя» из любого ракурса.

3. Не чувствителен к освещению. ArUco-детекция работает по бинарному шаблону маркера (чёрные/белые ячейки внутри 7×7), адаптивно порогируя изображение. В отличие от цветных кодов (Cimbar, Color Matrix), ArGRID не требует корректной цветопередачи.

4. Автоопределение размеров сетки. Клетка [0,0] содержит индикаторный маркер с ID из диапазона 990–997, однозначно кодирующий размер сетки (3×3, 5×5, 7×7, 8×8, 10×10, 12×12, 16×9). Достаточно увидеть хотя бы один индикатор — получатель знает размер всей сетки.

5. CRC-16 для каждого кадра. Два байта контрольной суммы в заголовке кадра позволяют мгновенно отбраковать некорректно считанные кадры, не тратя время на декодирование.

6. Двойная ориентация. Если камеру держат под углом 90° (портрет вместо ландшафта), сканер пробует декодировать сетку в обеих ориентациях и запоминает рабочую (кеш _lastWorkingTransposed).

Ограничения

  • Низкая плотность данных (~169 Б/кадр) — каждый маркер занимает ~100+ пикселей, но несёт максимум ~10 бит.
  • Требует библиотеку ArUco (WASM-модуль ~5 МБ или OpenCV.js ~8 МБ).
  • Плохо работает при сильно размытой камере.

Когда ArGRID лучше всего подходит

  • Съёмка под сильными углами (телефон в руке, наклонённый экран)
  • Частичные перекрытия (пальцы, блики, тени)
  • Плохое/неравномерное освещение
  • Быстрая передача небольших данных (текст, настройки, контакты)
  • Если вы не хотите использовать QR :D

5. Зачем это нужно?

Контраргументы на «у нас же есть Bluetooth/Wi-Fi/IR/NFC!!!»

«Зачем передавать через камеру, если есть Bluetooth?»

  • Bluetooth требует сопряжения — оба устройства должны быть «паре». В корпоративных/гостевых сетях Bluetooth часто отключён политикой безопасности.
  • Visual Transfer не требует никакого соединения. Одно устройство показывает, другое снимает. Нулевая настройка.
  • Bluetooth работает на расстоянии ~10 м и требует, чтобы оба устройства были сопряжены, находились рядом, видели друг друга, включили обнаружение и, порой, ещё кучу соблюдённых условий. Visual Transfer работает на любом расстоянии, до которого «добивает» камера — хоть через видеозвонок, хоть по телевизионной трансляции, хоть при фотографирования экрана с другого конца комнаты (в теории), с терминала, дисплей-баннера, экрана другого смартфона и т.п.

«Wi-Fi Direct / AirDrop — это же то же самое, только быстрее?»

  • AirDrop работает только между устройствами Apple. Wi-Fi Direct — только на некоторых устройствах и ОС.
  • Оба требуют, чтобы устройства знали друг о друге (обнаружение, подтверждение).
  • Visual Transfer — строго однонаправленный протокол передачи. Отправитель даже не знает, кто получает данные. Это делает возможным сценарии, невозможные с pair-протоколами.

«Инфракрасник / Li-Fi / QR из контактов — уже всё для этого есть!»

  • IR имеет скорость ~250 Кбит/с и требует прямой видимости на расстоянии < 1 м.
  • Стандартный QR в контактах — это статический код. Он не передаёт файлы, не потоковый, вы через него вряд ли комфортно передадите даже страницу текста.

Ещё есть NFC!!!*

  • Да, но он изначально проектировался не для передачи данных, требует наличия датчиков на устройствах, прямого контакта (менее 4 см), сопряжения и т.п. Через него лучше получить вредоносный код. Камера же есть на любом устройстве, расстояние не так критично, одновременно получать данные могут несколько пользователей.

Important

Несмотря на это, протокол не разрабатывался и не предназначен для передачи огромных объёмов информации. Пожалуйста, не пытайтесь передавать через него «Аватар» в 4К-качестве, Skyrim со всеми модами или GTA V — скорее всего, у вас зависнет передатчик или вы будете ждать передачи около сотни лет. :P

Уникальные сценарии применения

  1. Air-gapped среды. Помещения без сети (лаборатории, серверные, военные объекты, SCADA-системы). Visual Transfer — один из немногих способов передать файл с телефона/ПК на изолированное устройство.

  2. Публичные дисплеи. Информация на большом экране (аэропорт, конференция, выставка) может содержать ёмкие данные, которые зрители «скачают», просто наведя телефон. Без Wi-Fi, без QR-кода со ссылкой на сайт.

  3. Видеозвонки. Один участник видеозвонка показывает код — другой снимает экран. Данные проходят через видеопоток. Не важно, какой сервис видеосвязи — Zoom, Telegram, Skype — они все передают пиксели.

  4. Печатные материалы. Звучит забавно, но теоретически код может быть распечатан на бумаге. Получатель снимает последовательность — данные восстановлены. Это похоже на обычное сканирование статики, но с фонтанными кодами — можно напечатать «ленту из кодов» и отсканировать её :D. Хотя, разумеется, это не совсем то, для чего создавался протокол.

  5. Разнородные устройства. Любое устройство с экраном + любое устройство с камерой. Смартфон ↔ ноутбук ↔ планшет ↔ умный ТВ ↔ камера наблюдения. Никакой специфической совместимости по ОС или протоколам не требуется, если вы сможете подружить софт или заснять данные для последующей расшифровки.

  6. Публичная передача (broadcast). Один отправитель — множество получателей. Классический пример: преподаватель показывает код на проекторе — 30 студентов снимают его телефонами одновременно. Все получают большой текст/файл. Библиотеки, музеи — тоже подходят под эту категорию (передать файл с историей экспоната на несколько страниц прямо документом, изображение-баннер, промо-визитку — что угодно и без спец. датчиков. Всего лишь нужен простейший экран.)

  7. Взаимодействие с IoT. Устройство без Wi-Fi/Bluetooth (например, промышленный контроллер с экраном) может выводить данные в виде кода, а оператор считывает их планшетом.

Сравнение с альтернативами

Критерий Bluetooth Wi-Fi Direct NFC IrDA Visual Transfer
Требует сопряжения ✅ да ✅ да ✅ да ❌ нет ❌ нет
Требует спец. приёмника на обоих устройствах ✅ да ✅ да ✅ да ✅ да ❌ нет
Работает через видеозвонок/трансляцию ❌ нет ❌ нет ❌ нет ❌ нет ✅ да
Публичная трансляция «One-to-All» ❌ нет ⚠️ ограниченно ❌ нет ❌ нет ✅ да
Air-gapped среда ❌ нет ❌ нет ⚠️ малые данные ⚠️ < 1 м ✅ да
Разнородные ОС ⚠️ ограниченно ⚠️ ограниченно ❌ нет ⚠️ ограниченно ✅ да
Зависимость от освещения ❌ нет ❌ нет ❌ нет ⚠️ да ⚠️ зависит от типа

6. Структура проекта

Общая архитектура

project/
├── public/app/                  ← Основное веб-приложение
│   ├── index.html               ← Основная HTML-страница
│   ├── css/style.css            ← Стили
│   ├── js/                      ← Логика приложения
│   ├── cimbar/                  ← WASM-модуль Cimbar (Emscripten)
│   ├── argrid/                  ← ArUco-детекция (Rust/WASM + OpenCV.js)
│   ├── jabcode/                 ← JAB Code WASM + worker
│   ├── apriltag/                ← AprilTag WASM (альт. якоря, не исп.)
│   ├── img/                     ← Превью-изображения кодов
│   ├── lottie/                  ← Lottie-анимации
│   └── vendor/                  ← Сторонние библиотеки, для оффлайн-работы
│
│── android/                     ← Нативный проект Android (Capacitor)
│── standalone/                  ← Electron-приложение
│── repo-assets/                 ← Доп. ресурсы для README
│── assets/                      ← Исходные графические ресурсы приложения
├── icons/                       ← Папка для Capacitor assets generator.
│
├── capacitor.config.json        ← Конфигурация мобильной среды
└── package.json              ← Зависимости сборщика и плагины Capacitor

7. Сборка и развёртывание

Проект спроектирован так, чтобы работать без сложного этапа компиляции на стороне фронтенда (чистый Vanilla JS ESM + готовые WASM-модули). Благодаря указанию директории "webDir": "public/app" в конфигурации Capacitor, нативные сборки напрямую используют исходную кодовую базу в папке public.

Требования

  • Node.js (версии 18+)
  • NPM (поставляется вместе с Node.js)
  • Для сборки Android: Android Studio, установленный SDK и корректно настроенные переменные окружения (ANDROID_HOME). Либо настроенный GitHub Actions Workflow.

1. Локальный запуск (Веб-версия)

Поскольку проект активно использует JavaScript-модули (ESM) и WASM, обычное открытие файла index.html через двойной клик (file://) заблокируется политиками CORS безопасности браузера. Необходим локальный веб-сервер.

1. Склонируйте репозиторий:

git clone https://github.com/deblinux-dev/visual-transfer-protocol.git
cd visual-transfer-protocol

2. Поднимите любой локальный статический сервер из корня репозитория (Node, python, Simple Web Server и т.п.):

# Вариант А: Быстрый запуск через Node.js (рекомендуется)
npx serve public/app

# Вариант Б: Использование Python
python -m http.server 8080 --directory public/app

3. Откройте предоставленный локальный адрес (к примеру, http://localhost:8080) в браузере.

2. Десктопная версия (Electron)

Electron-сборка используется для оффлайн-работы на ПК и включает экспериментальные функции трансляции видеопотока через HLS/UDP локальной сети.

1. Перейдите в каталог десктопной версии (standalone) и установите внутренние зависимости:

cd standalone
npm install

2. Запустите приложение в режиме отладки:

npm start

Для сборки:

# Обычная сборка:
npm run build

# Или для сборки portable:
npm run build-portable

3. Мобильное приложение

Установите зависимости проекта в корневом каталоге:

npm install

Синхронизируйте веб-интерфейс public/app с нативным Android-проектом:

npx cap sync android

Сгенерируйте иконки и экраны загрузки из исходников в папке assets/:

npx capacitor-assets generate --android

Откройте проект в среде Android Studio для финальной компиляции:

npx cap open android

В интерфейсе Android Studio выполните сборку: Build > Build Bundle(s) / APK(s) > Build APK(s).


8. Используемые библиотеки и благодарности

Visual Transfer Protocol целиком основан на open-source. Разработка сложных высокоплотных режимов сканирования и адаптация существующих библиотек под работу в браузерах стали возможны благодаря наработкам следующих авторов:

9. Лицензия

Проект распространяется под лицензией GNU Affero General Public License v3.0 (AGPL-v3).

Что это значит для разработчиков и пользователей:

  • Открытый исходный код: Вы имеете полное право модифицировать, копировать и распространять данный софт.
  • Сетевое копилефт-условие: Если вы используете этот код, его части или модифицированные версии в составе своего веб-сервиса (даже если пользователи работают с ним удалённо через веб-интерфейс/браузер, как в случае с GitHub Pages), вы обязаны предоставить пользователям доступ к полному исходному коду вашей модифицированной версии под той же лицензией AGPL-v3.
  • Сохранение авторства: Оригинальные копирайты автора должны быть сохранены во всех производных проектах.

Внимание: Входящие в состав сторонние бинарные WASM-модули и библиотеки (такие как движки JAB Code, libcimbar или OpenCV) регулируются условиями их собственных open-source лицензий.


10. Контакты

Если у вас возникли вопросы по спецификации прикладного протокола, предложения по оптимизации или вы хотите помочь с нативным портированием и тестированием под iOS/macOS — вы можете связаться со мной или принять участие в развитии проекта:

  • Автор / Разработчик: DebLinux
  • GitHub Профиль: @deblinux-dev
  • Поиск багов и предложений: GitHub Issues
  • Связь в Telegram: @DebLinuxx

Вы можете развернуть свою локальную версию, протестировать её на имеющихся устройствах и отправить Pull Request. Любой вклад в оптимизацию алгоритмов или UI приветствуется.

Important

Пожалуйста, не отправляйте Pull Requests, если ваше исправление или нововведение ломает работу приложения, сгенерировано целиком ИИ и не проверено на работоспособность вами лично. Это облегчит работу по поддержанию проекта в работоспособном состоянии.

About

Визуальная передача данных между устройствами через камеру и экран — без интернета, Bluetooth, NFC или кабеля.

Topics

Resources

License

Stars

Watchers

Forks

Packages

 
 
 

Contributors