LINUX.ORG.RU

Новый формат изображений быстрее PNG в десятки раз

 , , , qoi

Новый формат изображений быстрее PNG в десятки раз

6

3

Доминик Саблевски представил новый и невероятно простой в реализации формат изображений QOI (Quite OK Image). По представленным тестам, при сжатии изображений QOI производительнее PNG в 20–30 раз, а при распаковке — в 3–4 раза.

Доминик признаётся, что не является экспертом в области сжатия изображений. Идея создать новый простой и эффективный формат изображений пришла к нему во времена работы с MPEG-1. Его целью была скорость и простота.

Файлы QOI больше по размеру, чем PNG на 10–50 % в зависимости от картинки, поэтому QOI стоит применять, когда необходима скорость.

Исходный код на C, состоящий из одного универсального файла, доступен на GitHub.

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

Также доступны реализации на Zig, Rust, Go, TypeScript, Python, C#. Поддержка QOI добавлена в библиотеку SAIL.

Для пользователей Arch Linux в AUR доступен пакет qoi-git.

>>> Замеры скорости и размеров изображений

>>> Подробности

★★★

Проверено: Shaman007 ()
Последнее исправление: sudopacman (всего исправлений: 2)

Ответ на: комментарий от AVL

Так это вопрос к автору новости. Почему у него там акцент на PNG. Я тоже не понял.

anonymous
()

JPEG XL уже на подходе, умеющий в lossless и с обратной совместимостью со старым JPEG. А этот мусорный формат не нужен.

anonymous
()
Ответ на: комментарий от anonymous

JPEG XL

Отличное название.

ps. Они что, серьезно?

anonymous
()
Ответ на: комментарий от anonymous

У deflate скорость не так сильно зависит от степени сжатия. Экономия - проценты.

former_anonymous ★★★
() автор топика

Название уже нравится. А вот накой qoi оно нужно, пока не понятно.

ashot ★★★★
()
Ответ на: комментарий от MKuznetsov

Текстурки в гпу на лету распаковываются быстрее, чем читались бы из видеопамяти в raw.

anonymous
()
Ответ на: комментарий от upcFrost

Только тут спорный прирост с учетом ухудшения сжатия на 10-50%. Какой профит получится на бэке от этого формата? Ресайзилки картинок на вебне прикрыты каким-нибудь кэшированием. Отресайзеные картинки надо где-то хранить и потом отдавать, а этот формат увеличит утилизацию канала и время полной загрузки страницы/экрана приложения. Выглядит как какая-то нишевая штука

cobold ★★★★★
()
Ответ на: комментарий от cobold

Только тут спорный прирост с учетом ухудшения сжатия на 10-50%. Какой профит получится на бэке от этого формата? 

Обычно машинное время прилично дороже хранилища

upcFrost ★★★★★
()
Ответ на: комментарий от Lrrr

Сейчас пилят JPEG XL, который и меньше, и быстрее.

именно поэтому его назвали eXtra Large? гениальный маркетинг!

crypt ★★★★★
()

От скорости сжатия толк может быть только в VNC каком-нибудь, имхо. Но там я так понимаю и так уже что-то похожее - ZRLE, или что там…

Ну или в каких-то ещё более специфичных применениях, типа ембеддед там…

А как эксперимент, конечно, интересно - что такой простой алгоритм так хорошо жмёт)

vitalif ★★★★★
()
Последнее исправление: vitalif (всего исправлений: 1)
Ответ на: комментарий от vitalif

Ну если идея в том что контент по сути не кэшируемый, персонально под клиента генерится, то наверное допустимый трейдофф. Типа картинки с графиками из того же мониторинга, а сырые данные мы не хотим на клиент отдавать

cobold ★★★★★
()

Отлично. Рад за человека. Но воспримет ли его индустрия? Ведь со стороны, выскочка, а лезет им стул пилить.

R_He_Po6oT ★★★★
()
Ответ на: комментарий от upcFrost

Напоминает дрочерство вимеров на «скорость»

Эт ты зря. Для серверов прирост скорости обработки даже на 5% это уже повод подумать.

«Сервера работающие на vim» — теперь это тред про кислотные трипы.

slackwarrior ★★★★★
()
Ответ на: комментарий от Lrrr

