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

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

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

https://i.imgflip.com/5lvfw5.jpg

Они же наяривают на скорость, могли сжимать не на максимум.

JPEG XL

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

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

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

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

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

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

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

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

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

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

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

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

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

Надо было jpeg plus или jpeg max называть, по модному. Нуууу тупыыые

Но оно тратится на кодирование один раз, а трафик - постоянно

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

браузера. Где без мышки все равно никак.

Lynx.

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

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

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

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

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

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

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

Кой!

кои

В VNC, например, JPEGами можно фигачить как из пулемёта, а это куда?

Тото он так тормозит

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

какой-то странный бенчмарк, для других форматов выполняется просто загрузка файла в память, а для 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);

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

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

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

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

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

QOI

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

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

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

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

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

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

Кто о чём, а пятизвёздочный о чужих (*) и 💩, мдя. У кого о чём болит…

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

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

Быстрее только на сжатие, а по всем другим пунктам хуже. Язабан, конечно.

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

посмотри сам код qoibench, он какой-то странный.

коммент видел, но смотреть откровенно лень, и так видно, что ересь

что ересь

Тогда нужно разъяснение по кол-ву форков и ватчеров. МММ?

anonymous ★★★★★

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

qoi_write(const char *filename

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

Запили багрепорт, зачем это на Лоре писать?

имхо, это ок, он просто кодирует битмап в целевой формат перед бенчмарком декода. Но это не точно.

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

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

Кои-8 тоже не особо

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

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

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

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

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

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