Сжатие данных *

1. Назначение

CJON – это легковесный, компактный и человекочитаемый формат, предназначенный для использования в условиях ограниченных каналов связи, таких как SMS, DTMF, и низкоскоростная радиосвязь. Его основное назначение – передача структурированных телеметрических или управляющих данных в случаях, когда традиционный JSON слишком объёмен, а бинарные форматы непрактичны или плохо читаемы.

2. Области применения

• Дистанционная телеметрия для сельского хозяйства и промышленного оборудования
• Аварийные сообщения и тревоги
• Автоматизация в условиях низкоскоростной или оффлайн-связи
• Мобильные устройства, передающие структурированные данные через SMS или голосовую связь
• Передача данных по DTMF через GSM-сети

Недавно опубликованная третья редакция спецификации Portable Network Graphics (PNG) 2025 года, разработанная World Wide Web Consortium (W3C), привлекла внимание к эволюции этого формата (W3C PNG Specification (Third Edition, 2025)). Ранее я, как и многие, использовал PNG, не задумываясь о его развитии и различных редакциях. Углубившись в изучение спецификаций PNG (1996, 2003, 2025), я решил подготовить данную статью, чтобы обобщить ключевые изменения и их значение для веб-дизайна, разработки игр и мультимедиа. Статья не претендует на исчерпывающий охват, но стремится предоставить полезный обзор для всех заинтересованных, включая начинающих. Приветствуются любые замечания и предложения по улучшению материала в комментариях к публикации. Весь код, приведённый ниже, выложил в репозиторий. Надеюсь, чтение будет полезным и увлекательным.

Современные большие языковые модели впечатляют, но остаются громоздкими и статичными. В ближайшие годы мы перейдём от таких «гигантов» к персональным ИИ-спутникам: компактным и обучаемым на ходу. Ключ к этому — долговременная память (mem-векторы), модульные трансформеры, параметро-эффективное дообучение, внешние базы знаний и жёсткая оптимизация под локальное железо. Разбираем, какие технологии уже работают, какие ещё только вырастают из лабораторий и что ждёт нас завтра.

Каждый, кто работал с большими языковыми моделями (LLM), знает про ограничение длины контекста: модель не может напрямую обработать текст, превышающий определённое число токенов. Это накладывает ограничения на работу с длинными документами и обширным контекстом. Но что если бы мы могли упаковать длинный текст в один-единственный вектор и скормить его модели как обычный токен? Звучит фантастично, однако свежие исследования показывают, что это возможно – такие “mem-векторы” позволяют сохранить сотни и даже полторы тысячи токенов информации в одном эмбеддинге. Это принципиально иной подход, нежели классическое сжатие данных, и он сулит интересные применения.

Mem-вектор (от “memory vector”) – это специально обученный вектор, который хранит содержание целого текста. Идея в том, что если модель умеет предсказывать текст, то можно подобрать такой вектор на входе, при котором замороженная (неизменяемая) LLM сама декодирует исходный текст. Иначе говоря, mem-вектор играет роль «семени», из которого предобученная модель порождает заложенное в нём сообщение. В этой статье разберём, как это работает, почему вообще возможно “запихнуть” роман в один вектор и какие ограничения при этом появляются. Также сравним mem-подход с классическими алгоритмами сжатия (Huffman, арифметическое кодирование, zlib и др.), обсудим последние научные работы на эту тему и возможные применения: от Retrieval-Augmented Generation (RAG) до передачи новых знаний замороженным моделям. Центральная мысль: mem-векторы – это не просто компрессия текста, а способ напрямую скормить модели смысл и знания, минуя последовательное чтение токенов.

Давайте разберёмся в том, как работает новый метод квантования больших языковых моделей HIGGS (Hadamard Incoherence with Gaussian MSE-optimal GridS)

Как экономить до 90% оперативной памяти при загрузке pandas DataFrame из базы данных?

Сравним различные способы выгрузки данных и найдем метод для снижения потребления оперативной памяти.

Недавно прочитал статью на Пикабу про бесконечное сжатие, где предлагалось создать словарь 3-х байтовых блоков, и представлять информацию в виде ссылок на эти блоки. Понял что выигрыша в этом нет, но идея передавать не саму информацию, f что-то другое, меня зацепила. Начал размышлять, допустим демон на дне океана перекусывает нитку оптоволокна и смотрит как туда сюда бегут 1 и 0. Какой в них смысл? Одно и тоже. И правда как извлечь смысл из этого однообразия. А здесь вступают в игру фактор времени и договоренности. То есть добавляются дополнительные измерения о которых демон не знает. Стартовые, стоповые биты, длина пакета.

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

