Представлен новый легковесный формат сжатия изображений без потерь - QOI (Quite OK Image), позволяющий очень быстро сжимать изображения в цветовых пространствах RGB и RGBA. При сравнении производительности с форматом PNG однопоточная эталонная реализация формата QOI на языке Си, не использующая SIMD-инструкции и ассемблерные оптимизации, по скорости кодирования в 20-50 раз превосходит библиотеки libpng и stb_image, а по скорости декодирования в 3-4 раза. По эффективности сжатия QOI в большинстве тестов близок к libpng (в каких-то тестах немного опережает, а в каких-то проигрывает), но в целом заметно опережает stb_image (выигрыш вплоть до 20%)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56229
и как его установить?
В Debian 11:apt install libstb-dev
gcc -I /usr/include/stb -o qoiconv qoiconv.c
Нарот ! Лену в студию ! Тут говорят лучше там говорят хуже. Пусть она все рассудит.
> и как его установить?И зачем? 🤔
Когда нужно быстро сохранять кучу картинок в "игрушечных" программах без возни с библиотеками -- это отличнейшее решение. Простой формат файла, простой декодер-энкодер.
Сейчас есть lodepng, конечно, но он не быстрый. И pgm/ppm, но они без сжатия. Тут всё сочеталось бы идеально, если бы формат можно было открыть в чём угодно. Как появится поддержка в условных Qt с IrfanView -- вообще прекрасная замена будет
Расширение файла будет QOI? Сложно произносить будет.
Къюоай.
Я подозреваю, что это читается как 恋.
> Я подозреваю, что это читается как 恋.иероглиф 恋 читается как liàn (произносится четвёртым тоном).
значение: "любить", "ощущать привязанность", "страстно желать"; а также "жидкий" в значении "недостаточной концентрации".
Сорян я только на японском разговариваю.
Ничего себе, я резко стал понимать японский!
> Ничего себе, я резко стал понимать японский!Круто тебе, мне пришлось много лет учить.
Это просто, достаточно простого советского...
То что ты смотришь онимэ для дебилов не значит что ты учишь японский.
Вот я смотрю онимэ для умных. Наруто, например.
Это какое-то извращение
Я вижу что ты несколько неадекватен, но я могу дать серьёзный ответ тем, кто может быть заинтересован. Нет, смотря мультики языку не научишься, только подберёшь странную лексику в жизни крайне неуместную. Но при этом достаточно быстро можно начинать смотреть детские мультики без перевода, это несколько помогает практике. Содержимое конечно там ощутимо попроще. Если при этом знать азбуки, этого может быть практически достаточно для полноценного взаимодействия с носителями.
> Я подозреваю, что это читается как 恋.鯉? 濃い... 来い!
Среди айтишников много виабу, вероятно это тот кейс.
Я абсолютно равнодушен ко всему мангоанимешному. Я просто случайно понимаю японский.
Тащем-то я имел в виду автора, а ты просто поехавший, наверное. Насчёт мангоанимешного это зря, те же комиксы с фуриганой это нормальная такая практика.
> а ты просто поехавший, наверное.Несомненно. Кстати, многие японцы думают так же -- не-японец не может понимать японский, это абсолютно невозможно.
Когда уже будет «ко-ко»?
не разговаривай, когда ешь
>Къюоай.Обнаружен англопоклонник.
Срочная эвакуация из треда!
тогда уж Кьюоуай.
А чего не Киуёуоайяаёуо?
Подсказка тебе: как произносится NASA?
> Къюоай.Ловите американофила!
Кой, просто кой.
Предлагаю произносить на французский манер - "куа".
- Же не ма шпа сис жур
- Иди-ка ты на куа
>Предлагаю произносить на французский манер - "куа".Поддерживаю. Любителей придираться к названиям вообще надо отправить отведать монгольской кухни: есть там замечательное блюдо, мясное ассорти, с шикарным названием "хyiцаа". Сия шутка есть древнючий боян монголоведов, если что.
Да вообще, лубителей называть латинские буквы английскими, и на том основании давать им неродные названия, надо пороть. А то достали со своими «си» вместо «цэ», и считающими свою т.з. нормой.
Ничего что предшественником Си был bcpl, буква означает следующую попытку делать то же самое, и это акроним? Ни разу не латинский.
В русском языке нет слова "акроним", это калька. Есть слова "аббревиатура" и "сокращение".
Акроним это частный случай аббревиатуры (сокращения).
> Да вообще, лубителей называть латинские буквы английскими, и на том основании давать
> им неродные названия, надо пороть.Надо. Начать с Розы, которая оказалась Пока.
> А то достали со своими «си»
> вместо «цэ», и считающими свою т.з. нормой.Потерявши голову, по волосам не плачут:
Заглавие на русском языке: Информационная технология. Языки программирования. Си
Стандарт ISO/IEC 9899:2018 входит в рубрики классификатора:
ОКС \ ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ \ Языки, используемые в информационных технологиях \
>Языки программированияПри чём здесь они? Я про букву.
>>Языки программирования
> При чём здесь они? Я про букву.Не припоминаю, что бы _здесь_ кто-то писал "Си" не имея ввиду ЯП.
Пример я выбрал неудачный, хотя когда выбирал, исходил из наибольшей непохожести названий букв в латыни и английской недописьменности.
I и Y более непохоже. Правильно: Микрософт, Питон. А тут пишут про какие-то Майки и Пайтон.
Да вообще вся английская недоазбука кривая. Для меня самым первым пришло в голову именно то сравнение, которое я указал. А уж как некоторые европейские языки поиздевались над буквой «ёт», так вообще любо-дорого взглянуть.
Забавно. То есть английский, это типа паданкофского слэнга латыни, и похрену на сотни лет истории, а американский, это еще одна итерация, и тот факт, что русский язык 100 лет назад был другим, а скажем лет 300 назад, уже можно было и не понять о чем речь,..ну с таким подходом то да, языки же моисею господь передал на горе синай, вместе с аудиокассетами с правильной фонетикой, только он их гдето потерял, а ты походу нашел)
> Забавно. То есть английский, это типа паданкофского слэнга латыниКорректное название феномена - Great Vowel Shift
https://ru.wikipedia.org/wiki/Великий_сдвиг_гласных
Долбанутый ответ, как и автор, наверное.Кириллица, как азбука — самая простая, наверное. без всяких закрытых слогов. Читается если и не одинаково, то похоже. В отличие от европейских языков есть буквы «Ч» и «Ш» и нет порнографии с диграфами, триграфами и тетраграфами. Нет порнографии с открытыми и закрытыми словами, как в англонедоорфографии. Все слова русского языка читаются по одним правилам. Нет такого, чтобы слово заимствовалось и читалось по правилам иного языка (привет франкизмам в английском).
>То есть английский, это типа паданкофского слэнга латыни
Откуда это можно было вычитать в моём комментарии? Воистину: сам придумал, сам опроверг. Мамкин победитель.
> Долбанутый ответ, как и автор, наверное.
> Кириллица, как азбука — самая простая, наверное. без всяких закрытых слогов. Читается
> если и не одинаково, то похоже. В отличие от европейских языков
> есть буквы «Ч» и «Ш» и нет порнографии с диграфами, триграфами
> и тетраграфами. Нет порнографииУгу-угу, просто игнорируем "сч", читаемое как щ в "счастье", "насчет", "чт/чн" - читаемое как "шт/шн" (что-то, скучно), "сш/cж" читаемые как длинный ш/ж (сшить/попозже), как и т(ь)ся, читаемое как "ца" (учиться, заниматься), "выкидываение" согласных в "грустно, праздник, солнце", букву "г" читаемую между гласных как "в" (сегодня/его/третьего, но: погода/строго).
Ну и всякие "е/я" редуцируемые в и (лето, весна), "е" читаемое как "Ы" после Ж/Ш/Ц, безударная э,
и прочие "мелкие нюансы" чтения, типа "о" читаем как "а" (отец), "г" как "к" (друг), "ж" как "ш" (ёж), "е" как "и" , "д" как "т" (сад), з/c и б/п (хлеб, арбуз).
А так да, все просто и интуитивно понятно - вон, даже школьники осиливают ...
> Предлагаю произносить на французский манер - "куа".И три раза присесть, что бы браузеры начали показывать.
Кои, как рыба.
Кой. Только накой тебе?
На французский манер: Куа? ;))
на кой он сдался?
Опять не на расте... Небезопасный хлам!
Дополнительно энтузиастами подготовлены реализации кодировщиков и декодировщиков на языках Go, Zig и Rust.
Опять Хаскель забыли.
Zig Rust!!
В твите по ссылки из стать четыре реализации на расте
Чукча не читатель. Откуда вы такие берётесь? Это риторический вопрос был,если что. Я знаю откуда.Цитата: "Дополнительно энтузиастами подготовлены реализации кодировщиков и декодировщиков на языках Go, Zig и Rust".
То есть как это "Производительность QOI не зависит от размера и характера кодируемого изображения (O(1))"?
Если алгоритм проходит по каждому пикселю один раз, то тогда алгоритмическая сложность равна O(n), где n=количество пикселей.
Автор новости не внимателен. Там по ссылке в заголовке O(n)
Бог тролинга ! Преклоняюсь перед тобой !
Производительность - производная. Отношение количества операций к количеству пикселей к не зависит от размера и характера изображения.
Исходная статья называется "Lossless Image Compression in O(n) Time!". Полагаете, там ошибка?
> Исходная статья называется "Lossless Image Compression in O(n) Time!". Полагаете, там ошибка?Полагаю что ошибка у вас в рассуждениях, так как время выполнения != производительность.
Не могли бы вы предоставить какое-то общеупотребительное определение слову "производительность" в контексте оценки эффективности алгоритмов?Допускаю, в вашем личном лексиконе такое неравенство действительно существует. Но вот обычно принято эти два понятия приравнивать (ещё раз подчеркну, что речь идёт об оценке эффективности алгоритмов и только о ней). Такое имеет место быть и на Википедии, и в той литературе, которая попадалась мне на эту тему, и даже в лекциях некоторых профессоров MIT. Поэтому ссылки на сколь-либо авторитетные источники с вашей стороны были бы как нельзя кстати.
В противном случае возникает впечатление, что вы изобретаете новую терминологию просто только для того, чтобы оправдать свою позицию в данной дискуссии.
> Не могли бы вы предоставить какое-то общеупотребительное определение слову "производительность" в контексте оценки эффективности алгоритмов?Производительность как следует из любого ее определения это количество произведенной пользы в единицу времени. Поэтому независимо от натягивания термина на алгоритмы сравнивать производительность алгоритма со временем его работы (тем более в общем случае) некорректно.
Простите, но я всё-таки хотел бы увидеть это "любое определение" в применении к алгоритмам не в вашей трактовке, а где-либо в авторитетном источнике. Желательно с формулами, которые характеризовали бы "производительность" того или иного алгоритма.Надеюсь, мне не надо объяснять, почему в технических статьях (новостях, заметках) следует придерживаться общепринятой терминологии, а не изобретать новояз и "натягивать" его потом на обсуждаемую тематику? Или надо?
Я соглашусь с вами, что в общем случае, производительность и время - не одно и то же. Но мы в данной статье видим формулу, которая обычно (всегда) применяется в отношении именно ко времени, сложности, эффективности (всё это слова-синонимы в обсуждаемой тематике) алгоритмов. Если автор решил повыпендриваться таким образом, надо было как-то специально оговорить это, чтобы у людей, читающих подобные заметки не возникало вопросов наподобие тех, которые уже возникли: то ли автор ошибся с формулой, то ли производительность алгоритма - это его собственное изобретение. Хотя, казалось бы, зачем оно здесь, если в оригинальной статье применяется именно время работы?
Собственно, заметку уже поправили.
Вот, если что, ссылка на статью из Вики. https://ru.wikipedia.org/wiki/%D0%AD%D1%...Читаем, пример для эффективности O(n) - Поиск элемента в несортированном списке или несбалансированном дереве (худший случай). Вполне себе хорошая аналогия. Так что всё-таки комментатор выше прав в своём недоумении.
>Отношение количества операций к количеству пикселейкаких операций? над одним пикселем? так у алгоритма конечное количество операций над одним пикселем, а таких пикселей много.
Вот только количество пикселей прямо таки зависит от размера изображения, а количество операций пропорцинально "характеру" (формату представления и способу сжатия) изображения. Что уж говорить об их отношении.
Тот случай, когда слова расходятся со смыслом буквально, но с самого начала понятно?
F djn b gjyznyj!
Недавно на Hacker News видел + реализацию на Zig, думаю, будет легко реализовать на каком–нибудь другом языке
zig сам по себе простой язык. И даже не оброс еще пакетами, что хорошо.
Вся экосистема библиотек с C API к твоим услугам
что плохого в развитой экосистеме языка?
Это фактически lz4.
По-моему даже вот очено конкретно.
Нужно было lzi называть или как-то так.
Астанавитесь! WebP не успели вкатить везде, накатили AVIF, не успели его вкатить, теперь уже новый убероптимизированный формат - JXL!Да пофиг на эти проценты. Нужен достаточно оптимизированный формат с широкой поддержкой и многолетней обратной совместимостью.
webp нормально уже вкатился
Да нифига. Попробуйте например в Telegram послать webp изображение как файл. Telegram его вроде показывает, но уверен, что это стикер: ни увеличить, ни сохранить его нельзя.
Формат то понят телегой. Просто у него своя особая семантика к нему и свои какие-то телодвижения
> webp нормально уже вкатилсяГы-гы, мне смешно от ваших отзывов. И как там с профилями ICC? А... вы таким не пользуетесь. Ну ладно-ладно, тогда вкатился.
ICC в web??? WebP делался для ускорения загрузки web-страниц, и не более... Хотя сейчас, по слухам, есть какие-то HDR мониторы, и там что-то пошире sRGB. Но оно точно надо в web? Ах да, скоро ж всё будет только в web. Особо круто будет работать в 40 км к северу от Новосибирска.
> ICC в web??? WebP делался для ускорения загрузки web-страниц, и не более...
> Хотя сейчас, по слухам, есть какие-то HDR мониторы, и там что-то
> пошире sRGB. Но оно точно надо в web? Ах да, скоро
> ж всё будет только в web. Особо круто будет работать в
> 40 км к северу от Новосибирска.ICC нужно для ЛЮБОГО монитора, а не только для HDR. И таки оно нужно в Web в том числе.
В джипеге если не указан профиль, то подразумевается sRGB. Разумный дефолт. К цветовому профиля монитора проыили картинок отношения не имеют.
А зачем нужен профиль картинки, если нет профиля монитора?
> А зачем нужен профиль картинки, если нет профиля монитора?Профиль картинки описывает какой именно цвет имеет каждая точка твоего изображения. Цветовое пространство непрерывно и его можно дискретизировать по разному, отдавая предпочтение тем или иным полутонам, например.
Профиль монитора описывает свойства конкретной модели монитора (или даже конкретного экземпляра монитора в случае индивидуальной калибровки) плюс твои хотелки - например можно сделать несколько профилей под разные температуры цвета и переключать их в зависимости от освещения в комнате.
Спасибо за справку, но это было риторический вопрос. Я твёрдо убеждён, что недоподдержка новых форматов нафиг не нужна. За ссылками на отсутствие поддержки цветовых профилей, надеюсь, посылать в багзиллу не надо?
Риторические вопросы обычно имеют ответы, очевидные для спрашивающего. По предыдущей части у меня не сложилось впечатления, что ты вообще понимаешь о чем речь.Если профиля нет, то это просто значит, что какая-то интерпретация палитры прибита к стандарту гвоздями. Не вижу в этом ничего незаконного - сплошная экономия на размере изображений и отсутствие двусмысленности с опенсорсными прогами, которые могут быть скомпилены с поддержкой профилей и без.
> Риторические вопросы обычно имеют ответы, очевидные для спрашивающего. По предыдущей части
> у меня не сложилось впечатления, что ты вообще понимаешь о чем
> речь.Всё хуже, дело в том, что если профиль даже есть, то изображение интерпретируется как sRGB. Про инструментарий же отличный от браузеров я вообще молчу. Там "вкатывание" будет продолжаться не один год. Только вкатятся и новый "стандарт" на 2-5% эффективнее при нулевой обратной совместимости. Кстати, о совместимости, в этом отношении всё же JXL лучше. Он хотя бы обещает пережатие JPEG без потери качества за счёт более эффективного алгоритма остаточного кодирования. Но процент его "вкатывания" едва выше нуля, а куда девать WebP, AVIF, HEIF - не понятно.
> Всё хуже, дело в том, что если профиль даже есть, то изображение интерпретируется как sRGB.Ну вот иди сюда и посмотри как интерпретируется изображение: http://www.libpng.org/pub/png/png-colortest.html - уверен, что современных броузеров игнорирующих профили изображения ты не найдешь.
Или вот возьмём какое-нибудь изображение с той странички, например http://www.libpng.org/pub/png/img_png/ArcTriomphe-iCCP-red-g... , сохраним его в ФС и попробуем открыть ГИМПом. Гимп увидит, что профиль нестандартный и предложит сконвертировать его.
Хотя, если я на своём десктопном распберри пи открою то же изображение специализированной программой-просмотрщиком изображений GPicView или Ristretto v.0.8.3 - то эти воротца я увижу зелёненькими. И я не уверен, что эти программы ничего не знают про цветовые профили - вполне возможно мейнтейнеры распбиана решили чутка сэкономить и просто собрали их без поддержки профилей. Вот на такие случаи формат изображения, не подразумевающий кастомных профилей, является более надёжным решением, всегда дающим результат, близкий к желаемому.
С другой стороны я тоже не вижу для себя особых выгод от перелезания на новые форматы, обычно пользуюсь jpeg, gif и иногда png. Поле для конкуренции между форматами сейчас должно быть с точки зрения оптимизации их обработки за счет более эффективного использования процессорного кеша, и вот сабжевый формат тут, возможно, имеет какие-то шансы за счет меньшего размера исполнимого кода и меньших пробегов по картинке во время обработки.
> Ну вот иди сюда...https://bugzilla.mozilla.org/show_bug.cgi?id=1709814 — а создатели-то браузеров не в курсе..., AVIF тоже не умеет, WebP, слава Богу, уже научили, но там другие проблемы есть...
https://github.com/mozilla/pdf.js/issues/2856 — восемь лет багу...
Накидать про корявость цветокалиброванного воркфлоу в принтерах?
Так о чем и речь - раньше и с распространенными картинками бровсеры не справлялись. Картинки без профилей проще. Кстати, окуляр на удивление, справился с ПДФом по второй ссылке. Не ожидал от него.Нет, спасибо, не надо повышать энтропию треда ещё и принтерами :)
> Так о чем и речь - раньше и с распространенными картинками бровсеры
> не справлялись. Картинки без профилей проще. Кстати, окуляр на удивление, справился
> с ПДФом по второй ссылке. Не ожидал от него.
> Нет, спасибо, не надо повышать энтропию треда ещё и принтерами :)Все на поплере справляются, а FF нет, т.к. декодер там для картинок (всех поддерживаемых форматов) внезапно не нативный, а javascript'овский и очень примитивный по своему функционалу! С другой стороны есть поддержка JPEG2000, который необходим для PDF, а в браузерах его нет и не будет.
> webp нормально уже вкатилсяЕщё пример: github не поддерживает заливку webp изображений в комментарии. png или jpg можно, но не webp.
AVIF ни о чём. Webp заменяют на webp2 который не такой убогий, но тоже не сахар. JXL был бы прекрасен, если бы не был таким кривым и давал использовать низкий битрейт (желательно без вымывания всего цвета как это позволяет webp). Но это лосси, в контексте лосслесс jxl никто не превзойдёт. Для текстур и прочего уже придумали tga или специальные форматы.
TGA? Придумали? Ах, ностальгия...
Представьте, что вам надо не одно изображение кодировать, а тысячи, десятки тысяч, причём с заданным временем отклика. Если алгоритм из новости даёт возможность вместо, условно, 32-процессорного монстра купить что-либо на порядок (в 10 раз) дешевле и делать всё то же самое на нём, то почему бы и не воспользоваться данным алгоритмом?Ещё вопрос. Зачем нужна именно многолетняя обратная совместимость? Ну не увидит кто-то в древнем смартфоне кошака, картинка с которым будет в новом формате, и что?
> Ну не увидит кто-то в древнем смартфоне кошака, картинка с которым будет в новом формате, и что?Заведут баг, и его надо будет чинить.
Вроде это так работает?
Речь не об этом. Речь о том, зачем нужна многолетняя обратная совместимость. Вот что мне непонятно.
Чтобы не создавать потом факультетов древних и восточных языков?
Чтобы видеть кошака на древнем телефоне и Windows XP.
> Речь не об этом. Речь о том, зачем нужна многолетняя обратная совместимость.
> Вот что мне непонятно.Потому что заводят баги и их надо чинить
Чушь не городи! Никому и никогда не надо "тысячи, десятки тысяч, причём с заданным временем отклика" - искусственная задача. Для веба достаточно того, что каждый му****ак, которому хватило времени вкорячить на сайт богомерзкий JS, потратил время на перекодирование своих убожеств в WebP.
На твоих задачах и твоём опыте свет клином не сошёлся же? Или сошёлся?Возьмём те же социальные сети. Или софт, обрабатывающий медицинские снимки. Или оцифровка видео без потерь. Или сайты фото-банки. Да мало ли применений может найтись подобному формату.
Ещё webp активно юзают в мобильных играх. Там часто очень большие объёмы, ко времени правда нет жоских требований, сугубо оптимизация времени сборки
> Ещё webp активно юзают в мобильных играх. Там часто очень большие объёмы,
> ко времени правда нет жоских требований, сугубо оптимизация времени сборкиШо, текстуры в WebP видюхи уже грузят или так, для стикерпаков?
Совместимость нужна например для старых мобилок в которые не очень быстро заезжают аппаратные ускорения сабжа и аналогов
Создатели устройств, в которых владелец не может обновить прошивку в силу проприетари и блобов, должны гореть в аду вместе с их последователями
> Создатели устройств, в которых владелец не может обновить прошивку в силу проприетари и блобовДругих не бывает.
PinePhone
ну есть несколько устройств: https://wiki.lineageos.org/devices/
Не уверен, что ради 10% людей, не желающих обновлять смартфоны на более современные, надо заморачиваться многолетней обратной совместимостью, причём в некритичной для жизни области: по большей части речь идёт ведь о сфере развлечений.
> Не уверен, что ради 10% людей, не желающих обновлять смартфоны на более
> современные, надо заморачиваться многолетней обратной совместимостью, причём в некритичной
> для жизни области: по большей части речь идёт ведь о сфере
> развлечений.Угу, у меня коллега семейные фотографии в вотсапе хранит. Оно же навсегда, сервисы никогда не закрывают, ключи шифрования не теряют.
GIF
Поддерживаю алерт. WebP - сами видите, "не новичок", а вот однако ж, далеко не везде! По-хорошему, когда КАЖДАЯ программа будет давать опцию "WebP", тогда и можно говорить о безоговорочной победе пролетариата. А пока дилетанты и пеpдуны сидят со своими jpeg'ами (и, прости господи, gif) и даже не пытаются двикаться в сторону света.
>А пока дилетанты и пеpдуны сидят со своими jpeg'ами (и, прости господи, gif)Это и есть устоявшиеся стандарты, о которых говорил тот, кому отвечаете. А веюп пока не прошёл проверку временем, как огг, к примеру. Ну не нужны они большинству, утритесь этим фактом.
Большинству, к сожалению, ничего не нужно, кроме хлеба и зрелищ.
> Большинству, к сожалению, ничего не нужно, кроме хлеба и зрелищ.И что даёт ваш лозунг? Что невостребованные технологии сразу становятся востребованными?
Никакой победы пролетариата в ССР не было. Была победа партократии. Это был класс эксплуататоров если говорить терминами Маркса. Ни одного рабочего в верхах сср не было!!!
> Никакой победы пролетариата в ССР не было. Была победа партократии. Это был
> класс эксплуататоров если говорить терминами Маркса. Ни одного рабочего в верхах
> сср не было!!!Эксплуататором по Марксу была буржуазия, которая владела средствами производства и использовала их для извлечения личной прибыли. Дети партийной верхушки СССР не сформировали нового поколения правителей, что всё же даёт основания верить в идеологию, отличную от культа Маммоны.
Сформировали.
> Сформировали.Накинь пару-тройку имён опрысков партийного руководства, оставшихся у кормушки. Только вот не надо там глав райцентров среднеазиатских республик эпохи перестройки.
Потомки бывших вождей предпочитают жить за границей.
> Потомки бывших вождей предпочитают жить за границей.Так погоди, а где же те потомки, которые якобы сформировали правящий класс СССР?
> Накинь пару-тройку имён опрысков партийного руководства, оставшихся у кормушки.https://ru.wikipedia.org/wiki/Басков,_Николай_Викторович
https://ru.wikipedia.org/wiki/Галкин,_Максим_АлександровичНу, Вы понели, куда надо смотреть и почему некий режиссёр спектаклей отрицательной ценности оплатил штраф по делу о хищении и гуляет.
Я даже не ходил по ссылке, т.к. СССР уже 30 лет как не существует, а перечисленные персонажи к руководству страны имеет отношение не больше моего?
Вопрос был про кормушку (впрочем, их братия и пытается руководить мнениями). Сходите по ссылке, там у них папы интересные. Я бы понял, если бы талантливые детки продолжали дело родителей, как когда-то было принято, а не вещали с экранов со странным "акцентом".
> Вопрос был про кормушку (впрочем, их братия и пытается руководить мнениями). Сходите
> по ссылке, там у них папы интересные. Я бы понял, если
> бы талантливые детки продолжали дело родителей, как когда-то было принято, а
> не вещали с экранов со странным "акцентом".Спасибо, я в курсе, но к предмету обсуждения это не имеет никакого отношения, т.к. СССР прекратил существование 30 лет назад.
>> Вопрос был про кормушку (впрочем, их братия и пытается руководить мнениями). Сходите
>> по ссылке, там у них папы интересные. Я бы понял, если
>> бы талантливые детки продолжали дело родителей, как когда-то было принято, а
>> не вещали с экранов со странным "акцентом".
> Спасибо, я в курсе, но к предмету обсуждения это не имеет никакого
> отношения, т.к. СССР прекратил существование 30 лет назад.Смотри какой расклад. Ты не сходил по ссылкам. Не прочитал про родителей членов КПСС и рождённых в СССР детей. Эта проблема в тебе и она действительно не имеет отношения к вопросу. Зачем ты на ней акцентируешь внимание? Не важно, что ты сам родился после развала СССР. Упомянутые люди родились в СССР и приближены к кормушке влиятельными родителями. При этом они именно что у кормушки: много кюшают и ни за что не отвечают.
Я родился и пошёл в школу в СССР, у меня были политзанятия в начальной школе и стоял портрет В.И. Ленина на парте (разумеется, когда я учился лучше всех в классе). У меня один из родителей был членом КПСС и депутатом в маленькой, но гордой республике. Мне это никак не помогло (да и не помешало) в дальнейшей моей жизни, миллионов я тоже не видел.Я сходил по ссылкам и не понимаю, какая связь c тезисами из "Никакой победы пролетариата в ССР не было. Была победа партократии. Это был класс эксплуататоров если говорить терминами Маркса. Ни одного рабочего в верхах сср не было!!!"?
Связь чего с чем? Связь самоназначенных "звёзд" с кормушкой очевидна. Не я про кормушку написал, приравняв к контуру управления (и получилось "а ещё мы в неё едим"). Если ЦК управлял с помощью идеологии, то эти точно так же управляют с помощью идеологии, просто идеология сменилась. Они сами себя и называют Четвёртая власть. А то что у кого-то папа был в КПСС, но не в ЦК, и потому он не попал к кормушке -- так именно про это и шла речь.
> Связь самоназначенных "звёзд" с кормушкой очевидна.Ты действительно считаешь их самоназначенными? Я не даю оценку тому, чем они занимаются, но, очевидно, что народу это нравится (нравилось).
А, кстати, чем же они занимаются, один рекламирует суррогатное материнство, по сути торговлю детьми? А оперный певец вдруг стал ведущим шоу "Дом"? Понятно, что не один другого назначал, а кому-то это выгодно. Например, можно трудовые накопления из сберкасс легализовать.
> а кому-то это выгодноВ соседней стране с такой логикой очень далеко зашли, советую не злоупотреблять.
>> а кому-то это выгодно
> В соседней стране с такой логикой очень далеко зашли, советую не злоупотреблять.Не думал, что кого-то может бомбануть, придётся переформулировать на чуть менее понятный пример.
Когда Вы хотите покушать - Вы руководствуетесь логикой? Здесь ответ писать не надо, я его и так знаю.
> Не думал, что кого-то может бомбануть, придётся переформулировать на чуть менее понятный пример.
> Когда Вы хотите покушать - Вы руководствуетесь логикой? Здесь ответ писать не надо, я его и так знаю.Три дня за мной бежал, чтобы сказать, насколько я тебе безразличен?
> Три дня за мной бежал, чтобы сказать, насколько я тебе безразличен?Если не хочешь видеть ответы на свои вопросы, это сделать очень просто -- не задавай вопросы. Тем более в публичном месте. И да -- это не логика.
webp уже используется в инстаграмме, а это уже распространённее некуда.
Херограмме.От этого вебпе одна головная боль.
Потому что вот браузер его показывает, а сайт далеко не каждый принимает, а тот сто принимает может неверно понимать.Не все просмотрщики изображений его умеют. Не все редакторы.
И нахуа? Ради чего?
С сжв, простите свж, такие же проблемы.
Вместо тысячи слов:
https://duckduckgo.com/?q=convert+webp
Мальчик с косичкой, шел бы ты ядро конпелять.
> Мальчик с косичкой, шел бы ты ядро конпелять.Зойчем? Меня и стоковое устраивает, а стороннее я могу и в dkms прикрутить.
Хм, я уже где-то видел тесты. Кодирование действительно было в разы быстрее, но декодирование было неспешным. Может то была какая-то альфа-версия? Сейчас уже не найду статью...
Судя по описанию алгоритма, оно должно в обе стороны шустро гонять.
В оригинальной статье есть ссылка на тесты.
Декодировать должно ещё быстрее. Буквально пропускная способность ОЗУ тут лимит.
>STBНу, STB скажем так не блещет скоростью. Бенчи - https://github.com/HappySeaFox/sail/blob/master/BENCHMARKS.md
Название плохо подобрано - не взлетит.
Не взлетит совершенно по другой причине.
Вполне представляю, что в каком-нибудь жёстком embedded кто-нибудь будет использовать такой примитивный способ сжатия.
Зачем кодировать изображения на STM8S003F3?
Для бортового компьютера автомобиля.
В бортовых компьютерах каких автомобилей сэкономили пару баксов на нормальную микросхему для кодирования в реальном времени изображения в 4к и поставили микросхему за 5 центов?
А зачем там реальное время изображения в 4к?
Для камер обзора и сохранения в облако, как вариант.
Какие камеры обзора и облако в троллейбусе МАЗ-ЭТОН-Т203?
Китайские!
Не знаю, что там в автомобилях, но, например, в видеокартах часто экономят на конденсаторах и/или термопрокладках. Казалось бы, копеечная экономия, а поди ж ты.Однако, допустим, что и в автомобилях так решили. Давайте допустим, что общий тираж такой модели у Тойоты составит 12 млн. машин в год. Умножаем 2 доллара экономии на 12 млн. и получаем 24 млн. доллара на ровном месте. Почему бы и нет?
Вспомнился один персонаж, который выбирал между 4-мя МЕГАбайтами (SIMM) и лесенкой на крузер.
Если кто-то положил в карман 24 миллиона долларов за счёт многолетнего ежедневного неудобства 12 миллионов человек, то позор ему.
Когда у человека прибыль в 24 миллиона долларов, ему плевать на позор.
> многолетнего ежедневного неудобства 12 миллионов человекУ Билли на неск-ко порядков больше аудитория мучеников - и ничего, живёт и радуется.
Апплеапологеты еще и Илитой себя ощущают за оверпрайснутые поделки, которые еще и следят за тобой.
Ну, адепты космонавта тут всех переплюнут.
Как раз SPI Flash или EEPROM можно прикрутить, чего не скажешь о мощности ядра
Ну вот умножьте стоимость лишнего SPI Flash на 100 миллионов. Вот столько денег компании вы решили потратить совершенно без причины.
P.S.: При этом вы не только напрасно потратили деньги компании и место на плате, вы ещё добавили дополнительную точку отказа.
Мне вот всегда странно слышать что кто-то смог сделать ещё более эффективный формат в области где уже десятилетия мощнейшие мозги работают. Но если это правда то просто супер.
Интересно будет когда попробуют его векторизировать, возможно даже придётся формат передалать.
А почему бы и нет? И кто сказал, что авторы этого алгоритма - не мощнейшие мозги? Ждём, что скажет академическое сообщество и программистское комьюнити.
Если этот парень написал алгоритм, который я усвоил, прочитав один абзац, то он мой герой.
'Working on QOI was a lot of fun.'
там ничего не сказано на каких изображениях получены результаты по уровню сжатия
ведь фото, рендер, рисунок или скрин - дадут совершенно разные результаты!
Не поленитесь, откройте оригинальную статью, там всё есть.
ага, нашёл https://phoboslab.org/files/qoibench/
кмк, выборочка весьма нерепрезентативная… но да ладно)
Ну судя по описанию алгоритма он должен подойти к скриншотам и разного рода логотипам. Он ожидает большие малоизменяющиеся области. Ну вот например на бенчмарке - фон страницы.
С более полноцветными изображениями типа "хамелеон на фоне джунглей" или той же "леной" будет справляться хуже, поскольку чащу будет напарываться на ситуацию "Ничего не понимаю, пишу целый пиксель". По хорошему этот алгоритм - RLE + небольшой буфер для индексации.
Ну то есть в принципе для тех же изображений, для которых предназначен PNG - должен работать вполне сносно. Но вот фотографии через него прогонять не стоит.
Там афтырь неплохо в своей статье проехался по мощнейшим мозгам и каким местом они наработали.Жаль что он ниасилил эффективный _видео_ кодек (как изначально замахивался). Поскольку от фото-кодеков требуется именно совместимость на века, а не эффективность.
Это прото lz4 с учётом rgb.
Мне было бы интересно на сколько увеличится производительность (многопоточная обработка) и размер файла если добавить "ключевые кадры". Можно было бы гибко играться этими параметрами.
Зачем рассуждения о скорости, когда нет представления о коэффициенте сжатия?
Этот формат для сжатия БЕЗ потерь. К чему попытки сравнивать тут в комментариях с методами с потерями?
Старые алгоритмы сжатия без потерь ориентировались на изображения "без украшательств". Теперь кругом модные подложки, полупрозрачности, размытия шрифтов и линий. Цель такого кодировщика восстановить растровое изображение идентичное оригиналу, при этом иметь размер в сжатом виде соизмеримый с количеством исходной информации, представляющей ценность, а не украшательства.
"
По эффективности сжатия QOI в большинстве тестов близок к libpng (в каких-то тестах немного опережает, а в каких-то проигрывает), но в целом заметно опережает stb_image (выигрыш вплоть до 20%).
"
Там, в первом абзаце..
Это было изначально прочитано. Если рассматривать только приведенную информацию, то цифры говорят скорее против нового формата. То есть, исходя из вышесказанного, формат не переработан под современные реалии. Другого от цивилизации ворда и ожидать не приходится.
Какое-то странное "сравнение" по степени сжатия.libpng сжимает с помощью zlib. Однако формат PNG позволяет использовать более эффективные реализации алгоритма сжатия Deflate. Например, реализацию из 7z.
stb_image.h только декодирует.
stb_image_write.h всегда жал "not optimal" самопалом ("it is 20-50% larger than the file written by a decent optimizing implementation"). Либо с помощью всё того же zlib.
А в чем заключается странность?
Зачем с png сравнивать. Тут webp конкуррент скорее
webp отнюдь не простой формат.
А PNG, проходящийся по каждей строчке картинки пять раз для определения метода фильтрации перед применением LZSS и Хаффмана, простой, да?
Я конечно понимаю коммент удалят.Но все равно вопрос.А порно фото с известного сайта сжимает лучше чем jpeg или png дает самое лучшее качество?
Тем товарищам пора разрабатывать собственный алгоритм, проблемно-ориентированный... Например устанавливать пользователю заранее словарь кодирования.. размером пару гигов.. зато потом просмотр будет супербыстрый и экономичный...
Пару гигов ух! Это уже тогда mysql тогда надо.А супер быстро то и не надо как бы.Надо ведь рассмотреть изображение хорошо а png самое то.А этого формата вроде и нет в огнелисе.
>порно фото с известного сайтаС какого сайта? Друг спрашивает
Сайт очень известный а то вы и не знаете? Да ладно!
http://www.lenna.org/
Это не тот сайт.Какая в лобаду лена.Это не те дроиды которых вы исчете.
Тимур, ты уже 5 лет назад спрашивал - неужели опять забыл? :))
O(1) это константное время операции.
Однопроходный перебор всех пикселей это O(n)
>O(1) это константное время операции.Не время, а scalability.
Ерунда. "scalability" по определению зависит от одного или нескольких параметров. O(1) не зависит от n.
QoI fungicides are used on a wide range of crops, such as cereals, vines, pome fruits, cucurbits, tomatoes and potatoes.
Да никакого смысла в этом нету, png > webp > avif > jxl по силе сжатия, это почти в 2 раза сильнее, из-за развития технологий за последние 25 лет, и между прочем скорость кодирования у них ну крайне медленная а вот Декодирование вполне быстрое что бы открывать фоточки за пол секунды, увы никому не нужен быстрый формат фото для быстрого сжатия без потерь, это вам не zstd
символьной, схематической, формальной семантики достаточно. а то передают в сверхсовременных форматах изображение грифельной доски лектора с мелом.
По-моему, у вас стрелки не туда показывают. Получается что пнг сжимает лучше всех, скорей всего все наоборот.
> а вот Декодирование вполне быстрое
> что бы открывать фоточки за пол секундыВы большие PNG файлы когда-нибудь открывали? Никакими "пол секунды" там и не пахнет, даже на мощном процессоре. Или под фоточками вы подразумеваете исключительно превьюшки настоящих фотографий в стиле инстаграма?
> никому не нужен быстрый формат фото для быстрого сжатия без потерьОтучаемся говорить за всех. Попробуйте хоть чуть-чуть абстрагироваться от своего ограниченного жизненного опыта.
Если все так, думаю, этот алгоритм был бы очень полезен во всяких VNC и иже с ним. Автор красавчик.
> Please note that this library is not yet ready to deal with untrusted input.
Ну это очень просто фиксится.
https://en.wikipedia.org/wiki/Run-length_encoding
Да это понятно, что алгоритм стар как папкины дискеты, но если адаптировать с учётом характера данных, можно что-то вытянуть. Особенно для всяких схем - там полно белого BG.
Скриншоты, схемы - для этого отлично гиф подходит.
Хороше бы в огнелиса интегрировали и в VNC тоже.
Ждем QOI в ffmpeg.
и новые уязвимости
Первая мысль. о, это круто.... о, это интересно. Потом подумал, ну пусть он, QOI, сначала разойдется, сначала начнет юзаться там и там. А то форматов изображений достаточно много уже. Webp. Jpeg2000. Есть еще какие-то другие которые опережают PNG. Ну и что ? Где они разошлись? Нигде почти. Так что. Ну еще один формат... Ну вы ребята сначала найдите свою нишу. Найдите популярность.
Есть много вариантов, как его прямо сейчас можно использовать - в играх, приложениях со вшитыми изображениями, видеопоток кодировать быстро, пусть и с небольшим сжатием. Ждать когда он разойдётся, необязательно.
Webp очень популярен и поддерживается уже практически везде
веб ненужон
веб ненужонСкажи лучше это свой мамке болван , для кучи интернет мусора картинок стандарт сокращает жадность размера картинки отдавая качество такое же , а вес на 70% и больше меньше.
наивный, какое качество, берут jpeg и перекодируют в Webp, экономя трафика, сдался ты им со своим качеством
Он только как внутренний web формат популярен. Ну там показать иконочки на сайте или фоточки продукта в каталоге. За пределами этого его как бы и нет.
Ага, только вот на том же пикабу с многомиллионной аудиторией все картиночки в WEBP.
А еще они едят чипсы и считают это нормальной едой
Я понимаю, быть илитой пачотно. Но речь шла по распространённости.
jpeg2000 был офигенен в свое время, у него была очень перспективная база в виде вейвлетов вместо dct, правда платой за это была алгоритмическая сложность.
Но шансы стать новым стандартом были похоронены патентами. Sad but true.
Популярность и востребованность у обывателей - такой себе критерий оценки. Иначе получается, что mp3 с jpeg - венец развития.
Так что использовать то? png, jpg, webp или энтот новый?
JPEG родимый. А вообще, смотря для чего.
JPG для фотографий, PNG для остального.
и для кое-чего SVG
для растра с малым числом оттенков - gif
В 21 году, мы видим все еще самыми популярными jpg и mp3
Где вкатили webp теперь нельзя сохранить как... в браузере сделать. Опечален
Музыку уже предпочитают беспотерьно сжимать, FLAC.
И много кто себе на телефончик флаки закидывает? Про стриминг я уже не говорю.
Стриминг FLAC есть, хотя это немассовое и обычно премиум явление, а проблема заикидывания на телефон решается емкой картой памяти.
Муня тут больше прикалывает тот факт что люди слушают разжатый FLAC через...Блютус наушники, которые кодируют звук своим кодеком между передатчком и приемником. Какой смысл после этого...
Я знаю, что и стриминг есть, и карты памяти сейчас копеечные. Вопрос в том, МНОГО ли кому это нужно.
Flac настолько замечательный формат, что позволяет услышать треск магнитофона, который оцифровывал запись, которую вы слушаете.Если честно, мне было бы интересно посмотреть на то, насколько LDAC "портит" звук, и если не сильно, то почему им и не кодировать треки.
Можно предположить, что они не всегда слушают это через блютуз и не видят смысла хранить рядом ещё и копию в ухудшенном качестве специально для прослушивания через БТ :)
Я во flac диктофонные записи пишу.
В 24/192, надеюсь? Иначе нещитово.
Ну человеческая глупость неискоренима, особенно в сарказме, если понимать для чего нужен диктофон, и какую звуковую полосу частот он пишет.
Во flac библиотека на ПК, на телефоне в opus.
> Если очередной пиксель совпадает с предыдущим, то лишь увеличивается счётчик повторений. Если пиксель совпадает с одним из значений в буфере 64 прошлых пикселей, то вместо значения указывается 6-битовое смещение на прошлый пиксель. Если цвет прошлого пикселя незначительно отличается, в короткой форме указывается различие (сокращённое кодировние различий цветовых составляющих, укладывающихся в 2,4 и 5 бита). Если оптимизация не применима, указывается полное значение rgba.Кто-то переизобрёл RLE и LZW... Но описание интригует. Надо будет потестировать самому.
Автор не претендует на инновационность. Он подобрал простых велосипедов, которые реализуются в 300 строк кода и в сумме дают достаточно хороший результат
> Автор не претендует на инновационность. Он подобрал простых велосипедов, которые реализуются
> в 300 строк кода и в сумме дают достаточно хороший результатНу так я не издеваюсь, так, слегка иронизирую.
LZW был в GIF, а это гораздо боле простой алгоритм.
> LZW был в GIF, а это гораздо боле простой алгоритм."Если пиксель совпадает с одним из значений в буфере 64 прошлых пикселей, то вместо значения указывается 6-битовое смещение на прошлый пиксель." - LZ* класс алгоритмов, GIF, PNG... Ну, точнее сильно упрощённый LZ.
"Если очередной пиксель совпадает с предыдущим, то лишь увеличивается счётчик повторений." - RLE алгоритм. Использовался в PCX, BMP (хотя BMP со сжатием не все программы понимали)
"Если цвет прошлого пикселя незначительно отличается, в короткой форме указывается различие (сокращённое кодировние различий цветовых составляющих, укладывающихся в 2,4 и 5 бита)." - что-то похожее на ADPCM, только адаптированное для растра, а не звука.
image.Q0I
image.QOI
image.Q01
image.QO1А потом пля удивляются https://www.opennet.dev/openforum/vsluhforumID3/125739.html
у тебя шрифт не православный
https://i.ibb.co/cNXyHTV/pravoslavnifont.jpg
Спорщикам насчёт O(1) O(n) простая задачка.
Сколько будет по отношению к пикселам? Правильно, O(n)
Сколько будет по отношению к целому изображению? Правильно, O(1), так как проход по изображению только 1 :D
Такие дела.
Короче я согласен за O(n), но O(1) на глобус натягивается элементарно, если принять изображение за единицу данных.
Спорщикам насчёт O(1) O(n) простая задачка. Сортировка коллекции из 2000000000 элементов пузырьковым методом.
Сколько будет по отношению к элементам коллекции? Правильно, O(n^2)
Сколько будет по отношению к целой коллекции? Правильно, O(1), так как сортировка была только одналогика опеннет экспертов.
O(1) это не один проход, это константная сложность
Не совсем. Все эти асимптотические сложности оценивают сложность выполнения на машине Тьюринга. Там квадрат n неизбежно возникнет. Другое дело, что n может быть константой. И вот тогда ты можешь хоть сколько массивов сортировать, сложность сортировки каждого будет O(1).То есть, ты вроде и правильно сказал, но мимо цели. Количество массивов не влияет на сложность сортировки пузырьком. Хотя если у нас ровно один массив, то n вроде как константа. Хотя хз: может ли что-то называться константой, если никто не пытался его менять? Вот если попытались и не вышло...
>Правильно, O(1), так как сортировка была только однада вам премию Тьюринга, ой Тьфуринга надо дать.
https://ru.m.wikipedia.org/wiki/%D0%A1%D0...на досуге
Мне кажется, алгоритм даже ещё лучше чем описано, т.к. из описания следует, что скорее всего кодированное изображение можно ещё _эффективно_ прогнать через архиватор, типа bz2. В отличие от png где вся энтропия уже использована.
> Мне кажется, алгоритм даже ещё лучше чем описано, т.к. из описания следует,
> что скорее всего кодированное изображение можно ещё _эффективно_ прогнать через архиватор,
> типа bz2. В отличие от png где вся энтропия уже использована.Неа.
#!/bin/bashSTART_X=200
START_Y=150for ((i=1; i<10; i++))
do
x=$(($i*$START_X));
y=$(($i*$START_Y));
head -c "$((3*x*y))" /dev/urandom | convert -depth 8 -size "${x}x${y}" RGB:- random-"${x}"x"${y}".png;
donefor i in *.png; do echo ../qoiconv $i $i.qoi; done
bzip2 -kz9 *.qoi;
ls -la | awk '{print $5" "$9}' | sort -n | column -t;
90481 random-200x150.png
102175 random-200x150.png.qoi.lzma
102236 random-200x150.png.qoi.xz
102777 random-200x150.png.qoi.gz
105689 random-200x150.png.qoi.bz2
119619 random-200x150.png.qoi
119695 random-200x150.png.qoi.lzo
361092 random-400x300.png
409830 random-400x300.png.qoi.lzma
409940 random-400x300.png.qoi.xz
410943 random-400x300.png.qoi.gz
418278 random-400x300.png.qoi.bz2
478434 random-400x300.png.qoi
478522 random-400x300.png.qoi.lzo
811929 random-600x450.png
922013 random-600x450.png.qoi.lzma
922208 random-600x450.png.qoi.xz
924535 random-600x450.png.qoi.gz
930832 random-600x450.png.qoi.bz2
1076293 random-600x450.png.qoi
1076417 random-600x450.png.qoi.lzo
1443083 random-800x600.png
1639903 random-800x600.png.qoi.lzma
1640204 random-800x600.png.qoi.xz
1643651 random-800x600.png.qoi.gz
1651356 random-800x600.png.qoi.bz2
1913416 random-800x600.png.qoi
1913576 random-800x600.png.qoi.lzo
2254528 random-1000x750.png
2561200 random-1000x750.png.qoi.lzma
2561648 random-1000x750.png.qoi.xz
2568004 random-1000x750.png.qoi.gz
2581402 random-1000x750.png.qoi.bz2
2989527 random-1000x750.png.qoi
2989736 random-1000x750.png.qoi.lzo
3246251 random-1200x900.png
3689247 random-1200x900.png.qoi.lzma
3689876 random-1200x900.png.qoi.xz
3697809 random-1200x900.png.qoi.gz
3714149 random-1200x900.png.qoi.bz2
4305202 random-1200x900.png.qoi
4305471 random-1200x900.png.qoi.lzo
4418269 random-1400x1050.png
5020919 random-1400x1050.png.qoi.lzma
5021748 random-1400x1050.png.qoi.xz
5033110 random-1400x1050.png.qoi.gz
5056000 random-1400x1050.png.qoi.bz2
5770586 random-1600x1200.png
5859828 random-1400x1050.png.qoi
5860170 random-1400x1050.png.qoi.lzo
6557833 random-1600x1200.png.qoi.lzma
6558900 random-1600x1200.png.qoi.xz
6573773 random-1600x1200.png.qoi.gz
6602008 random-1600x1200.png.qoi.bz2
7303156 random-1800x1350.png
7653462 random-1600x1200.png.qoi
7653888 random-1600x1200.png.qoi.lzo
8295150 random-1800x1350.png.qoi.lzma
8296500 random-1800x1350.png.qoi.xz
8319590 random-1800x1350.png.qoi.gz
8352895 random-1800x1350.png.qoi.bz2
9686531 random-1800x1350.png.qoi
9687041 random-1800x1350.png.qoi.lzoLZMA как всегда, лучше всех плющит.
глупо проверять эффективность сжатия на рандоме.
> глупо проверять эффективность сжатия на рандоме.Скорость работы алгоритма с неизвестными данными примерно
равна скорости работы с данными распределенными по Гауссу, Пуассону, итд.
Более того, за всё время работы алгоритма скорость работы
будет даже медленнее, чем один раз проверенная с рандомом.
>> глупо проверять эффективность сжатия на рандоме.
> Скорость работы алгоритма с неизвестными данными примерно
> равна скорости работы с данными распределенными по Гауссу, Пуассону, итд.только тут измерялось не время работы, а степень сжатия.
для алгоритма, который рассчитан на сжимаемые данные.
>>> глупо проверять эффективность сжатия на рандоме.
>> Скорость работы алгоритма с неизвестными данными примерно
>> равна скорости работы с данными распределенными по Гауссу, Пуассону, итд.
> только тут измерялось не время работы, а степень сжатия.
> для алгоритма, который рассчитан на сжимаемые данные.Дык, если сжатие не зависит от содержимого, то скорость должна быть равна.
Типа strcmp() - ей пофиг, сравнивает i-й байт с j-ым, а strstr() ужо с логикой.
Сжатие - для слабаков. *.bmp рулит.
вообще-то bmp поддерживает RLE сжатие
BMP ещё и встраивание JPEG и PNG поддерживает.
*.bmp рулит.Разогретого до красна тебе телефона и долгой загрузки страниц!
202007 54203449_My_diary.png
239357 54203449_My_diary.qoi
276908 54203449_My_diary2.pngПервый файл сжал во второй и потом разжал в третий.
Или я что-то делаю не так, или картинка такая.
https://i.imgur.com/KnaYWWO.png
inb4: разные файлы
0ec9d8762525b0e5cbc083191b363910 *54203449_My_diary.png
eb21ffad024ef96e0933c9eec2549390 *54203449_My_diary2.png
eb21ffad024ef96e0933c9eec2549390 *KnaYWWO.2.png
2d2267a9001abcfa0cc906e542cbad0c *KnaYWWO.png
98cd3bb5cd7702b5a5bfb906c5a5c805 *54203449_My_diary.qoi
98cd3bb5cd7702b5a5bfb906c5a5c805 *KnaYWWO.qoi
"Разжал в PNG" это нонсенс. Это тоже сжатый формат, и его сжимать можно по-разному, как более эффективно, так и менее. Пробуйте скажем BMP исходник и потом обратно тоже в BMP. Или какие там чисто растровые форматы будут поближе, PNM что-ли.
Оно "сжимает" с этими параметрами: https://github.com/nothings/stb/blob/master/stb_image_write....Исходный был с compression_level = 8? RLE compression ? png_filter = -1;
...
where the callback is: void stbi_write_func(void *context, void *data, int size);You can configure it with these global variables:
int stbi_write_tga_with_rle; // defaults to true; set to 0 to disable RLE
int stbi_write_png_compression_level; // defaults to 8; set to higher for more compression
int stbi_write_force_png_filter; // defaults to -1; set to 0..5 to force a filter mode
...
optipng тебе в руки.
Ну допустим взлетит и...лет 10-20 ждать пока станут пользоваться. Вон, WebP сколько лет, а до сих пор внятной поддержки нет. ФФ сколько лет шел к тому чтобы поддерживать, смотрелки картинок до сих пор через одну понимают, а уж о поддержке со стороны сайтов и говорить нечего - 95% при попытке загрузить webP получаешь О_о, притом что некоторые уже даже графику начали в webP отдавать.
> ФФ сколько лет шел к тому чтобы поддерживатьВот такими темпами он к своим 3% и пришёл.
> смотрелки картинок до сих пор через одну понимаютНе пользоваться убогими смотрелками? На винде сейчас проверил — IrfanView поддерживает, Faststone поддерживает, даже MS Paint поддерживает, лол.
>> ФФ сколько лет шел к тому чтобы поддерживать
> Вот такими темпами он к своим 3% и пришёл.
>> смотрелки картинок до сих пор через одну понимают
> Не пользоваться убогими смотрелками? На винде сейчас проверил — IrfanView поддерживает,
> Faststone поддерживает, даже MS Paint поддерживает, лол.Ну вот на примере Ляликса нормально поддерживает XnViewMP, но это его ниша поддерживать все что возможно. Всякие встроенные смотрелки вроде глаз Мате не поддерживает, да.
на создают всякой ерунды, а после кричат что в каждой щели уязвимость..
Но ведь PNG - это просто матрица сырых пикселей в контейнере, а любое сжатие поверх - это deflate. Что там декодировать?
> Эталонная реализация QOI на языке Си насчитывает всего 300 строк кода.Это и энкодер и декодер. А на расте только decode.rs уже 319 строк. Выходит сишка более высокого уровня язык?
Зачем тебе это знать, ты же не программист.
На расте даже простую вещь сделать сложно.
И правда. Только на нём куча кода.
Растовский компилятор заставляет программиста писать кучу дополнительных проверок и перепроверок, блягодаря чему код намного безопаснее.
А по факту - были утечки в редоксе и падения фурифокса.
> А по факту - были утечки в редоксеГлавное - ни в коем случае не смотреть на сами "факты":
https://gitlab.redox-os.org/redox-os/redox/-/issues/855
>> The Redox kernel does not have the structures in place to allow freeing memory."И вот так - у вас все!"(с)
>> Эталонная реализация QOI на языке Си насчитывает всего 300 строк кода.
> Это и энкодер и декодер. А на расте только decode.rs уже 319 строк. Выходит сишка более высокого уровня язык?https://github.com/phoboslab/qoi/blob/master/qoi.h (631 _строка_ - из них 304 строк с кодом)
А вообще, тебе-то какая разница - ты ж ни разу не разработчик, раз не в курсе таких "мелких нюансов"? Или очередной опеннетный расто-подгорелец болеет "за правое дело"?
Эвон как вас порвало - 2 идентичных коммента с переходом на личность. Давай ещё в третий раз напиши, что ты знаешь про анонима.
> Эвон как вас порвало - 2 идентичных коммента с переходом на личность.Хм, у тебя и с чтением не очень, да?
> Давай ещё в третий раз напиши, что ты знаешь про анонима.Опять пафос, надутые щечки, очередная посадка в лужу - и 0 по теме.
Ты, главное, не забывай уточнять, кого именно "порвало" - чтобы совсем никто случайно не перепутал!
Так в сишном файле половина места под описание алгоритма отведена, а в растовом кроме кода и щепотки комментов ничего нет, так что сишных строк кода меньше всё равно. Но ты не плачь, сходи лучше лайкусиков любимой растишке отсыпь, а то у растовой версии алгоритма почти в 100 раз меньше звёзд на гитхабе. Любимый язык программистов, ага.
> Так в сишном файле половина места под описание алгоритма отведена
> ... Но ты не плачь, сходи лучше лайкусиковТебе в новости прямым текстом написали "300 строк кода" со ссылкой на файл.
"Строки кода" - метрика, известная любому разработчику, а не разработчику достаточно было пройти по ссылке, увидеть разницу и немного задуматься "а чей это так?".
Но анониму некогда по ссылкам ходить и думать - ему палится^W с умным комментировать надо, враги не ждут!
Теперь только и остается лепка унылых отмазок и клоунада.
Впрочем, все как всегда у местных расто-подгорельцев.
Согласен с этим мнением на 100%. Нет смысла в новомодных форматах: https://feet.by/all/mnozhestvo-formatov-kartinok-a-tolku/
Иронично что автор в описании сам ноет о том что "развели форматов - плюнуть некуда". Ну и естественно его решение - запилить еще один формат.
Ну и мерзкий же мужик.
>Дополнительно энтузиастами подготовлены реализации кодировщиков и декодировщиков на языках GoНадо было goi назвать.
Теперь Яндекс возьмет WEBP сжатый из jpeg, который был сжат из png и сожмёт в QOI и останется от него коуй, но яндексу экономия однозначно!!
Этот формат надо в установить фотоаппараты, чтобы было по-умолчанию.
А вот QOI
Это альтернатива png, а не jpg.
Дело не в том, что является он чей-то альтернативой, или нет. Вопрос в том поддержавает-ли он полноцветные изображения фотографического качества.
Я, может быть, дурак, но: выбор в качестве "хеша" тривиального xor'а с обрезанием старших бит разве не приводит к тому, что для картинки с "бедной" палитрой (а именно для таких алгоритм вроде бы и предназначен?) все простые цвета типа #808000 будут хешироваться одинаково?Честное слово, лучше бы, наоборот, резал младшие биты: похожие цвета (различающиеся в младших битах) diff ветка алгоритма достаточно эффективно обработает, а непохожие, но чистые (с круглыми значениями rgb) лучше бы по разным корзинам раскидывать? Где я не прав?
Представляешь картинку, когда один пиксель #551155, а соседний #115511 ? Белый шум какой-то.Но чисто математически, согласен можно было б какие-нить сдвиги добавить,
типа ( r << 8 | g << 4 | b << 2 | a ),Процессорная XOR довольно жирненькая операция, при этом 3 SHR + 3 OR не намного больше 4 XOR
> Где я не прав?Автор в статье объяснил, что это небольшая жертва качеством сжатия ради производительности, а иначе там был бы обычный линейный проход по 64 последним значениям.
Для гнома/gtk уже есть плагин - qoi-pixbuf-loader, по идее все приложения которые открывают файлы через gtk должны работать и с QOI.https://copr.fedorainfracloud.org/coprs/vr5/gtk-pixbuf-loaders/
http://vr5.narod.ru/fedora/gtk-pixbuf-loaders/qoi-pixbuf-loa...
webp придуман для мусорных картинок?
будет ли это векторизироваться с SIMD. когда данные занимают 2, 4, 5 байт, без выравнивания.
А какая лицензия у этого формата?
MIT - к сожалению бздуноподобная пермиссивка. Надо автора убедить чтобы под лютый копилефт перелицензировал. Он ведь сделал конкретное "нужно".
Аффтор сделал как ему удобно, а не как собакам на сене хочется.
Алсо гнутая непермесивка не мешает облакам и даже микрософту с всл зарабатывать на гнутых.
Что там мешает, или не мешает Майкрософту нас не интересует. Важно чтобы лицензия была копилефтной и одобренной Столлманом. Это дело принципа!
> Что там мешает, или не мешает Майкрософту нас не интересует. Важно чтобы
> лицензия была копилефтной и одобренной Столлманом. Это дело принципа!Интересно, что там мешает анонимам сделать другую реализацию под более "правильной" лицензией, вместо нытья на форуме (о котором автор, скорее всего, ни разу не слышал)? Дело опеннетного принципа?
Шаблевский только, а не Саблевский
ждём шей-дыры для замены DXT5 )
Кстати, круто, что формат позволяет сохранять в файл, что RGBA-каналы находятся в линейном цветовом пространстве. Если кто не в курсе, почти любая обработка хорошо работает только с линейными цветами, т.к. они правильно смешиваются.
Я пытался строить консольные конвейеры обработки пару лет назад (т.е. каждый фильтр - отдельная консольная программа), но это приводило к тому, что надо было постоянно конвертировать из sRGB в линейный формат. Я там изобретал велосипед. Еще видел, есть текстовые форматы типа farbfeld, но это совсем уж извращения.В общем, если даже бегло пробежаться по исходникам и описанию, получается, что формат очень хорошо приспособлен для хранения промежуточного результата обработки. На нём можно строить вполне себе неплохие конвейеры. Даже несмотря на то, что формат восьмибитный, т.к. он убирает необходимость постоянных преобразований в sRGB и обратно, там должно быть минимальное падение точности с каждым шагом обработки.
Правда, начальное и конечное преобразование — уже довольно травматичная вещь, если сохранять результат в 8 бит.
Несложно адаптировать под любую битность канала. RGB565 тоже было бы прикольно иметь для микроконтроллеров всяких.
>Эталонная реализация QOI на языке Си насчитывает всего 300 строк кодаВот так надо. Учитесь господа!
НебезопасТно!
У раста слишком многобуквенный синтаксис, так что в такой объём кода не уложиться.
> НебезопасТно!Не используй сжатие картинок на компе управляющем ядерным реактором.
проверил ради интереса в андроид java.
с битмапа байты и обратно.
изображение 4400х3200 (похожих пикселей почти нет) - повреждение пикселей по верхнему краю и дольше чем png цикл.