Вот нифига, обработка картинок на сервере это боль именно из-за сжатия. А на десктопе зависит время прорисовки всяких иконок.

InterVi ★★★★
()
Ответ на: комментарий от fornlr

Я пользуюсь geeqie именно из-зе скорости. Попробуй.

hateWin ★☆
()
Ответ на: комментарий от crypt

уже на уровне звукового ряда чувствуется простота

Кой!

hobbit ★★★★★
()
Ответ на: комментарий от zgen

Хех, когда включается эта эвристика он, наоборот, перестаёт «тормозить». И начинает «шакалить».

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)

какой-то странный бенчмарк, для других форматов выполняется просто загрузка файла в память, а для qoi сразу какую-то функцию вызывает

void *pixels = (void *)stbi_load(path, &w, &h, NULL, 4);
	void *encoded_png = fload(path, &encoded_png_size);
	void *encoded_qoi = qoi_encode(pixels, &(qoi_desc){
			.width = w,
			.height = h, 
			.channels = 4,
			.colorspace = QOI_SRGB
		}, &encoded_qoi_size);

xmikex ★★★★
()

Идея создать новый простой и эффективный формат изображений пришла к нему во времена работы с MPEG-1. Его целью была скорость и простота.

Мужик сказал - мужик сделал! Вот это я понимаю, четко.

Только что-то слабо верится, что все разработчики форматов изображений такие тупые, а теперь нашелся один умный, который еще и «не является экспертом». Кто-нибудь может объяснить, в чем подвох?

anonymous
()

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

anonymous
()
Ответ на: комментарий от t184256

Зачем вообще мышь при наборе текста? Я вот это сообщение набрал и мышь вообще не трогал.

anonymous
()

QOI

Напуркуа такие названия тупые придумывать. Программист что ле? Хотя хуже редхатовской шоблы с их Копром и Пидорами всё равно уже нет.

d_a ★★★★★
()

Это же lz4. Он всегда быстрее был. Но называть это новым форматом грех какой то

anonymous
()
Ответ на: комментарий от anonymous

В том, что для хранения без потерь уже есть PNG, который покрывает практически всё, если хочется экономить процессорное время - compression-level compression-filter compression-strategy и color-type в помощь. Но спецификация и реализация QOI очень красивая и лаконичная.

anonymous
()

Доминик признаётся, что не является экспертом в области сжатия изображений.

Дальше можно не читать…

P.S. Аналогия: я не эксперт по коньякам многолетней выдержки, но могу предлОжить «быстрый коньяк»: «спирт + вода + пищевой краситель» :)

quickquest ★★★★★
()
Ответ на: комментарий от anonymous

Только что-то слабо верится, что все разработчики форматов изображений такие тупые, а теперь нашелся один умный, который еще и «не является экспертом». Кто-нибудь может объяснить, в чем подвох?

Никакого подвоха нет. Никто не запрещает делать PET проекты и делиться своими успехами, пусть даже и скромными.

DarkAmateur ★★★
()
Ответ на: комментарий от anonymous

Как корабль назовёшь, так он и поплывёт (c) народная мудрость.

d_a ★★★★★
()
Ответ на: комментарий от AVL

Да, у PNG сжатие без потерь. И чем выше степень, тем оно дольше проходит.

MageasteR ★★★★★
()

qoi_write(const char *filename

Приличные библиотеки принимают FILE*, а не пытаются открывать сами.

anonymous
()
Ответ на: комментарий от LamerOk

То ли дело «жыпег» или «пыэнгы» - так и просятся на язык.

Первое давно считается дефолтом, и не называется. Второе называется «пнг».

anonymous
()
Ответ на: комментарий от izzholtik

почему остальные файлы он просто загружает? логично было бы, чтобы он и из файла так же загружал qoi формат.

xmikex ★★★★
()

QOI стоит применять, когда необходима скорость.

Китайцы заочно благодарят поди.

anonymous
()
Ответ на: комментарий от anonymous

Второе называется «пнг».

Не расслышал. Понг? Или Пунг?

anonymous
()
Ответ на: комментарий от anonymous

Тогда на винде перестанет работать, если qoi будет скомпилировано статически со стандартной библиотекой, а конечная программа - динамически (или наоборот), т.к. у каждого экземпляра стандартной либы свой набор файловых дескрипторов.

gag ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.