Комментарии 123
Еще лучше метод сжатия - ссылку на картинку в интернете даете и все.
Удивительно что когда я написал про это статью, то засрали карму так что я уже никогда не вернусь. А вам вон плюсиков настрочили.
Тут понимать надо: статьи ни о чем можно писать только в корпоративных блогах.
накинули так что нет давно ничего, квакнуть лишний раз боюсь даже в обсуждениях. спасибо сейчас народ плюсиков накидал, хотя бы писать могу комментарии не раз в год :)
Я готов поставить + в карму, но... что это даёт мне? Хочу, чтобы та самая статья была доступна, а не спрятана.
P. S. По моему опыту, в результате написания статьи карму повышают, даже когда статья заминусованная. А минусы прилетают за острые комментарии в тусовочных темах.
P. P. S. Ещё минусуют за агрессивные ответы на критику собственной статьи.
Другими словами, карму повышают за статьи, снижают за комментарии.
Это не всегда так, но в целом верно.
Хочу, чтобы та самая статья была доступна, а не спрятана.
Я думаю изменить акцент, поэтому возможно к концу года сделаю пару материалов по практике использования MOS 6502 на оригинальном железе. Пока мешают проблемы со здоровьем и финансовые сложности.
Старые платформы нравятся еще и тем, что это определенный вызов, трюки и твики, на Хабре есть статьи про такое, вот вероятно смогу дать что-то подобное. Надеемся на лучшее.
Другими словами, карму повышают за статьи, снижают за комментарии.
держи плюсик, мне не жалко. А статья шуточная, и я об этом написал
Есть еще короче. Описание для декодера: баба в шляпе.
Гораздо короче ссылки.
Укорачиватель ссылок ещё несколько десятков процентов к уровню сжатия даст))
Анекдот:
- Так мне Паваротти не понравился, картавит, в ноты не попадает...
- Вы были на концерте Паваротти?
- Нет, мне Рабинович по телефону напел.
Вы еще "Лена Сёдерберг" вбейте в генератор.
Потихоньку начинает проясняться механика возникновения ночных кошмаров.
вбил в midjourney Lena Soderberg
странно, но, нейросеть, реально, не поняла прикола, и показала, что вообще не в теме
Это mj? Stable Diffusion тоже не знает кто это, ни первая версия ни вторая:
Попробуй вбить Lenna Söderberg :)
Все равно не знает. Лены слишком мало в датасете, одной картинки недостаточно. Где-то видел исследования что SD удовлетворительно рисует только порядка сотни селебрити, причем совсем хорошо только пару десятков наиболее известных типа Эммы Уотсон и Харисона Форда. И это была первая версия, до того как датасет почистили от персоналий.
Мне какую-то хрень сгенерировала http://rudalle.ru/check_kandinsky2/9e4b4401796b456da845116784436e7f
Stable duffusion
Lena Soderberg in brown hat
negative: (deformed, distorted, disfigured: I 3), poorly drawn, bad anatomy, wrong anatomy, etfra limb, missing limb, floating limb a (mutated hands and fingers 1.4), disconnected limbs, mutation, mutated, ugly disgusting, blurry amputation
seed 3193650323
три очаровательные, весьма близкие мне особы
С козырей зашел...
Спасибо, улыбнуло много раз ))))))
Думаю, максимальной схожести оригинала и дешифрованного изображения можно добиться если использовать паттерны по аналогии с компьютерными шрифтами когда на принимающем устройстве уже содержатся шаблоны шрифтов (правила их графического вывода), а из источника достаточно передать лишь название шрифта и текст. В итоге принимающее устройство "нарисует" текст требуемым начертанием шрифта. Аналогично если будет некий строгий стандарт классификаций изображений (грубо говоря, по художественным стилям +каким-либо другим уточняющим признакам), то любое изображение можно разложить на этот ряд признаков, а затем достаточно точно воссоздать по ним оригинал. Это напоминает обычное языковое описание изображения, но будет более точным и лаконичным, без разночтений и искажений интерпретации.
Нейросети, генерирующие картинки по описанию, сперва создают миниатюру в низком разрешении, а затем уже другие нейросети повышают разрешение этой миниатюры и дополняют менее значимыми деталями. Аналогично и в способе сжатия помимо описательной части может быть сгенерирована миниатюра оригинального изображения, отображающая сам образ и взаиморасположение основных объектов, и в таком виде миниатюра + описательная часть представлять сжатый файл.
А можно пойти ещё дальше: и передающее, и принимающее устройство могут хранить не только абстрактные художественные паттерны, а вообще целостную библиотеку образов-аватаров - это как Википедия, но из графических образов, в том числе и трёхмерных. И уже оперировать этими образами, подставляя их в самые разные сцены - как совместимые (например, живая рыба в аквариуме), так и любые фентезийные.
DALL·E 2 по запросу "Lena Soderberg" выдал довольно неожиданное.
Я давно для бэкапов скачал архиватор, который сжимает любой объем данных до 1 байта. Делаю, как и положено, три копии.
Надеюсь, к тому времени, как данные мне понадобятся, автор архиватора, наконец, допилит обещанный разархиватор.
Почему "революционный"? Идея сжатия автокодировщиками (autoencoder) известна давно.
Размер архива считается как файл архива + размер разархивирова. У вас с коэффициентом сжатия все очень печально.
zanuda mode off
это если архив самораспаковывающийся ( т.е. с бинарником распаковщика и приданными к нему модулями)
Нет. Всегда. С бесконечным размером разархиватора размер любого архива составит байт 8 примерно. Ладно пусть 16 байт.
Нет. В 16 байтах информации, больше чем на эти самые 16 байт не влезет. (Доказательство, если нужно: жмём все числа подряд)
Заодно и вопрос-претензия к исходному комментарию: почему размер архива обязан считаться с учётом архиватора?
Нет. В 16 байтах информации, больше чем на эти самые 16 байт не влезет. (Доказательство, если нужно: жмём все числа подряд)
В смысле не влезет? Туда много чего влезет.
uint128 это довольно много. С учетом бесконечного размера разархиватора можно много интересного придумать. Здоровые предрассчитанные таблицы меняющие память на время даже в обычной разработке бывают полезны, а уж а такой специфичной теме как сжатие они совсем магию творить могут. С нейросетями все еще интереснее становится. Подробностей довольно много в интернете. Тема сложная в комментарии не описать. Начать стоит отсюда https://habr.com/ru/post/570694/ и далее по ссылкам.
Заодно и вопрос-претензия к исходному комментарию: почему размер архива обязан считаться с учётом архиватора?
Нет. Ибо это дает легкую возможность накрутить коэффициент сжатия бесплатно.
Всё-таки не влезет. См. идею про "всё уже записано в числе пи" (Нормальное число). Проблема в том, что для кодирования смещения в таком бесконечном архиве нужно число с энтропией порядка самих закодированных данных.
Ну и вообще, для интересующихся советую познакомиться с понятием Колмогоровская сложность — очень расширяет сознание архиваторостроителям.
uint128 это довольно много. С учетом бесконечного размера разархиватора можно много интересного придумать. Здоровые предрассчитанные таблицы меняющие память на время даже в обычной разработке бывают полезны, а уж а такой специфичной теме как сжатие они совсем магию творить могут.
Ну расскажите нам, какая магия позволит пожать случайное 32 байтное число в 16 байт без потери информации.
https://cs.stackexchange.com/questions/40239/compression-of-random-data-is-impossible
Не стоит проверять алгоритмы сжатия на случайных числах. Вы так ничего не получите. Принято проверять на чем-то структурированном, вроде всего текста Википедии.
Т.е. ваш алгоритм не работает на произвольных данных? Степень сжатия на рандомах проверять действительно не стоит, но тут вопрос в самой возможности сжатия.
Ну вы же сами утверждали, что
С бесконечным размером разархиватора размер любого архива составит байт 8 примерно. Ладно пусть 16 байт.
32 байтные случайные числа можно прогнать через архиватор и получившийся архив подпадает под квантор "любой".
Не стоит проверять алгоритмы сжатия на случайных числах.
Очень даже можно, упомянутые вами же тексты Википедии вполне себе представимы в виде чисел. И с точки зрения архиватора это будут вполне себе случайные числа, просто с неравномерным распределением. Это на равномерно распределенных случайных числах проверять архиватор бесполезно.
И структурированность тут не причем. Найдутся текст/картинка/etc, что не сожмется ни в 16 байт, ни в любое заранее заданное. Это прямое следстиве обратной теоремы Шеннона для источника общего вида.
вполне себе случайные числа, просто с неравномерным распределением
Произвольные -- да, случайные -- нет. При таком подходе все числа можно считать случайными, просто "с неравномерным распределением". Важнейшее качество Г[П]СЧ это как раз таки равномерность и непредсказуемость.
Множество случайных чисел с хорошим распределением это подмножество любых чисел. Архиваторы общего вида хорошо работают с множеством любых неслучайных чисел. Частные случаи архиваторов работают вообще с конкретными наборами чисел, например видео или текст или голос. С полностью случайными числами не работает ничего.
Для псевдослучайных чисел можно как обычно подобрать вырожденный пример. Ваш ГСЧ инициализируется seed int64. Просто передаем его и длину нужной последовательности и генерируем точно такие же псевдослучайные числа на другой стороне.
С полностью случайными числами не работает ничего.
Что значит не работает? Алгоритмы сжатия работают с потоками байт, им плевать случайные они или нет. Коэффициент сжатия может получиться равным 1, но работать он будет.
Ну и полностью случайные числа - это прям классный термин. Я так понимаю под ним понимается величина с равномерным распределением? Если да, то таки вы правы - его сжать не получится. И поэтому ваше утверждение про возможность сжать всё в 16 байт при неограниченном размере компилятора - это чушь.
Нет. Ибо это дает легкую возможность накрутить коэффициент сжатия бесплатно.
В том и смысл, что архиватор-то в одном экземпляре, размер его константен, а сжатой информации потенциально бесконечно много.
Более того: если считать по вашей методике, то коэффициент можно поднять просто архивируя склеенные файлы, верно?
Давайте, я разрешу ваш спор. (Извините, не знаю, кто вы, какие у вас компетенции и возраст. Также я не читал всю ветку дискуссии, но увидел, что она длинная).
Вопрос: взяли архиватор, сжали файл размером 1 гигабайт до размера 1 байт. Следует ли включить размер разархиватора (например, 2 гигабайта) в размер архива при вычислении степени сжатия?
Ответ: это зависит от информации, которой обладали разработчики (раз)архиватора на момент его разработки.
Если разработчики знали заранее, что (раз)архиватору будет подан на вход именно этот файл, то размер разахиватора следует включить в размер архива при вычислении степени сжатия.
Если же разработчики разрабатывали (раз)архиватор только на основе априорной информации (известной до того, как будет получена хоть какая-то информация о том, что именно мы собираемся сжимать), то следует смотреть только на размер архива, игнорируя размер разархиватора.
Пояснение: на практике мы не имеем полной информационной независимости между разработкой (раз)ахиватора и файлами, которые мы собираемся сжимать. Даже если предположить, что (раз)архиватор был разработан инопланетянами, не знающими ровным счётом ничего о нашей планете, информационная зависимость между разархиватором и сжимаемым файлом может возникнуть в ситуации, когда пользователь знает, что конкретный тип информации лучше сжимается именно этим архиватором, и подсознательно использует его в «подходящих» случаях.
Обычно этой информационной зависимостью можно пренебречь, особенно когда сжимается новая информация, созданная через несколько лет после разработки (раз)архиватора.
Но можно представить и противоположный случай: разархиватор размером несколько петабайт, содержит в себе кучу картинок из Интернета, и сжимаемая картинка вдруг оказалась в базе (раз)архиватора. Есть ли здесь информационная независимость? Очевидно, нет.
Доказательство очень сложно. Но можно представить себе, что мы межгалактически передаём информацию информационно-независимым от нас инопланетянам (например, это первая передача). Тогда нам нужно передать разахиватор и сжатые файлы. Ввиду того, что количество передаваемых сжатых файлов не ограничено, при большом количестве этих файлов размер разархиватора в итоге станет пренебрежимо малым относительно общего количества переданной информации.
Примечание: тут кто-то приводил пример «сжатия» информации путём передачи ссылки на картинку в Интернете. Это невалидный пример, ибо отправитель и получатель не являются информационно-независимыми (в том смысле, что мессенджер, через который отправлена ссылка, не является единственной переданной информацией). Эту ситуацию следует рассматривать скорее так, что третья сторона (Интернет) передаёт информацию двум получателям. Аналогично, если мы с инопланетянами будем наблюдать некий общий объект во Вселенной, и обмениваться информацией, касающейся этого объекта, то «правильную» степень сжатия этой информации посчитать будет очень непросто из-за возникшей информационной зависимости.
оффтоп: жаль, что карма пользователя без статей ограничена. такие люди, как вы, дают надежду на светлое будущее Хабра.
Вы ввели новое понятие. Знал или не знал. Которое дает огромное преимущество в соревновании. То есть всем выгодно доказать что он не знал.
Как будете определять знал или не знал? Темная комната, яркая лампа в глаза, паяльник? Я других способов не знаю. И этот на самом деле не очень надежный.
Про такую вещь, как коллизия хешей, мы скромно умолчим ;)
Размер архива считается как файл архива + размер разархивирова.
Неправда. Для такого архиватора бесконечного размера, архив тоже должен быть бесконечного размера!
Эти ваши 16 байт позволят адресовать всего лишь 2^128 разных вариантов содержимого, а не бесконечность. Соответственно, если в архиваторе нет бесконечных файлов, его размер не будет бесконечным при конечном размере ключа.
Неправда. Для такого архиватора бесконечного размера, архив тоже должен быть бесконечного размера!
Почему?
Эти ваши 16 байт позволят адресовать всего лишь 2^128 разных вариантов содержимого, а не бесконечность. Соответственно, если в архиваторе нет бесконечных файлов, его размер не будет бесконечным при конечном размере ключа.
2^128 это немного больше чем люди способны создать за любое время. Если брать опять любые реальные вещи, а не абстрактный набор байт.
Я могу согласиться что этот архиватор будет эффективно сжимать только любой существующий в мире файл. Вроде нестрашное ограничение?
Если брать опять любые реальные вещи, а не абстрактный набор байт.
Если случайные значения не есть реальная вещь, то что насчёт зашифрованных данных? Весов для нейросетки? Вы, как я понял, предлагаете индексировать вообще всю информацию на свете и использовать пресловутый 128-битный индекс как результат "сжатия"?
Хорошо шифрованные данные неотличимы от случайных. И поэтому несжимаемы. Это никто и не пытается делать. В начале данные сжимают, потом шифруют.
У вас опять абстрактный и неприменимый в реальности пример.
И поэтому несжимаемы.
В каком моменте данные становятся достаточно случайными, чтобы не быть сжатыми вашим архиватором?
Обычный архиватор с условием выброса ошибки при длине результата, большей 16ти байт, попадает под определение вашего архиватора. Все ошибки оправдываются слишком большой случайностью входных данных.
Да в общем как и сейчас. Попробуйте сжать что-то нормально шифрованное. Это приведет к полному провалу. Ничего нового.
Зачем? Любой обычный файл сожмется без проблем. Фильмы, музыка, картинки, тексты, да примерно все что угодно что нужно в реальной жизни. Это заметно лучше любого специализированного типа архиваторов и очень близко к универсальным алгоритмам сжатия. Результат вполне себе достойный.
Это приведет к полному провалу.
Архиваторы обычные можно применять для сжатия всего подряд -- как, например, сжатие страниц в интернете. Обычно сжимает хорошо, но если попало что-то не то и сжатия не вышло -- не проблема, пусть будет так -- файл выйдет байт на десять больше. Ваш архиватор просто откажется сжимать -- см. вторую часть моего прошлого комментария.
Фильмы, музыка, картинки
Есть сжатие с потерями. Без потерь сжимается отвратительно и вообще сжимать так нет необходимости.
примерно все что угодно что нужно в реальной жизни
было бы неплохо пожать веса к сетке, знаете ли
На мои вопросы вы не ответили -- критерии случайности данных и про равенство архиватора "с вылетом ошибки" вашему.
Ваш архиватор просто откажется сжимать -- см. вторую часть моего прошлого комментария.
Написать ифчик который выдаст тот же файл + заголовок совсем несложно. Результат будет сравним с любым текущим существующим архиватором. Почему вы считаете это проблемой?
Есть сжатие с потерями. Без потерь сжимается отвратительно и вообще сжимать так нет необходимости.
С чего бы это? С бесконечным размеров разархиватора я готов сжимать все фильмы без потерь до нескольких байт. Вообще не вижу проблем. Это заметно лучше любого текущего алгоритма сжатия видео.
На мои вопросы вы не ответили -- критерии случайности данных и про равенство архиватора "с вылетом ошибки" вашему.
А оно вам надо? Зайдите лучше с другой стороны. Можно сжать до пару байт любой существующий в мире файл. В конце концов что-то новое появляется не так часто и можно просто выпустить обновление моего архиватора чтобы он это поддержал.
Почему вы считаете это проблемой?
Мой "вариант" и есть исключение таких случаев ради умещения в 16 байт.
С бесконечным размеров разархиватора я готов сжимать все фильмы без потерь до нескольких байт.
Можно сжать до пару байт любой существующий в мире файл.
Как вы будете сжимать файл, не находящийся в вашей базе?
Ваш бесконечного размера архиватор включает же сам себя? Сжимаем его самого -- получаем число икс. Сжимаем его самого кроме последнего байта -- число другое. Так как длина бесконечная, мы упрёмся в 2^128 значений.
В конце концов что-то новое появляется не так часто и можно просто выпустить обновление моего архиватора чтобы он это поддержал.
Т.е. предыдущие версии просто не будут разжимать что угодно новое? Отличный выход.
Т.е. предыдущие версии просто не будут разжимать что угодно новое? Отличный выход.
И? К автообновленияем все привыкли. Опять ничего нового.
Как вы будете сжимать файл, не находящийся в вашей базе?
Сжимать легко. Разжимать только обновления распаковщика.
Это опять не является проблемой. Основной трафик это видео. Которого конечное количество. Вчерашнее видео доступное все это приемлемый результат. В конце концов подождать один день и получить все видео сжатое до пары байт. Вместо того чтобы качать эти жутко неэффективные текущие архивы.
Ваш бесконечного размера архиватор включает же сам себя? Сжимаем его самого -- получаем число икс. Сжимаем его самого кроме последнего байта -- число другое. Так как длина бесконечная, мы упрёмся в 2^128 значений.
А зачем? Посмотрите начало ветки. Размер разархиватора люди предлагают не учитывать. Он любой. Просто не паримся.
К автообновленияем все привыкли.
В конце концов подождать один день и получить все видео сжатое до пары байт.
Хороший архиватор -- если скачать весь интернет, то второй раз качать не придётся!! вот это да
Размер разархиватора люди предлагают не учитывать.
...при подсчёте коэффициента сжатия. В цитируемом вами отрывке речь идёт о принципиальной неработоспособности архиватора.
(Весело обсуждать невозможный технически архиватор)
Это неплохой пример краевого случая почему размер архива надо считать вместе с размеров разархиватора. Тогда таких проблем не будет, все решено на уровне правил подсчета и они соответствуют реальному миру.
В обратную сторону краевые случаи обрабатываются по правилам без проблем. С типичным размером cli разархиватора около мегабайта-двух его размер почти не влияет на эффективность сжатия даже одного гигабайта. Оптимизировать и уменьшать его размер дальше нет смысла.
Для сжатия текстов/исходников/html наверное было бы хорошо иметь какой-нибудь словарь на блокчейне на несколько гигабайт.
Выкиньте блочейн (он как обычно любую задачу решает хуже любого другого способа) и получите довольно типичный способ сжатия со словарем. Обычный zstd так умеет. Что-то экспериментальное наверняка и с гигабайтными словарями умеет работать прилично.
Блокчейн удобен, чтобы словарь мог обрастать именно теми данными, которые лучше всего подойдут, чтобы степень сжатия увеличивалась. Proof of Compression. :-)
Зачем? Чем обычная БД не устраивает? Зачем платить кучу бабла и жечь кучу ресурсов? Опенсорс, Гибхаб, математические доказательства, тесты и тому подобные методы стоят на порядки дешевле и работают лучше.
Ну и мелочи вроде А как ошибки исправлять? А как убирать устаревшее? И тому подобное.
И правда, блокчейн это скорее инструмент для работы в условиях недоверенного окружения, а здесь достаточно использовать IPFS для распространения словаря.
Соответственно, а архиве можно хранить IPFS-адрес словаря, а его формат зафиксировать.
Опять какой-то ужас. Выложите его на Гитхабе. Или в Мавене или еще где угодно. Это все будет гораздо удобнее. Если хочется достоверности подпишите файлик кем-то с хорошей репутацией.
Эх, совсем децентрализованные сети не в почёте нынче.
И как через 30 лет распаковывать такой архив, ссылающийся на github? Может, тогда уже на vk?
Архив. Это файл. Сам по себе. Алгоритм zip за 30 лет я думаю люди не утратят. Взял и распаковал. Если оно кому-то нужно, то никуда он не денется. Если нет, то зачем хранить?
Мы же говорим об архиваторе с внешним большим словарём (скажем, порядка нескольких гигабайт). Такой словарь должен быть общедоступен по короткой ссылке, желательно даже без интернета.
При чем тут ссылки? Для работы локально, для наливки в репозитории. Репозиторий в интернете, локально возможна копия репозитория. Вроде типовая схема?
Вероятность что все ссылки в интернете умрут через 30 лет есть, но небольшая. Если это будет массово использоваться, то ссылки не умрут точно. Первопроходцем в таких вопросах быть не советую. Пусть большие ребята идут первыми, им нужнее.
С типовой схемой слишком много боли.
Ну, допустим, Git:
Сервер рано или поздно станет недоступен по заданному адресу.
Где уверенность, что кто-то, у кого права доступа на запись, не навандалит?
Архив создан с конкретной версией словаря. Нужна доступность всех версий, с дедубликацией.
Что, если размеры словарей не по несколько гигабайт, а по несколько десятков гигабайт? Это уже не git, тем более не github, это всякие неудобные надстройки (по сути, ссылка на центральный сервер).
Если это будет массово использоваться, то ссылки не умрут точно.
То есть пользователь архиватора должен уповать на то, что этот архиватор будет использоваться массово, всегда, именно с этим словарём. Или следить, чтобы локально сохранился каждый словарь к каждому созданному архиву.
Первопроходцем в таких вопросах быть не советую.
Использую IPFS не помню сколько, но больше 5 лет. Все описанные проблемы там естественным образом решаются как нельзя лучше.
Пусть большие ребята идут первыми, им нужнее.
Большие ребята к лаконичным децентрализованным технологиям относятся прохладно, используя разве что их элементы, где без этого совсем дорого (например, сети доставки контента, или обновления компьютерных игр через торренты). Почему так, интересный вопрос, однако... нет, им не нужнее.
Объем мавен централа измеряется в петабайтах. Вероятно до 10 дорос уже. Десяток гигабайт обновляемый раз в год это не проблема. Люди уже больше хранят.
То есть пользователь архиватора должен уповать на то, что этот архиватор будет использоваться массово, всегда, именно с этим словарём. Или следить, чтобы локально сохранился каждый словарь к каждому созданному архиву.
Конечно. Если вы хотите надежности, то ждите пока крупный бизнес перейдет на эту технологию. Это тоже не гарантия, но надежность очень приличная будет. Крупный бизнес умеет хранить данные и делать надежные системы.
Или храните все сами. Что разумно. Или надейтесь на мир и ждите пока мир признает эту технологию нужной и полезной и обеспечит хранение всего нужного для ее работы или все сами делайте и надейтесь только на себя.
Использую IPFS не помню сколько, но больше 5 лет. Все описанные проблемы там естественным образом решаются как нельзя лучше.
Она вся из себя это один костыль. Миллион долларов (а меньше нет смысла, ибо зип проще) я бы ей не доверил. Она может потерять ваш файл в любой момент без всяких гарантий.
Большие ребята к лаконичным децентрализованным технологиям относятся прохладно, используя разве что их элементы, где без этого совсем дорого (например, сети доставки контента, или обновления компьютерных игр через торренты). Почему так, интересный вопрос, однако... нет, им не нужнее.
Большие ребята умеют считать деньги. И у них много данных. Прямо очень много. Любая технология которая позволит экономить хотя бы десятки процентов на хранении этих данных (без недостатков стримеров) будет внедрена довольно быстро. Это экономия много миллионов долларов в год.
Раз ничего такого нет, значит таких технологий просто не существует.
Или храните все сами. Что разумно. Или надейтесь на мир и ждите пока мир признает эту технологию нужной и полезной и обеспечит хранение всего нужного для ее работы или все сами делайте и надейтесь только на себя.
Не "или", а "и". С IPFS я храню всё нужное у себя, с возможностью взять и у других, если что.
Она вся из себя это один костыль. Миллион долларов (а меньше нет смысла, ибо зип проще) я бы ей не доверил. Она может потерять ваш файл в любой момент без всяких гарантий.
Версия 0.x до сих пор, так что как бы может.
Но я бы скорее доверил миллион долларов IPFS, чем любому из централизованных облачных провайдеров, тем более в наше то время.
Большие ребята умеют считать деньги. И у них много данных. Прямо очень много. Любая технология которая позволит экономить хотя бы десятки процентов на хранении этих данных (без недостатков стримеров) будет внедрена довольно быстро. Это экономия много миллионов долларов в год.
Раз ничего такого нет, значит таких технологий просто не существует.
Когда дело касается тактических задач, они внедряют необходимые технологии, и экономят десятки процентов. Но это обычно закрытые технологии, внутри ихних экосистем.
На стратегических (может, не самая удачная терминология), выигрыш может быть и в разы и на порядки. Но не хватает понимания, а как его считать.
Вспоминается статья KPHP спустя 2 года от разработчиков VK, очень показательная.
К тому же, у больших дядек просто не стоит такой задачи, чтобы все интересующие тебя данные остались доступны сколь угодно долго.
Ими удалось откусить 10–15% времени ответов API (которые через полгода обратно съелись продуктовым кодом, как оно всегда и бывает).
Из вышеупомянутой статьи.
И даже если программа действительно настолько массовая, что непотопляемая, где-то на уровне Windows, то заставлять людей перезаливать словари и заниматься перепостом новых ссылок взамен старых ушедших... Мне эта старинная забава уже поднадоела.
Тогда оно будет просто работать. Мавен централ. Просто работает. Массовая технология хранения бинарей уже дано сделана.
Загруженный в Maven Central файл будет всегда доступен? И даже через 30+ лет? И даже если загрузивший будет из страны, которая под санкциями? И даже если найдут в файле какую-нибудь последовательность, вызывающую чувства? И даже если загрузивший сам решит файл удалить? И даже когда сам Maven Central пойдёт вслед за JCenter?
Да, да и да. Это несущая технология для заметной части IT. На него такие миллиарды завязаны что все что вы перечилили пыль под ногами не стоящая внимания.
Удалить нельзя, прям вообще никак. В том числе автор не может. Исключения могут быть для удаления сознательного вредительства. Не помню таких, но допускаю.
Это неплохой пример краевого случая почему
...нужно пользоваться нормальными архиваторами, алгоритмическими, а не пытающимися утянуть частовстречающиеся куски файлов.
С типичным размером cli разархиватора около мегабайта-двух его размер почти не влияет на эффективность сжатия даже одного гигабайта.
Обратная сторона: сжимаем миллион нулевых байт в, например, тридцать байт -- коэффициент сжатия меньше одного; сжимаем терабайт -- ситуация друга, хотя сжатия абсолютно подобны друг другу.
...нужно пользоваться нормальными архиваторами, алгоритмическими, а не пытающимися утянуть частовстречающиеся куски файлов.
А почему? Сделать словарь из часто встречающихся кусков и пользоваться им это разумная идея. Она реализована на практике и неплохо работает. Не всегда, но применимость есть. Размер архива уменьшается.
Дальше эту идею можно развить в ширь и хранить все файлы вообще. Тогда размер архива уменьшится до единиц байт.
Обратная сторона: сжимаем миллион нулевых байт в, например, тридцать байт -- коэффициент сжатия меньше одного; сжимаем терабайт -- ситуация друга, хотя сжатия абсолютно подобны друг другу.
Конечно. Поэтому тесты коэффициента на таких маленьких файлах стараются не проводить. Типичный объем данных для тестирования алгоритмов сжатия сейчас это около гигабайта.
Сделать словарь из часто встречающихся кусков и пользоваться им это разумная идея.
Только если что для каждого отдельного случая, в сам архиватор вписывать словарь бесполезно, достаточно длинных и встречающихся везде кусков нет.
Дальше эту идею можно развить в ширь и хранить все файлы вообще. Тогда размер архива уменьшится до единиц байт.
Даже архивом назвать сложно -- сжатия-то нет. Ntfs/ext4 мои тоже архивы тогда, только вместо двухбайтовых значений -- пути и inode'ы.
Поэтому тесты коэффициента на таких маленьких файлах стараются не проводить.
Мой абзац был про то, что даже гениальный архиватор, сжимающий мегабайт рандома в байт по вашему коэффициенту выдающимся не будет.
Размер архива считается как файл архива + размер разархивирова.
С чего бы? Бывают схемы сжатия, где например словарь хранится отдельно от архива, или даже схема данных хранится отдельно от данных, что тоже экономит место.
В теории-то да, можно представить "распаковщик бесконечного размера", но на практике это невозможно, а размер архиватора не всегда важен. Когда данные куда-то передаются, архиватор не всегда передаётся - он может быть передан 1 раз заранее.
Иначе непонятно как считать. Вот есть у вас разархиватор размером в терабайт. Он эффективнее всех существующих процентов на 50. Он достоин считаться лучшим и рекомендованным к использованию?
Для типичных случаев где cli версия весит килобайты или единицы мегабайт это не критично. Это важно именно для краевых случаев.
ко мне приходил человек из авиации - он был бы согласен возить разархиватор и в 10 терабайт, если бы только
1) ролики с ютуба\тиктока влезали в радиоканал в самолете (т.е. чтобы каждый пассажир мог смотреть свой хотя бы в 420р)
2) не сильно долго бы распаковывал (ну там секунды)
Вот есть у вас разархиватор размером в терабайт. Он эффективнее всех
существующих процентов на 50. Он достоин считаться лучшим и
рекомендованным к использованию?
При определённых условиях (если работает достаточно быстро и экономит, например, от пары терабайт) - вполне.
Курс компьютерной графики в том или ином виде присутствует в образовательной программе любой ИТ-специальности
Нет
В числе прочего там обязательно проходят форматы графических файлов и затрагивают алгоритмы сжатия изображений
Нет
Скажу больше - большинство того что на Хабре обсуждается на уровне "библий для ИТ" или "это должен знать каждый" - в образовательных программах в принципе отсутствует. Можно сколько угодно рассуждать о качестве такого образования, но факт остается фактом.
1) определить пол (1 бит)
3) определить возраст (1 байт должно хватить)
4) определить положение (фас/профиль/etc)
5) определить цвет/разрез/etc глаз
6) определить форму губ
7) определить фокусное расстояние
8) определить положение и источник освещения
и т.д.
То есть иметь небольшой набор чисто числовых (а не текстовых!) характеристик, гарантирующих узнавание закодированного человека вне зависимости от того, участвовал он в обучающей выборке для нейросети или нет.
Идея интересная, но дьявол кроется в деталях. На кодирование всех веснушек уйдет много места, либо декодер восстановит не ту фотографию.
Вы придумали современную версию фоторобота для полиции, там где подбородки меняются, брови, глаза.
Не, слишком примитивно. Сейчас можно пропустить через 'автоэнкодер'. Он выявит значимые характеристики. Из них сделать вектор, который потом можно подавать на половину автоэнкодера для декодирования. И так уже пробуют. Тут нужно найти баланс. Целиком изображение если пропустить, то он его "обобщит" до вектора из которого только мыльные пузыри получить назад можно. А вот если таким макаром кодировать результат, который выдает сверточная сеть, то м б можно что то пытаться получить вменяемое. Тут ещё было бы интересно представить изображение в виде основного вектора и добавок к нему. Основные вектора уже могут быть зашиты в декодере. (Например набор характерных лиц) А набор "добавок" - это само кодированные изображение. Его подаем на вход декодера и получаем первоначальный вариант с некоторыми искажениями. Чем больше векторов вшито в декодер и чем жирнее добавка тем лучше качество.
Именно так и выглядели паспорта до того, как фотография стала общедоступной:
Когда очень нужно нагнать трафика в корпоративный блог, но писать совсем уж нечего.
субъективизм... ничто человеческое AI не чуждо)
Такую идею высказывали не раз и не два. Даже помню кто-то видеокодек хотел так сделать. Показать нейросети фильм, а потом попросить её "вспомнить" его. :)
Если отжать магию нейросетей, то то, что вы предлагаете, лишь обычное сжатие со словарём, только со статическим, разделяемым между всеми участниками. Для музыки аналогичный метод вполне себе существовал в виде midi. Надо садиться и считать какой размер базы шаблонов будет достаточен для значительного обгона степени сжатия по сравнению с другими методами. Возможно её размер будет порядка сотни гигабайт, что делало бы её непрактичной для 90-х, но подходящей для современных компьютеров. (Но не для мобильных устройств.) А может размер окажется порядка петабайт или даже экзабайт и идея всё ещё будет непрактичной.
Некоторые специалисты называют это "словесный портрет".
Спасибо, автор, повеселил ))
Все люди одинаковые со степенью достоверности 99,9%, судя по нашему геному.
Господа, VQ-VAE нас спасет. Использование латентного пространства очень хорошо подходит для создания качественных энкодеров-декодеров. Соответственно, их суть отлично ложится на теорию и практику сжатия изображений. Очень часто - практически без потерь там, где имеющиеся алгоритмы ухудшают картинку.
«стена, покрытая лучами заката» — это пять.
Я специалист по обработке изображений, и я очень недоволен, когда при сжатии изображения «с потерями» изображение становится хуже. Почему «теряется» всё самое хорошее, а плохое остаётся, да ещё и добавляются артефакты? Пусть теряются дефекты!
Правильный алгоритм сжатия с потерями в случае сильного сжатия должен работать так:
Шума на сжатой фотографии нет, потому как для хранения всех «шуминок» в файле не осталось места. Вместо этого идеально чистое и чёткое изображение.
Хроматических аберраций тоже нет — не сохранились.
Разрешение бесконечное. Зачем нужны пиксели? Достаточно соотношения сторон. Разрешение — это лишнее число; его можно не сохранять.
Если на фотографии запечатлён человек, то его кожа будет без дефектов и морщин — ведь нужно много лишних байт, чтобы записать координаты каждой морщины, прыща, пятна и шрама. Аналогично, если запечатлён какой-то предмет (например, автомобиль), то он тоже будет без дефектов (без царапин, чистый) — на хранение дефектов не хватило места.
Повреждение файла обнаружить невозможно. Ведь сама возможность обнаружения повреждений означает, что кодирование избыточно. Если мы выжимаем каждый бит, то любая комбинация байтов должна быть валидным изображением. Изменился какой-нибудь бит в файле — и, например, человек на фотографии из мужчины превратился в женщину. В идеале, увеличивать степень сжатия можно, просто отбрасывая байты с конца файла.
Если изображение сгенерировано алгоритмически, то после сжатия без потерь «правильным» алгоритмом размер изображения не должен превышать размер исходного кода (или исполняемого) файла, который это изображение породил. Например, если какая-нибудь демка (EXE-файл на 64 килобайта) генерирует пятиминутное видео, то такое видео должно сжаться вообще без потерь в 64 килобайта (или меньше).
И так далее. В будущем, когда такие алгоритмы будут разработаны, будет так:
—Я тебе послал фотку моей девушки. Как тебе?
—Что-то я не пойму, она действительно такая красивая, или это просто Телеграм так сильно фотку зашакалил?
Или:
—Я тебе послал фотку моей девушки. Как тебе?
—Там какой-то мужик-алкаш на фотографии.
—Странно. Наверное, файл повредился при передаче.
Не знаю, зачем нужно будет аж так экономить место и трафик в эпоху сильного ИИ, но определённая красота в этом есть.
В идеале, увеличивать степень сжатия можно, просто отбрасывая байты с конца файла.
Прогрессивному сжатию уже больше 10 лет https://habr.com/ru/post/165645/
это получается векторная графика
За фантазию - 5, за попытку назвать это методом сжатия - кол.
А уместно ли вообще говорить о сжатии в данном случае, когда от исходного файла не остается ничего? Тут скорее копирование. Вроде ерунда, но если подумать про авторские права и уникальность, то останутся ли они?
Вот статейка получше. В ней буквально рассматривается энкодер для сжатия через stable diffusion: https://habr.com/ru/post/691192/
Никаких гипотез, только реальное применение. Никаких бредней про "уложиться в твиттерский пост", а адекватное применение новой технологии на практике.
Революционный метод сжатия изображений