Написал граф-ноды что бы посчитать для разных картинок размеры компрессии с разными преобразованиями

Очевидно LZP хорошо жмет (в 9 раз) картинку в которой те же цвета повторяются.

На сложной картинке (с лебедем) не так мощно сжатие идет.

Что интересно, если трансформировать картинку по одному алгоритму из PNG, то LZP сжатие становится чуть хуже на драконе, а на лебеде заметно лучше.

Теперь надо ANS сжатие добавить.

К слову, что вообще за LZP.

Название расшифровывается как Lempel-Ziv Predictive.
И это самый просто LZ-like, который к тому же еще и быстрый и эффективный на определенных типах данных.

Оригинальный LZ77 кодирует символы в последовательность ссылок на подстроки символов уже встреченных ранее (и не вышедших за окно) и литералы.
Это приводит к тому, что при кодировании приходится искать в окне самую длинную подстроку.

LZP не ищет подстроки. Вместо этого окно, обычно совсем небольшое, по сравнению с LZ77, например 4 символа, хэшируется. Этот хэш используется как ключ в кэш символов.
Если следующий символ равен символу в кэше - кодируем один бит 0. Если нет - кодируем бит 1 и литерал. И переписывает символ в кэше на новый.

Несмотря на простоту кодирования, LZP отлично себя показывает на данных, где за последовательностью символов с большой вероятностью идет такой же, как и в прошлый раз за такой последовательностью.
Но предел сжатия - 1 / symbol_bits если всегда будет хит в кэш. Тогда как LZ77 может сжимать в тысячи и миллионы раз, если в данных совсем нет энтропии (все символы одинаковые).

Причина номер 1, почему я не пишу что-то каждый день

Mutex превращает Send в Send+Sync

А Arc мог бы превращать Sync в Sync+Send, но требует Send тоже, только потому что можете вытащить T оттуда в другом потоке через get_mut и try_unwrap.

Вот вам и недостаток выразительности языка. Нет конструкции что бы сказать T: Send для этой функции если Self передавали в другой поток.

Если прям очень надо, можно сделать свой Ark, который будет Send+Sync where T: Sync, но без возможности получить T или &mut T из него

Когда вспоминаешь, что вышла серия, а там филер опять :(

Если вы делаете игру и там будет огненный меч - вот вам референс

Сразу и не заметишь, но как начнешь читать...

И вот это отбирает работу у художников.

Если вы еще гадаете, зачем нужны ИИ, так это для того что бы делать работу с нулевой суммой.

Например ИИ чтоб генерировать 10 страниц текста, где только одна строчка нужна тому, кому понадобилось это прочесть.
И потом ИИ для того что бы найти эту строчку на сайте.

ИИ что бы сгенерировать CV под каждую вакансию по профессии на всём LinkedIn
А у HR-а ИИ для поиска нормальных CV из миллиона присланных.

У нас уже есть ИИ, что бы разговаривать с ним вместо живых людей.
Значит ждем ИИ, что бы он разговаривал с живыми людьми вместо нас.

Любителям чисел посвящается

Абсолютно точное значение длины чего-то в метрах это рациональное или иррациональное число?

Тестируем как вам зайдет матъюмор

Сжимаю картинку.

Было 101 мегабит.
LZP жмёт её до 78 мегабит
LZ78 жмёт её до 57 мегабит

Обратимо фильтруем
LZP жмёт до 63 мегабит
LZ78 жмёт до 24 мегабит!!!

Как назло LZ78 разжимать на GPU намного менее удобно.
Думаем дальше

Столько разных боевых искусств. Я даже названий некоторых не знаю.

Самурай прям анимешный получился.

Но больше всего вариант Шаолинь понравился.

Искал адрес больницы на яблокартах.

Поиск: Hospital
Яблокарты:

Ну вот.
Теперь я трижды отец.

Я и 3д принтер

А вот настоящая текстура.
Тут эффект от нового фильтра даже больше, чем от Paeth