Комментарии 14
RLE на стероидах. Для нарисованных в пеинте графиков подойдёт, для остального не очень.
Не сказал бы, в бенчмарках есть и натурные фотографии. Потом разработчик сам из геймдева, и там полно текстур которые должны неплохо жаться и скорость там важна.
Замечу что это всё на CPU, на GPU это может быть ещё быстрее.
Замечу что это всё на CPU, на GPU это может быть ещё быстрее.
На GPU это в принципе не будет работать — там что у кодера, что у декодера зависимость по данным от предыдущего пикселя.
Какой-то выигрыш от параллелизма тут в теории может быть, только если наперёд считать хэши цветов в кодере и парсить чанки в декодере, но это достаточно простые операции, так что я не уверен, что это даст сколько-нибудь существенное ускорение. И точно не на GPU — максимум SIMD.
В Геймдеве используют нативные форматы, которые прям сразу мапятся на память и апартно расжимаются.
Взял наугад фотографию, картинку и сложную текстуру. QOI проигрывает на всех трех по размеру от 20 до 40%. Очень слабое сжатие. Скорость не так важна как обьем.
А с чем сравнивали?
Скорость не так важна как обьем.
Целиком и полностью зависит от задачи. Этот проект же как раз и возник из потребности в быстром кодировании/декодировании.
Сравнивал с png. В настоящее время медиа контент жирнеет, скорость распаковки и так растёт за счёт модификаций алгоритмов, модернизации железа. Но это моё мнение.
Сравнивал с png.
Зависит от кодера и параметров ещё.
По бенчмаркам с дефолтными параметрами libpng выглядит больше похоже на 10-20% разницы (разве что от часто меняющегося альфа-канала QOI судя по всему плохеет, и там может быть и до двукратного различия).
В настоящее время медиа контент жирнеет, скорость распаковки и так растёт за счёт модификаций алгоритмов, модернизации железа.
Для веба или личных коллекций мемов никто (вроде) и не предлагает QOI использовать, а если у вас на сервере большую базу картинок надо регулярно перемалывать какой-то обработкой, то дисковое пространство легко может оказаться дешевле, чем процессорное время.
Использовал настройки по умолчанию.
Но если смотреть с такой позиции (дисковое пространство неограничено) проще исползовать raw. Хотя ваш случай очень эксцентричный. Не могу представить практический пример.
У меня, например, личный фотоархив перевалил за 10гб (и это в формате jpeg).
Коллекция текстур и прочий графический контент занимает 1tb. Там и jpg, png, gif и аппаратные форматы и кастомные тоже.
Вот мне бы их перепаковать в компактный формат, эхх...
Хотя ваш случай очень эксцентричный. Не могу представить практический пример.
В общем-то любой облачный сервис, связанный с обработкой изображений.
А дальше вопрос в том, насколько много изображений надо хранить и насколько часто их читать и писать. С некоторого порога становится выгодно подтюнить кодер или перейти на условный QOI, с совсем другого — на raw (там надо не только гораздо больше диска, но он ещё и должен быть намного быстрее, чтобы в него не упираться, и это очень сильно применимость raw в данном сценарии ограничивает).
У меня, например, личный фотоархив… Коллекция текстур и прочий графический контент
А вот вам, очевидно, QOI нафиг не сдался :)
Но тогда минуточку. Игроделам не надо, разработчикам не надо, дизайнерам не надо, обычным пользователям не надо, соцсетям и их хомячкам не надо, image хостингам и xxx площадкам не надо. Остались мифический сервера с непонятными пост обработками изображений.
Приведите пожалуйста конкретный практический пример.
Идея конечно интересная, но на практике - в 99% случаев бесполезна. Если речь идёт о изображениях без потерь, то главное - занимаемое место на диске. Объём передаваемого трафика - тоже очень важен. Формат подойдёт только для генерации изображений "на лету" с возможностью сохранения, на ум приходит только фотоаппарат в режме, когда он делает много фотографий за короткие интервалы времени, но тут уже вопрос, насколько эффективно он сжимает raw.
Опубликованы спецификации графического формата QOI, который в 20–50 раз быстрее PNG