Как уместить словарь размером 250 КБ в 64 КБ ОЗУ с возможностью выполнения быстрого поиска? Для справки: даже современные методики сжатия наподобие gzip -9 не могут сжать этот файл до размера меньше 85 КБ.

В 1970-х Дуглас Макилрой столкнулся с этой непростой задачей при реализации проверки правописания для Unix в AT&T. Из-за ограничений компьютера PDP-11 весь словарь должен был умещаться всего в 64 КБ ОЗУ. Кажется, подобную задачу решить невозможно.

Вместо того, чтобы использовать стандартные методики сжатия, Дуглас воспользовался преимуществами свойств данных, разработав алгоритм сжатия, отличавшийся от теоретического минимума сжатия всего на 0,03 бита. И по сей день этот рекорд остаётся непревзойдённым.

История spell в Unix — это не только любопытный исторический факт. Это мастер-класс по проектированию в условиях жёстких ограничений: анализа первооснов задачи, применения математических наблюдений и проектирования изящных решений, работающих в условиях строгого дефицита ресурсов.

Привет! Меня зовут Михаил Мазанов, я отвечаю за технологический стек работы с медиаданными в Кинопоиске: от съёмок оригинальных проектов до доставки и просмотра видео на всех экранах. Для нашей пятой ежегодной конференции про стриминг PlayButton 2024 я готовил большой доклад про оптимизацию качества видео Кинопоиска, а для Хабра решил пересобрать его в виде статьи — для тех, кому текстовый формат предпочтительнее видео.

Кроме технических графиков, вас ждёт ещё и наглядная разница в работе алгоритмов сжатия на примере «Рика и Морти» и «Джона Уика».

Привет, Хабр! Меня зовут Александр Крестинин, я разработчик встроенного ПО в компании Whoosh. Мы в embedded-команде не только переливаем биты из одного регистра в другой, но и решаем разные бизнес-задачи. Иногда попадаются головоломки. 

Однажды мы подумали, что было бы здорово выводить на экраны самокатов анимации и изображения — показывать инструкции, как пользоваться сервисом, как начать и закончить поездку, и чтобы запускать DOOM.

Зачем?

1) Сделать комфортнее. Удобно видеть инструкции на большом и ярком экране перед глазами, а не нырять за ними в приложение на смартфоне. 

2) Сделать безопаснее. Пользователь меньше отвлекается на телефон, крепче держится за самокат и внимательнее смотрит на всё, что вокруг.

3) Почти у всех привычных устройств уже есть экраны, которые выводят пользователям видео и картинки, а почему бы не сделать то же самое на самокате?

Но тут возникает проблема. Микроконтроллер крайне ограничен в памяти и вычислительных ресурсах. Самая простая анимация занимает чрезмерно много места. А если внедрить в отрисовку алгоритмы сжатия, то вычислительная нагрузка увеличится и анимация будет сильно лагать.

Расскажу, как мы нашли решение этой задачи. Прошу под кат.

В этой статье я поделюсь своим опытом и еще некоторыми утилитами

Вообще меня побудило написать эту статью прохождение курса Базовый курс по CTF на онлайн платформе Stepik, он бесплатный и по окончании выдается сертификат (это не реклама, а совет).

Перейдем непосредственно к утилитам.

Я уже подготовил файл «нашпигованый» двумя стегоконтейнерами. Файл скриншота рабочего стола 1.jpg

Проверим его наличие на рабочем столе ls.

Сегодня я хотел бы познакомить читателей Хабра с цифровой стеганографией. В нынешнем примере мы создадим, протестируем, проанализируем и взломаем стегосистемы. Я использую операционную систему Kali GNU/Linux, но кому интересна тема на практике, тот может повторить все то же в любом другом дистрибутиве Линукс.
Но для начала совсем немного теории.

Среди методов анализа информации, в данной статье представлен анализ распределения плотности информации в битовом блоке данных. Данный метод может быть ориентиром при разработке методов сжатия информации, так как дает оценки как распределена плотность информации в зависимости от состава блока, который определяется количеством нулей и единиц, формирующих битовый блок данных.

Привет, меня зовут Рома. Я работаю в отделе спецпроектов KTS на позиции Python backend-разработчика. 

Однажды мне взбрело в голову написать собственную имплементацию алгоритма сжатия RLE. В этой статье рассказываю подробнее про RLE: что это за зверь такой, где используется, чем плох, чем хорош, и какие неожиданные сложности могут возникнуть при попытке имплементации.

▍ Ошибка