Компания Google представила новую открытую библиотеку jpegli с реализацией кодировщика и декодировщика изображений в формате JPEG. Библиотека включает дополнительные оптимизации для повышения эффективности кодирования, позволяющие на 35% увеличить степень сжатия высококачественных изображений, по сравнению с традиционными кодеками JPEG. В сравнении с libjpeg-turbo библиотека jpegli позволяет добиться аналогичного уровня качества при снижении битрейта на 32%. На уровне API и ABI библиотека полностью совместима с libjpeg62 и может применяться для её прозрачной замены. Код библиотеки написан на языке С++ и распространяется под лицензией BSD...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60921
Ни webp, ни avif, ни jpeg-xl до сих пор не зашли... Удивительно, почему сразу не могли улучшать обычный jpeg, с обратной совместимостью?
Так потому и улучшают что альтернативно одарённые навязать не удаётся .
> Так потому и улучшают что альтернативно одарённые навязать не удаётся .Софт порой инерционен с поддержкой. Попробуйте анимированый webp вообще открыть чем?! Кроме хрома/файрфокса, конечно. И как, получается? Даже с анимацией? И всех версий webp? А чтоб еще и отредактировать анимаху и разобрать на фреймы - слабо?! Не, это даже ffmpeg не сожрет с его более 9000 форматов. Вот скроить это может - но билет в одну сторону! А потом это только в хроме и лисе и смотреть. И все, по сути. Write-only формат. Оказывается так можно было.
В telegram же, ну
это та социалочка, которая хранит переписку в открытом виде?
Сможешь прочитать мою переписку, раз она в открытом виде?
паша сможет и фсб. тебе мало?
В телеграмме ты сам можешь управлять уровнем приватности. Можешь пользоваться обычными чатами и иметь связанные с этим бонусы в виде сохранения истории, нормальной синхронизации между устройствами, возможности докачивания вложений и прочего.Или можешь пользоваться секретными чатами. Протокол открыт, клиенты опенсорсны. Был публичный конкурс с предложением его взломать с большими призовыми. Никто, вроде, приз так и не взял.
>Протокол открытможет, скажем ему?...
Протокол открыт и это факт. Мне как-то коллега по работе уши прожужжал о его безопасности. Протокол то хорош, но большинство людей не настолько умны чтобы его использовать.
Более того, вы уверены что прям ФСБ работает с телеграм? Я думаю это все слухи, потому что он не контролируется американскими силовыми ведомствами. Но помнится в скором времени владелец там что-то про IPO говорил, вот тогда его и возьмут за финансовые жабры. И судя по вашей логике ответов, вот тогда он станет демократичным и пригодным для использования. Какие же это двойные стандарты!
> Протокол открыт и это факт. Мне как-то коллега по работе уши прожужжал
> о его безопасности. Протокол то хорош, но большинство людей не настолько
> умны чтобы его использовать.Протокол никак не помогает - юзеров данонят кореляцией тележного ID <-> номер телефона и пробитием далее телефона по утекшам базам. И вот чем вам поможет хоть какой протокол от этого, если факап - в той логике?
Для майоров есть даже комплекс автоматизирующий это, недавно как раз засветился в закупках, но такой уровень атаки - даже и васян сможет, если захочет. Большая часть юзерей забывает скрыть номер телефона - за что и огребает сполна, наслушавшись булшита про "безопасный месенжер" - и сев на десяток лет и более.
Если пользователь, живя в тоталитарном государстве, желает выражать своё мнение, но не желает заботиться о конспирации — ССЗБ.
> Если пользователь, живя в тоталитарном государстве, желает выражать своё мнение, но не
> желает заботиться о конспирации — ССЗБ.Отлично, а зачем ему тогда безопасность обещают? Чтобы увеличить число залетчиков? Какие хорошие, белые и пушистые господа. И совсем не провокаторы даже.
А ещё не предупреждали, что кошку в микроволновке сушить нельзя!
> А ещё не предупреждали, что кошку в микроволновке сушить нельзя!Можете юродствовать сколько угодно - а я взамен буду считать что...
1) Высокие напряжения и интенсивные излучения - представляют неиллюзорную опасность и лучше с ними не связываться без острой на то нужды лишний раз. Иначе можно влегкую помереть или покалечиться.
2) Те кто обещает безопасность юзерам но не обеспечивает ее - в ответе за такую подставу и де факто что-то типа провокаторов.
Впрочем, как обычно, началось передёргивание. Кого-то сажали не за посты, а ЗА ПЕРЕПИСКУ?
> Впрочем, как обычно, началось передёргивание. Кого-то сажали не за посты, а ЗА ПЕРЕПИСКУ?Легко. Примеры можно найти - вот прямо в той же телеге. Вооооон там господа прям с фоточками и скриншотиками показывают отловленных экземплярчиков - и что именно им инкриминируется. А чо, удобно же, подгрузка истории и все такое... осталось еще автоматические скриншоты запилить - и отсылку на товарищмайорский канал, чего майоры на кучу кликов время то тратят?! Уже б генералами были давно.
> В телеграмме ты сам можешь управлять уровнем приватности. Можешь пользоваться Телеграмом, а можешь - не пользоваться. А если нет опции жить и не польжоваться - то можешь и не жить.Пофиксил.
> В телеграмме ты сам можешь управлять уровнем приватности. Можешь пользоваться обычными
> чатами и иметь связанные с этим бонусы в виде сохранения истории,
> нормальной синхронизации между устройствами, возможности докачивания вложений и прочего.Судя по количеству посаженных телеграмеров - с телеграмом ты можешь сам сесть на десять лет. Влегкую. А управление приватностью там в основном путем засовывания языка в ... и сидения тихо, судя по тому как телеграмеров пакуют в РАЗНЫХ юрисдикциях. Тенденция однако.
> Или можешь пользоваться секретными чатами. Протокол открыт, клиенты опенсорсны.
> Был публичный конкурс с предложением его взломать с большими призовыми. Никто, вроде,
> приз так и не взял.А оно на практике нахрен не надо. Майор просто радостно загрузит историю. Не с девайса, так с сервера самодурова на соседнем девайсе. Синхра девайсов. Удобно же!
— покупаем симку у опсоса, подконтрольного майору;
— регистрируемся с этим номером в мессенджере;
— получаем срок за пост… кто виноват? ну конечно, мессенджер.
> — покупаем симку у опсоса, подконтрольного майору;
> — регистрируемся с этим номером в мессенджере;
> — получаем срок за пост… кто виноват? ну конечно, мессенджер.Внезапно, да. Он это все затребовал от своих юзерей. Это он создал эту кореляцию. Он ее хранил. И же и слил ЭТО всем посторонним рожам, оптом, по дефолту! Так что - виноват. По полной программе. Эталонное создание юзерям подстав.
С таким же успехом - можно говорить что если вас размотало на мине на дорожке, виноваты - вы, потому что пошли гулять без миноискателя. А могли бы обучиться саперному делу и убрать ее с дорожки, "как нормальный человев". Что за лох такой - без миноискателя и саперного костюма?!
Если вас размотало на минном поле — да, сами виноваты.
> Если вас размотало на минном поле — да, сами виноваты.Так паша самодуров из каждого рупора орал что все проверено, все безопасно, навесил табличку - мин нет. А виноват после этого пользователь. Логично, чо.
Ага, Паша так взял и дал ФСБ доступ, он не просто так отсюда уехал после истории с ВКонтакте. ФСБ последние кто сможет получить доступ к переписка телеграмма.
> Ага, Паша так взял и дал ФСБ доступ, он не просто так
> отсюда уехал после истории с ВКонтакте. ФСБ последние кто сможет получить
> доступ к переписка телеграмма.Это совершенно не помешало им провести закупки комплекса по данону телеграмеров - который маппит тележный ID в номер телефона ибо по дефолту это вывешено всей толпе, и нагрести эти данные оптом не вопрос. А потом они по утекшим у операторов сотовым базам - всей толпой лукапают без всяких глупых запросов операторам что сие за тушки. Удобно однако!
Вот вам и вся безопасность от паши самодурова. Все что о ней надо было знать. А ФСБ что, если оно вас за жабры возьмет, тут вот как раз история с сервака и подгрузитяс очень кстати. А после небольшого массажа почек - и всему отделу засинхронизируется.
> паша сможет и фсбИ что за проблема? Шифруешь текстовый файлик openssl'ем и отправляешь файлом, или шифруешь сообщение, тут же кодируешь его в base64 и отправляешь как текст.
Собеседник должен уметь в openssl? Ну дык, либо ты играешь в эти игры, и тогда ты играешь всерьёз, в том числе выбирая корреспондентов, с которыми можно вести тайные дела, либо не играешь вообще.
> В telegram же, нуА что, он таки умеет анимаху на фреймы разбирать? Или что с ней там делать предлагается? Пойнт в том что после конверсии в этот формат - вы вообще ничего дальше с этим сделать особо уже не сможете. А постить ее можно и вебе.
> разобрать на фреймы - слабо?! Не, это даже ffmpeg не сожретImagemagick может.
> If you have an old version of imagemagick the command is convert instead of magickhttps://superuser.com/questions/1688850/how-do-i-convert-ani...
А потом я собираю фреймы в mp4 через ffmpeg. Получается скрипт по перекодированию анимированного webp в mp4.
Схема конечно муторнее, чем обычная ffmpeg команда перекодирования gif в mp4, но если надо, то сделать можно.
> Попробуйте анимированый webp вообще открыть чем?!Viewnior (gtk2) и Loupe (gtk4) анимированный WEBP открывают, как минимум, уже года два.
>> Попробуйте анимированый webp вообще открыть чем?!
> Viewnior (gtk2) и Loupe (gtk4) анимированный WEBP открывают, как минимум, уже года два.Зашибись! Целые 2 года - 2 программы про которые я впервые слышу. Чисто посмотреть. А сколько лет этому формату, не напомните? Я уже со счета сбился.
...но отредактировать то эту байду по человечески, с нормальным workflow вы не сможете, и даже просто конвертнуть в что-то другое придется еще поплясать. Воооон там какой-то креативщик с imagemagic'ом и потом ffmpeg'ом. Вот такое вот хреновое лето^W конверсие в мувик получается. Уровень поддержки формата в софте!
И с каким-нибудь Jpeg XL врядли сильно лучше. А с хрена ли?
> Зашибись! Целые 2 года - 2 программы про которые я впервые слышу. Чисто посмотреть.IrfanView (извините, что я с оффтопиком, да?) уже шесть лет умеет.
>> Зашибись! Целые 2 года - 2 программы про которые я впервые слышу. Чисто посмотреть.
> IrfanView (извините, что я с оффтопиком, да?) уже шесть лет умеет.И там прямо анимации, v2 формата и проч норм работает во всех комбо? Но посмотреть то можно и в браузере накрайняк. А вот разобрать допустим на фреймы или в другой формат это переделать... ээээ... :))
Ещё я для такой мелочёвки софт искать буду. Давным-давно это через ezgif делается.
> А сколько лет этому формату, не напомните?Не интересовался. Но когда столкнулся с изображениями этого формата, мне было их чем открыть.
> отредактировать
Там imagmagick уже предлагали.
Потому что сначала надо было придумать эти avif webp jpeg XL что бы брать от туда технологии, которые можно применить в jpeg
Точно так же как с AQ-3 из HEVC в AVC
Или та же технология butteraugli придуманная для jpeg XL и далее используемая в другом гугл jpeg кодировщике guetzli
Фичи можно было изначально для джпега разрабатывать , без прокладок и памперсов .
> без прокладок и памперсовА как ты тогда тут комментить будешь?
> Точно так же как с AQ-3 из HEVC в AVCМожно подробнее? В интернете мало инфы.
инфы нет вообще, только документация и сами кодеки x264 x265 с всвроенными инструкциями. (в интернете реально просто не существует описания некоторыех параметров кодеков, например Deadzone в x264. Единственное описание на какой то мёртвой вики, на которую ссылается весь интернет, это дизинформация.. такие дела, тыкай сам.)
AQ-3 в AVC позволяет кодировать тёмные гардиенты (в темноте) без артефактов блочности
> в интернете реально просто не существует описания некоторыех параметров кодеков, например Deadzone в x264Да ну, про него говорят, но только с высоты двадцати лет кодекостроения и двадцати лет квантования DCT-коэффициентов, для тех, кто знает всю предысторию. Как для непосвящённого, параметр вроде означает "не лезь, оно тебя сожрёт".
В целом: "deadzone quantizer ... [какие-то нехорошие слова, дублирующие картинку]. It has the benefit during compression of ensuring that noisy low-level signals are not allocated bits unnecessarily" - https://www.sciencedirect.com/topics/engineering/quantizer
Разговор о том, как его отменяют другие параметры. По крайней мере, один параметр. По крайней мере, в 2006-2007:
https://forum.doom9.org/showthread.php?p=883221#post883221
https://forum.doom9.org/showthread.php?p=1072878#post1072878
http://akuvian.org/src/x264/overview_x264_v8_5.pdfСудя и по этому, --trellis 1 (пресет <=faster) или 2 (пресет <=slow) заменяет deadzone quantizer с его настройками (--deadzone-inter --deadzone-intra), поэтому ими не стоит забивать голову.
Короче, алгоритм уменьшает коэффициенты, мыля картинку. Я это к чему говорю, в 2024 году можно обойтись без него, deadzone-inter=0 deadzone-intra=0 trellis=0
заместо этого алгоритма,
Используем пре-фильтр hqdn3d=luma_spatial=1:chroma_spatial=1:chroma_tmp=3:luma_tmp=3
либо намного более сложный nlmeans=3:7:7:5:5
параметры какие хочешь... к чему я это.
На тестах которые я проводил. AVC на разрешениях ниже чем 720p и при идентичном качестве картинки, работает быстрее и эффективнее чем HEVC, без проблем распараеливаясь на 12+ потоков (суммарно при 100%). Такие дела. (разрешения выше 720p не пригодны для avc. HEVC AV1 там это всё.)
AVC абсолютно на любом разрешении и любых параметрах дно, не спорь. Во всяком случае, я могу утверждать это про x264. А вот x265 терпимо и на sd и на hd+. Но там это, новый босс качалки пришёл, h266 лишён буквально всех недостатков недокодеков вроде vp9/av1 и совершенно идеален.>без проблем распараеливаясь
не без проблем, если ты кодируешь avc больше чем в ~4 потока на fullhd качество кодирования улетает в пол.
> AVC абсолютно на любом разрешении и любых параметрах дно, не спорь. Во
> всяком случае, я могу утверждать это про x264. А вот x265
> терпимо и на sd и на hd+. Но там это, новый
> босс качалки пришёл, h266 лишён буквально всех недостатков недокодеков вроде vp9/av1
> и совершенно идеален.А, вот почему ISO так судорожно кодеки строгает? А чего у вашего босса поджилки трясутся и из носа сопля свисает? Неужто получше никого не нашли?! И вот это чмище теперь попробует устроить патентный рэкет всему раёну? :)
Так реально vvc даёт совершенно минимальный битрейт (и не раздувает его на пустом месте как vp9/av1, толку от качества, если битрейт улетает в небеса, а без битрейта сыпет жуткими глитчами), не размывает картинку так сильно (av1 даже на медленнейшем качестве и неограниченном битрейте более мыльный, чем быстрый vvc), лучше держит края. И то, что av1 противопоставляют в лучшем случае hevc (а чаще всего avc) достаточно показательно. Победитель уже известен.
> Так реально vvc даёт совершенно минимальный битрейт (и не раздувает его на
> пустом месте как vp9/av1,Это все - абстрактные блабла. И вот что-что а AV1 в раздувании битрейта я бы уж точно не обвинил, а svt-av1 лично мне так очень понравился.
Да и VP9 субъективно - где-то на уровне x265 по битрейт-качество. При том что в массы пошел раньше. Одна из причин по которым H.265 непонятное бессмысленное УГ, с более плохими условиями использования, недопилеными реализациями, злыми условиями лицензинга, а с пришествием 266 это заодно еще - кидок тех кто все же развелся и заплатил, вынести лохов в obsolete с такой скоростью это круто придумано! А теперь их попытаются отрекетировать еще раз, объяснив что надо доплатить? Удачи! Думаю они будут в восторге, а у AOM чего может прибавиться участников :). Так можно дожать до этого даже и броадкомы с квалкомами пожалуй.
> толку от качества, если битрейт улетает в небеса,
У лично меня в AV1 и VP9 ничего никуда не улетает. Если вы не смогли в параметры кодирования - это не их баг.
> а без битрейта сыпет жуткими глитчами), не размывает картинку так
> сильно (av1 даже на медленнейшем качестве и неограниченном битрейте более мыльный,Красивые сказки. Только вот у меня свое мнение о фраунхофере и софте который они изрыгают. Эти господа хотят много денег - и мало делать. Зачем они вообще с такими соотношениями нужны я не понимаю.
Для сравнения AOM создал - целую экосистему next gen. Когда даже хардварный декодер можно получить на довольно халявных условиях. И генерится это все - прямо из сорцов libaom, через high-level synthesis. Попробуйте с фраунхофера и прочих жуликов такое получить?! В AOM и вписались интел/амд/нвидия/арм и куча имен помельче. И теперь вот это все будет - практически во всех новых разработках. А вон те что предложут? А, рэкет за очередную пулю из непонятного материала, с почетным правом сделать ловомой объем самим? А оно точно в таком виде надо? :)
> чем быстрый vvc), лучше держит края. И то, что av1 противопоставляют
> в лучшем случае hevc (а чаще всего avc) достаточно показательно. Победитель
> уже известен.HEVC едва-едва рубается с древним VP9, примерно на равных. Куды этой пакости до AV1, у него половины эффективных тулсов уменьшения битрейта на уровне формата потока нет. Отсталый прямо на момент дизайна формат. Потому исо и страгает новые в истеричном темпе, контроль над ситуацией утекает из их кривых лапок.
Это всё хорошо, но hevc абсолютно повсюду уже 12 лет. Это вечность. И никуда уходить не собирается, это до сих пор единственный вариант для качественного контента до повсеместного распространения декодеров h266 ещё несколько лет пройдёт. А ты, наверное, хотел как с mpeg2? Так он лет 10 использовался, bd заменил dvd и до-свидания.
Но это ведь не замена, это фильтры для удаления такого-то шума в таких-то исходниках. Плюс решение не тюнить качество/размер_файла до посинения.Хз, должен ли deadzone с его обнулением коэффициентов бить именно по высоким частотам. Trellis должен, но против этого предлагается тюнить psy-rd'ы.
Как фанаты этого дела выбирают под себя глубину крольчьей норы?.. Субъективная оптимизация* упирается в человеческие возможности - человека хватит на отсматривание нескольких десятков наборов настроек. Объективная оптимизация по хорошей метрике вроде VMAF или SSIMULACRA2 упирается в несовершенство метрики, да и крутят на практике только один параметр: crf или qp для отрезка видео[1][2]. Что как бы намекает на рецепт хорошего качества - перейти на самый новый кодек (независимо от разрешения), а с его тормознутостью будет уже не до тестирования кучи настроек.
> без проблем распараеливаясь на 12+ потоков
А если x265 с проблемами, то можно пойти по пути гуглокодеков - смириться с плохим распараллеливанием на уровне энкодера и запускать их одновременно, скармливая им по куску из видео (заранее разрезать на сцены) (всё это кое-как автоматизировали в av1an).
* оптимизация в математическом смысле - как максимизация функции типа визуальное_качество(настройка_1, настройка_2, ...)
[1] https://netflixtechblog.com/dynamic-optimizer-a-perceptual-v...
[2] https://github.com/alexheretic/ab-av1
> А если x265 с проблемами, то можно пойти по пути гуглокодеков -
> смириться с плохим распараллеливанием на уровне энкодера и запускать их одновременно,
> скармливая им по куску из видео (заранее разрезать на сцены) (всё
> это кое-как автоматизировали в av1an).На самом базовом уровне проблема примерно такая: анализ глобальной избыточности и еще ряд оптимизаций представления проседает от нарезки на тайлы. И чем больше тайлов тем хуже потери. На жирном контенте несколько тайлов которые жуются независимо сильной погоды не делают, но некие лимиты есть.
В случае h265 это впрочем не особая проблема - у этого крапа вообще нет толком глобальной коспенсации движения, CDEF и прочих продвинутостей - нельзя потерять то что у него никогда и не было. Однако при убогом формате потока еще и дополнительно нагнуть оптимизации кодирования спорное занятие.
> На жирном контенте несколько тайлов которые жуются независимо сильной погоды не делают, но некие лимиты есть.Но я не про тайлы (независимые части кадра для распараллеливания), а про "чанки", про видео, нарезанное по некоторым кадрам - по некоторым переходам между сценами. Если целиться на определённое качество, а не определённый битрейт, то особых проблем быть не должно. Может, есть смысл в гипотетической конструкции типа "2-й проход - параллельно по чанкам, 1-й - по всему видео, файл со статистикой как-то разрезать", но до такого никто не доходил.
> Однако при убогом формате потока еще и дополнительно нагнуть...
Я понимаю, что твоя вера сильна, но этот приём принят при кодировании не в H.265, а в гуглокодеках, из-за того, что они плохо параллелятся.
а разве только гугл причастна к разработке всех перечисленных вами форматов?
Почему сразу перешли на полупроводники, а не улучшали электронные лампы с обратной совместимостью?
Почему не взлетело — потому что не нужно уже. JPEG без цветовой субдискретизации и так покрывает 99% потребностей, а времена, когда размер картинок был так уж важен, прошли.
Впрочем, насчёт WEBP это зря. Его как раз гугл пропихнул.
"времена, когда размер картинок был так уж важен, прошли"
Я что-то пропустил, или хранение данных резко подешевело?
Да, подешевело.
Не так резко как хотелось бы, но с 2017 года примерно в 2 раза.
С 3 центов на гиг, до примерно 1.5В 2005 average cost per gigabyte было 65 центов, а в 2000 вообще за гиг приходилось отдавать 12 баксов)
С другой стороны кол-во мегапикселей, телефонов с камерами и фотографий "я и моя сарная кошка" увеличилось, причем думаю не пропорцианально)
Соцсеточки всё равно пережмут всё в хлам и уменьшат до пары мегапикселей.
Причем тут хранение, проблема в объемах передаваемых данных. А изображения, помимо огромного куска js кода, которая грузится в сингле пэдж аппликатион, одно из основных объемов по трафику.
Вы из какого года пишете? Основной объём трафика — это видео. Ну так о его ужатии как раз постоянно беспокоятся.
Как раз те, кто хранит гигантские объёмы контента (те же соцсети, например), от жпега отказываться не особо что-то спешат.
WEBP умеет в сжатие без потерь (lossless) и на этом поле обыгрывает популярный PNG на 20-30%.
> WEBP умеет в сжатие без потерь (lossless) и на этом поле обыгрывает
> популярный PNG на 20-30%.Не забыв при этом угробить цвета в скриншотах в хламину. Такой себе lossless, с subsampling'ом то.
lossless WebP это по сути отдельный кодек, в нём нет chroma subsampling, он не YUV, он RGBA.Но у него та же проблема, что и у lossy WebP - если уж слезать с jpg/png, то на jxl.
> lossless WebP это по сути отдельный кодек, в нём нет chroma subsampling,
> он не YUV, он RGBA.Изначально в первой версии это таки тупо I-frame от VP8. И тот чисто технически ничего кроме YUV с subsampling не умел. В версии 2 вроде попустило, но ее поддержка софтом - в еще большей ж... чем первой версии.
> Но у него та же проблема, что и у lossy WebP - если уж слезать с jpg/png, то на jxl.
PNG вообще не замена JPG и насколько JXL хорошо дружит с line art и способен в его lossless представление с минимальным размером и без артефактов - это мы еще будем посмотреть.
Всё-таки первый WebP умеет в RGB+lossless и этот режим прикручен отдельно как раз потому что с I-фреймом от VP8 так бы не получилось. Про lossless-режим в первом WebP говорили за 10 лет до WebP2:
https://blog.chromium.org/2011/11/lossless-and-transparency-...> PNG вообще не замена JPG и насколько JXL хорошо дружит с line
> art и способен в его lossless представление с минимальным размером и
> без артефактов - это мы еще будем посмотреть.Но к чему это? Вот сравнимые кодеки:
JPG => lossy WebP => lossy JXL
PNG => lossless WebP => lossless JXLLossless-представление с артефактами - всё-таки оксюморон.
Знаю несколько сайтов, где выкладывали HD-фотки в обычном jpeg, а потом стали конвертить их в webp, качество стало заметно хуже. Не знаю, какой в этом смысл, фотки занимают не так много места, а webp портит качество.
Скилл ишью. webp жмет по качеству не хуже чем jpeg с таким же параметром качества. Видимо его выкрутили пониже, чтобы жать сильнее, от сайта с hd-фотками в jpeg другого не стоит ожидать.
Вебп цвета прореживает.
У WebP есть много опций сжатия, на которые большинство забивают, ограничиваясь одной цифрой "качества", которая работает совсем не как у jpeg.
> У WebP есть много опций сжатия, на которые большинство забивают, ограничиваясь одной
> цифрой "качества", которая работает совсем не как у jpeg.Примерно так же на самом деле. Ну, для хорошего результата я использую image-hint=picture alpha-filtering=2 alpha-quality=100 partition-limit=0 use-sharp-yuv=1
А вот pass=10 с target-psnr дают результат ощутимо хуже. В особенности, плохое качество получается без use-sharp-yuv, но, если тип контента не угадает, тоже может быть очень плохо
Только вебп не лучше жпег. Лестницы на градиентах, опять же (пожалуй, единственное, что лучше в av1 по сравнению с vp8/vp9).
Так жмёт-то он из JPEG. Любой супер-пупер лосси алгоритм на каждом шаге что-то да теряет.
> а потом стали конвертить их в webp, качество стало заметно хужепотому что дважды пережато
> фотки занимают не так много места
у тебя. а у них это сохранение денег на хранении и получении доступа к терабайтам данных
> webp портит качествоЛюбое lossy-кодирование портит качество, включая JPEG. Пережимать лося в лося -- глупость. Нужно кодировать с одного RAW-источника в JPEG и WEBP, а затем сравнивать. Или не трогать лосей от греха. Не ходите на такие сайты, не пользуйтесь услугами идиотов, до добра это не доводит.
Например, jpegxl убирает артефакты кодирования jpeg в режиме с потерями и делает картинку визуально чище и приятнее. Понятно, что из q60 скажем q95 уже не получится, но, если исходник больше q95, то иногда вполне применимо, судя по моему опыту. Лично я предпочитаю перепаковывать jpeg в jpegxl, как есть, без сжатия -- это быстрая операция, и позволяет сэкономить ~20-99.9%. А jpeg даже с качеством 100 уже слишком убитый файл, чтобы корёжить его дальше. Но если тебя не уважают и предоставили только файлы с потерями, то тут ничего не поделать.
Кстати, если сравнивать jpegxl в режиме без потерь с типичным png, то, приняв размер файла png за 1, у jpegxl он будет 0.4 в среднем, и, кроме того он по-настоящему без потерь и не потеряет аттрибуты и экзотические цветовые пространства (png всё потеряет, да). Я не понимаю, какие конченные извращуги пропихнули avif в веб вместо него и кто им позволил -- он не конкурент даже webp.
Вы со своими файлами работаете, на свой страх и риск, вам и карты в руки. А там чужие пачками портят, не глядя.
Ну-ну, сравни сжатую мангу в "webp-архиве" с остальными
webp вполне себе зашел. Как минимум в тырнете его довольно прилично.
webp прекрасно зашли
я правильно понимаю что эта технология сугубо для веба? или она всётаки в ближайшие полгода перекочует в графические проги?
Картинкам надо откуда то браться - появится и в прогах .
А в поисковой системе Гугл нет картинок? Предполагаю что они это делали сугубо для себя, для экономии места под информацию. Может потому и поделились, чтоб себе любимым упростить работу с сайтами.
Во всех зеркалках и простых мыльницах используется JPEG, теперь есть возможность заменить
Кто-то покупает зеркалки, чтобы фотографировать в JPEG?
А мыльницы фактически вымерли, остались игрушки, там никому не надо заменять JPEG на что-то эффективное.
> Кто-то покупает зеркалки, чтобы фотографировать в JPEG?Конечно, быстрый предпросмотр ещё никому не мешал. А RAW будет долго распаковывать и жрать аккум, что критично для фотика. Не таскать же за собой диз.станцию )))
+ Зеркалки могут снимать видосики в MJPEG
Для быстрого предпросмотра на трёхдюймовом экранчике в один мегапиксель эти нюансы пережатия совершенно несущественны.
Не на трехдюймовом, а на нормальном мониторе. Потому что, пока 20-и мегапиксельный файл на четыре 16-битных канала загрузится, пока из оригинального формата сгенерится тривосьмибитовый RGB для подачи в видеокарту, пройдет куча времени, а мы желаем листать отснятое без ощущаемых задержек в каталогах ФС с сотнями и более фото. Лично я могу с двухчасовой прогулки с детьми принести сотни три фото, которые нужно быстро просмотреть и существенно проредить¸ оставив дюжину, максимум полторы. Вот как раз для этого в RAW'ах (которые есть IFF) содержится чанк с джейпегом.
Для быстрого предпросмотра в RAW кодируют урезанный вариант в JPEG, thumbnail называется
Просто праздник какой-то.
> В частности, в jpegli задействован адаптивная эвристика квантования, используемая проектом JPEG XL…Только что Гугл пищал, что там ничего интересного и вообще не нужно.
там же жпег2000 был и многие, очень многие решили форкаться...
Он был максимально проприетарным, емнип.
Кто нибудь уже смотрел код? Интересно за счет чего бустится производительность, неужто SIMD используют?
SIMD не позволяет увеличить эффективность сжатия, он только скорость сжатия увеличивает
Как знал, не переходил на libjpeg8 с libjpeg62! Сейчас заменю libjpeg62 на jpegli. Надеюсь, для сборки не потребуется какой-нибудь meson и llvm?Upd: уже глянул - cmake и clang-7 или новее. Норм, на apt.llvm.org есть готовая сборка LLVM 7 даже для Debian 7. Так что проблем со сборкой не возникнет.
Мань, сабж на плюсах написан. И ты каждый раз бежишь внедрять все сырые поделки корп? Тот же guetzli оказался весьма дорого и крайне не без потерь, libjpeg-turbo хотя бы предсказуема. А что касается jpegxl, то я очень доволен. Кроме того случая, когда все прошлые файлы внезапно оказались битыми (декодируются с зелёными артефактами местами) для всех новых версий библиотеки, совместимость-с.
> И ты каждый раз бежишь внедрять все сырые поделки корпЯ делаю домашние сборки некоторого ПО. Вот пример такой сборки:
https://github.com/OpenXRay/xray-16/files/14234005/S.T.A.L.K...
Свои сборки линкую с libpng12 и libjpeg62. Я выбрал их для совместимости: эти версии библиотек у всех есть (в отличие от libpng15, который сегодня заменили на libpng16, а завтра заменят на libpng17).
Однако хочется же с libjpeg8 слинковаться? Чтобы софтина работала быстрее. Но вдруг у юзера нет этой библиотеки? Я понимаю что "стандарт де-факто", но вдруг завтра поломают ABI и выпустят libjpeg9? Такое уже было с libjpeg7.
Поэтому я сейчас положу в архив с моей сборкой - сабж. Он такой же быстрый, как libjpeg8, но при этом имеет прежний ABI libjpeg62.
У плюсов перечень забавных приколов с аби и библиотекой раскрутки стека, это ещё если исключения не используются, такая библиотека менее универсальна и переносима. Зачем тебе чтобы софтина работала быстрее, ценой замены аутентичного компонента на непонятно что с непонятно какими непредсказуемыми последствиями? Наоборот, стоит бороться за сохранение и презервацию аутентичного кода для будущих поколений и тут чем меньше васянства и отклонений от оригинала, тем лучше.
>libpng15, который сегодня заменили на libpng16Очнись! Твое "сегодня" - это сентябрь 2017 года.
В RHEL всё ещё libpng15
Потому что все остальные версии либы насквозь протроянены похуже xz.
> Потому что все остальные версии либы насквозь протроянены похуже xz.Не, потому что последний RHEL релизнулся хрен знает когда. Я тут загуглил - оказывается, 9-й уже вышел... Я не знал.
Тогда в актуальном RHEL уже libpng16. Извиняюсь, был не прав.
Зенитурушка ты что все старые пакеты всех RPM дистрибутивов у себя хранишь? Их же наверное уже не существует.
Зато существуют у него, у Вас от этого убыло что ли?
> Зенитурушка ты что все старые пакеты всех RPM дистрибутивов у себя хранишь?
> Их же наверное уже не существует.Пусть качнет, чтоли, archive.debian.org себе. Если получится, сможет mirror'ом подрабатывать.
> Зенитурушка ты что все старые пакеты всех RPM дистрибутивов у себя хранишь?
> Их же наверное уже не существует.От CentOS я нашёл архивные зеркала + RPMFusion. От SLES 11 бэкапил, но пока что бэкап не понадобился: в интернете всё ещё есть пакеты.
А в чем проблема с llvm?
Обычно я осуществляю сборку в старых дистрах, чтобы бинарник запускался в широком диапазоне Linux-систем, выпущенных за последние 10-15 лет.А вот как собрать LLVM из исходников, мне неведомо. С GCC всё просто:
tar xf gcc-4.8.5.tar.bz2
cd gcc-4.8.5
mkdir build2
cd build2
../configure --prefix=/home/username/gcc-4.8 --enable-languages=c,c++
make -j7 // кол-во физических ядер +1
make install
export PATH=/home/username/gcc-4.8/bin:$PATH
export LD_LIBRARY_PATH=/home/username/gcc-4.8/lib:$LD_LIBRARY_PATH
gcc --versionЕдинственный минус такого GCC - бинарники, собранные таким компилятором, зависят от слишком новой libstd - новее, чем та, которая в /usr/lib. Как починить - не знаю! Наверное, надо смотреть devtoolset, там libstdc++.so заменён на какой-то текстовый файл - мне кажется, что разгадка скрыта где-то тут.
А вот с LLVM непонятно... В Debian DEB-SRC-пакет, который состоит из... шести архивов с исходниками... Их просто последовательно распаковать, или что? А собирать потом как? Дело в том, что идущий в комплекте debian/rules хрен распарсишь. Там ещё и stage-ы! Вот бы инструкцию - тогда бы я собрал любую версию LLVM, которая мне нужна. Чтобы просто в папке лежала, как вон выше пример с GCC...
Плюс ко всему, когда я собирал пакет LLVM 7 под Debian 7, я столкнулся с ошибкой, описанной тут:
https://www.linux.org.ru/forum/development/15941285
У автора треда Debian 10, но суть та же. Причём 64-битная сборка собралась без проблем! Ошибка только при сборке 32-битной сборки!
Хорошо что на сайте apt.llvm.org есть готовые пакеты с LLVM 7, и я смог установить их в 32-битную версию ОС Debian 7. А что если у меня не Debian, а что-то другое? Или Debian 6, например?
Ну и ещё при сборке Mesa 19.0.8 (последняя версия без Meson) возникла ошибка при сборке MesaOpenCL. Такая же ошибка возникла при сборке Beignet 1.3.2. Оказалось, что в binutils 2.26 прокралась регрессия, из-за которой LLVM генерирует неправильный код! Регрессию поправили в binutils 2.31.
А у меня в Debian 8 из коробки был binutils 2.25, который не был подвержен регрессии. Я зачем-то обновил binutils до более новой версии. А потом я потратил недели, чтобы понять, почему же я не могу собрать месу? Ведь предыдущая 18.3.6 собиралась без проблем... Ответ нашёлся, когда я попробовал пересобрать уже собранную у меня Mesa 18.3.6, и когда она не собралась, я понял, что я что-то запорол в своей системе - причём недавно. А значит, надо смотреть, какие пакеты я устанавливал в систему последними...
Когда арифметическое кодирование?
> Когда арифметическое кодирование?a) Патенты истекли лет 15 назад, но уже никогда - решили, что распространение таких jpeg'ов вредно из-за несовместимости со старым софтом.
b) У себя лично можно давно использовать - пропустить файлы через jpegtran -arithmetic, это lossless-операция.
c) А для распространения... Проблема из (a) решается сменой формата файла, чтобы арифметический жипег не выглядел обычным жипегом, но тогда и арифметического кодирования придерживаться не обязательно. Перепаковщиков жипега, работающих таким образом, много: ...jojpeg, packJPG, brunsli, lepton, JPEG-XL.
Lossless-перепаковка jpeg'ов - одна из фич JPEG-XL, ему бы ещё поддержку в браузерах.
С сегодняшними скоростями Интернет можно PNG использовать и не париться.
использовать можно, не париться не получится - гугль еще не написал для него "более эффективного кодировщика" (и, главное - декодировщика). А референсный - тот еще тормоз (и никогда, разумеется, не будет сопоставим с жпегом со своими вейвлетами и прочей заумью)
Не знаю, при чём тут вейвлеты из старых жипегостандартов, но png ещё можно ускорить распараллеливанием: https://github.com/w3c/PNG-spec/issues/54
Можно, но нельзя (потому что это w3c, они не умеют кодить)Ждите пока гугель захочет в png (а он не захочет).
Там про декодирование, оно проблемой не является. «This would significantly reduce the wall-clock time involved in reading large (8k-32k) PNG files on modern machines» — прямо очень частый кейс, да.
Тем не менее, Apple такое реализовала. Картинки чаще просматривают, чем сжимают. Причём сжимать обычно нужно много за раз (и однопоточность не мешает), а просматриваются они по одной штуке. Ещё декодирование проблемнее, потому что только для него нужны новые стандартные метаданные.Глядишь, для сканов пригодится. Или нет. Сначала надо убедиться, что скорость fpng и wuffs PNG недостаточна: https://github.com/nigeltao/qoir/blob/main/doc/full_benchmar...
Да пусть реализуют, спору нет. Просто 99,9% пользователей этого не заметит даже.
> использовать можно, не париться не получится - гугль еще не написал для
> него "более эффективного кодировщика" (и, главное - декодировщика). А референсный -
> тот еще тормоз (и никогда, разумеется, не будет сопоставим с жпегом
> со своими вейвлетами и прочей заумью)Они вообще разные. JPEG для фоточек, PNG для скриншотов, доков, схем, чертежей и проч - с контрастными четкими линиями, фонтами и проч.
Хранить фоту в PNG - можно, но это ж zlib с префильтрами. Сильно такое не ужмет. Зато line art и прочие скриншоты - вполне. При том lossless by design. Можно 20 раз редактировать и не париться. Это чуть более продвинутый вариант .bmp.gz - всего лишь. Оптимизаторы кстати есть, типа optipng, pngcrush, advpng и проч. В последнем, кстати, есть "zophli". Да, это - гугловая штука! Алго сжатия deflate на максималках. Жмет медленно - но лучше остальных, при 100% совместимости с форматом. Есть такая штука - "optimal parsing". Для двухфазных схем с huffman'ом внагрузку оно, правда, обречено быть "приблизительным" но остальные оптимизацией вариантов представления потока вообще не парились и жали еще хуже.
Сохранить вон то ("line art") в JPG можно - но DCT очень плохо реагирует на резкие перепады контраста, он под фотореалистику делался же. И там немеряно артефактов будет. Не для этого оно. А первая версия webp вообще только subsampled yuv умеет. Ибо i-frame от VP8. И для чего-то типа скрина с компа - капец полный по цветности.
Среди оптимизаторов pingo и ECT лидировали. pingo и быстрый, и лучший по степени сжатия, ECT иногда вырывался вперёд на какое-то микроскопическое расстояние.
> Среди оптимизаторов pingo и ECT лидировали. pingo и быстрый, и лучший по степени сжатия,С одним маленьким недостаточком - блоб онли варезок, под маздайку. В таком виде он мне нафиг не упал.
> ECT иногда вырывался вперёд на какое-то микроскопическое расстояние.
С PNG все не так просто: там кроме супер-сжатия еще префильтры есть и в зависимости от его выбора - optipng периодически показывает продвинутым пакерам с ломовым zlib'ом мастеркласс подыскав более удачный префильтр.
Разумеется упомянуть этот тонкий момент авторы того блобика немного постеснялись. А суперкомбо ака подобие optimal parsing + брут префильтра таки займет весьма нетривиальное время, и вот нафиг кому пнг на 3% меньше - путем нагрева проца полдня? :)
> https://css-ig.net/benchmark/png-lossless
Сейчас бы, блин, на сайте автора того блоб онли варезка - смотреть объективные результаты бенчмарков то. Сразу после того как Get The Facts на сайте корпорации Майкрософт дочитаю.
Не знаю, чего тебя так раскукожило, но:
- мне запомнились именно эти две софтины, раньше у меня они показывали себя лучше, чем zopfli и optipng
- из png в одном солидном бенчмарке[1] выжимали все соки именно связкой pingo+ECT. Наверное, ECT обгоняет pingo не "иногда", но "Generation 12562..." спустя часы в консоли напоминает, почему я предпочёл об этом забыть.
- optipng -o7 уже включает перебор всех фильтров (-f0-5)
- (ещё одна ошибка - с lossless WebP в другом комменте, под ним ответил)[1] https://www.reddit.com/r/AV1/comments/fjddcj/lossless_image_.../
Так avif вроде и не лосслесс ни в одном из смыслов. Ну, во всяком случае, libaom говорит, что лосслесс с нужными флагами, но просто раздует файл до невозможности и выдаст очень даже лосси под видом лосслесс (в частности, проредит цвета). Чё они там сравнивали?
Вот не надо, очень даже lossless, а цвета у тебя ломаются потому что надо было читать спецификацию, avif умеет в 8,10 и 12 битность и 400, 422 и 444 сабсэмплинг.
Неа, я прошёлся по всем параметрам кодера. А теперь рассказывай, как у тебя получился lossless avif? Сравнить соответствие оригиналу можешь с magick "${fsrc}" "${file}" -metric PAE -compare -format '%[distortion]' info: и цвета искажает даже со всеми дополнительными параметрами вроде -L -p chroma=444 --matrix_coefficients=0 (что заявлено как лосслесс с rgb).
>что заявлено как лосслесс с rgbвот тут и собака зарыта. avif не умеет в RGB, только в YUV, поэтому и потери в цвете. У jpeg xl этого недостатка нет.
Проблема в твоих руках. Lossless-режим в AV1 сделан для галочки, пользоваться им не надо и раньше баги в реализациях были, но сейчас проблема только в твоих руках.Посмотри на вывод ffprobe, в lossless-режиме yuv444p(бла-бла-бла) должен смениться на gbrp(бла-бла-бла), закодируй правильно, правильно сверь картинки.
avifenc --lossless in.png out1.avif
ffmpeg -i in.png -aom-params lossless=1 out2.avifffmpeg -loglevel error -i in.png -pix_fmt rgb24 -f md5 -
ffmpeg -loglevel error -i out1.avif -pix_fmt rgb24 -f md5 -
ffmpeg -loglevel error -i out2.avif -pix_fmt rgb24 -f md5 --f md5 считает хэш от bitmap'а после декодирования, -pix_fmt rgb24[*] приводит bitmap'ы к единому формату (interleaved/planar, rgb/bgr...), а то avif и png по умолчанию декодируются в разные форматы - "rgb24" и "gbrp".
* для картинок с альфа-каналом и с не-8-битами на канал нужен другой общий знаменатель, очевидно
Отмазки пошли. Какой же, к чёрту, это лосслесс тогда? Получается, проблема и не в моих руках вовсе.
...в твоих руках, а ещё глазах (и руках соседнего анонимуса).Если протереть глаза, то там описан процесс для исходника в RGB с 8 битами на канал. Lossy его превратит в YUV. Lossless - нет. Подходящий общий формат для битмапов: "-pix_fmt rgb24".
И смотри какие чудеса, название забагованного энкодера не указываешь ты, а баг в нём вижу я.https://github.com/strukturag/libheif/issues/62#issuecomment...
> Не знаю, чего тебя так раскукожило, но:То что совать непонятную проприетарь под винду на ресурсе про открытое ПО - это немного невежливо. И может крепко промазать с адресатом.
> - мне запомнились именно эти две софтины, раньше у меня они показывали
> себя лучше, чем zopfli и optipngМои эксперименты с оптимизаций PNG показали что таки - весьма контентозависимо, иногда optipng подбирает более удачный префильтр и остальные напрягаются его побить.
И кстати да, ниоткуда не следует что это же комбо фильтров - столь же оптимально для более сильного zlib пакера. Откуда и идея что полный брут
> pingo+ECT. Наверное, ECT обгоняет pingo не "иногда", но "Generation 12562..."
Ну я и намекал что в какой-то момент таки - и хрен с ним на целые 3% большей PNG'шкой. Убиваться ради нее имеет смысл только если делается "на века" а проц нагрузить совсем нечем.
> - optipng -o7 уже включает перебор всех фильтров (-f0-5)
Угу. Вот это бы с продвинутым пакером скрестить... но тогда все придет к вооон тому, и через полдня этого - захочется ctrl+c вкатить. И черт с ними с 3% улучшений.
> - (ещё одна ошибка - с lossless WebP в другом комменте, под ним ответил)
IIRC таки изначально он был с subsampling и YUV. В v2 вроде что-то более приличное сделали.
> [1] https://www.reddit.com/r/AV1/comments/fjddcj
> /lossless_image_formats_comparison_webp_jpeg_xl/Ну просто не в обиду ISO но их рабочая группа по видео - себя дискредитировала в хлам. Видимо в целом индустрия не очень доверяет и этой группе, хоть они и другие.
Но тебя перераскукожило до ошибок. С обсуждаемой проприетарью optipng сравнить не можешь, но отвечаешь; свободный fhanau/ECT тоже внимания заслуживает. WebP2 у гугла до сих пор называется "WebP 2: experimental successor" и в сравнении по ссылке с реддита обе версии протестированы же.> Ну просто не в обиду ISO но их рабочая группа по видео - себя дискредитировала в хлам. Видимо в целом индустрия не очень доверяет и этой группе, хоть они и другие.
Эта в целом индустрия называется Google и доверяет, конечно, своим WebP, WebP2, AVIF, AVIF@AV2. Но Google ещё, видимо, самодискредитацией занимается, принимая участие в разработке JXL.
согласен, сейчас основной объём - это джаваскрипт
Вы не хотите поработать маркетологом?
Разработчиком сайтов.
Сегодня пользователей тоже очень много, с PNG кэши браузеров быстро заполнятся и терабитные каналы забьются. Было бы иначе, всякие инстаграмы не жали бы картинки до предела худшего качества.
Пытаются оптимизировать йобибайты 100-мегапиксельных селфи в гуглофото... 35% от йобибайта это пара датацентров.
Почему jpegli, а не jpeglib?
> Почему jpegli, а не jpeglib?у нас в rsx11m имена не 8.3 а только 6.3 (зато 6.3;1 !)
Суффикс li не имеет никакого отношения к lib
А к чему имеет?
Такое же как в brotli и zopfli
library interface?
уменьшительно-ласкательный суффикс из швейцарско-немецкого диалекта - https://news.ycombinator.com/item?id=39923731
А Гугл разве немецкая или швейцарская компания?
Там отсылают к "In Zürich arbeiten über 5’000 Googler*innen"
> А Гугл разве немецкая или швейцарская компания?Не, там Jirki Alakuyala (надеюсь правильно написал) - ключевой чувак по компрессии в гугле - откуда-то оттуда. Ну и пошла такая традиция. Вообще что-то типа сортов хлебушков так то.
Не очень понял. Если это новая разработка гугла, почему они её написали на загибающихся плюсах?
Наверно потому что С и С++ на данный момент единственные универсальные языки, с помощью которых можно просто сделать свою работу, а не заниматься "высшей алгоритмической акробатикой". А то, что кто-то там загибается - это сказки для Васянов в шортиках на гироскутерах.
Это два разных языка, которые на текущий момент имеют лишь историческую связь. Это во первых. А во вторых они как минимум с появления Java перестали быть универсальными.На чистом няшном си всерьёз сейчас пишут только под сильно нестандартные архитектуры.
На крестах пишут всякую системную требуху или числодробилки.
Это если мы говорим о новых проектах. Разумеется что на одном, что на другом куча готового кода. Переписывать его на другой язык не имеет смысла, кроме случая, когда переписывание требуется само по себе.
> На чистом няшном си всерьёз сейчас пишут только под сильно нестандартные архитектурыНе смеши) На Си и плюсах сейчас дохрена всего пишется. Во-первых, тонны существующих проектов, которые будут существовать ещё минимум лет 50, и это нельзя не учитывать. Во-вторых, новые проекты. Вот пожалуйста, сам ультрапрогрессивный Гугл выкатил абсолютно новый проект на старом-добром С++, а не на каком-нибудь "модном-молодёжном".
Речь о том, что сишечка с крестами являются нишевыми языками по состоянию на 2к24 год. Если ты боишься, что вот прям всё-всё-всё перепишут и у тебя работы не останется, то могу тебя успокоить. С другой стороны яб не назвал всякие Java/C#/Python/JS и кучу другого "модным-молодёжным". Но кучу задач с C/C++ они определённо сняли. Согласись, несколько непродуктивно писать на них, скажем, веб-бекенд или что-то вроде того. Хотя каких-то лет 30 назад это было по крайней мере одним из вариантов.
ну так libjpeg это и есть числодробилка
просто гугл из загнивающего запада. логично, что они используют загибающиеся плюсы
Загибающихся? Лол, уже минимум лет 20 слышно что вот вот и все, выкинем эту вашу сишку с плюсами, ведь буквально завтра придумали новый языкнейм!
Самое интересное, почему не на Go? Пилили-пилили свой новый язык, который должен был исправить все недостатки языков программирования XX века, а в итоге выкатили новый проект на старом языке :/
> Самое интересное, почему не на Go?А почему не на Rust? )))
Потому что на нём с Си переписывают, а это новая библиотека, исходников на Си нет)
Go пилили не для того, чтобы исправить все недостатки всех языков, а для того, чтобы был узкоспециализированный язык для удобного написания i/o-bound сервисов с event loop. Чтобы по простоте как nodejs, но по производительности близко к C.В libjpeg это вообще не надо.
"Исправить все недостатки" - это к анонимам с опеннета :-)
Из Википедии: "Go может рассматриваться как попытка создать замену языкам С и C++ с учётом изменившихся компьютерных технологий и накопленного опыта разработки крупных систем[15]. По словам Роба Пайка[15], «Go был разработан для решения реальных проблем, возникающих при разработке программного обеспечения в Google»"Выходит, что всё-таки хотели создать свой универсальный язык на замену С и С++, но что-то пошло не так...
потому что там разные команды работают? кому-то проще/привычнее на плюсах писать, наверное
Так зачем было давать новый проект староязыковой команде? Пусть они поддерживали бы легаси код. А новую библиотеку можно было бы начать с чистого листа на новом современном языке.
> Так зачем было давать новый проект древнеязычной команде?//fixed
> Так зачем было давать новый проект староязыковой команде? Пусть они поддерживали бы
> легаси код. А новую библиотеку можно было бы начать с чистого
> листа на новом современном языке.почему вы думаете, что у них разделение по языкам? есть команда по кодекам (а скорее даже конкретно по фотокодекам), там в основном людям комфортно писать на плюсах, скорее всего
надо будет - перепишут хоть на расте, хоть на жабе, была бы необходимость/желание
а нет ли тут бэкдора ?
> Повышение уровня сжатия достигается применением продвинутых технологий для сокращения шумов на изображении и увеличения качества, использующих более эффективные методы психовизуального моделирования для уменьшения возникающих артефактов.Перевожу: у вас будут рисунки вместо фотографий. Ведь вы этого достойны...
MozJPEG больше не нужен?
Так jpegli входит в jpeg-xl
>> методы психовизуального моделирования для уменьшения возникающих артефактов.А можно вообще ИИ генерить, пофигу что там в исходнике было. Пользователь только спасибо скажет и еще с лопаты слижет.
Ну да, в стандартной-то жпеговской мазне любой пользователь с ходу определяет, что там было.
> Ну да, в стандартной-то жпеговской мазне любой пользователь с ходу определяет, что
> там было.А что, нет чтоли? Это тебе любой фильм про шпионов подтвердит! Видишь - там за километр авто, номер размером с прыщик? А вот раз, раз, раз, digital enhancement - и вот уже вместо мазни вполне себе како-нибудь х123ер. Правда, злые языки поговаривают что секретная экспериментальная технология недопилена - и работает почему-то только в фильмах :)
протестил я алгоритм на реальных картинках для сайта, мыло мыльное даже на большем размере, чем то что пожато другим энкодером
>мыло мыльноеЗато от артефактов классического жипега ушли, да.
Это собственно особенность всех современных форматов - они дают мыло вместо блоков, это хорошо видно на всяких сравнениях.
Лучше уж артефакты, чем мыло. К артефактам глаз уже привых и они особо не мешают, а когда мыло, то кажется, что у тебя или с глазами, или с монитором что-то - нечёткое изображение.
на тех размерах что тестировал, артефактов нет или они незаметны без увеличения, а вот потеря деталей на новых алгоритмах очень сильно заметна, картинка получается "мертвая", пластиковая, так мало того, еще и выходной файл больше получался чем у прошлого моего энкодера на 10-20%, а иначе еще больше несоотвествий с оригиналом и проигрыш предыдущему энкодерутак что очень советую тестировать самому, а не хайп ловить, энкодер неплох, но есть лучше
Интересно. А со старымы декомпрессорами оно, кстати, совместимо?
Меня одного пугает указание на "использование собственного декодировщика приводит к снижению артефактов"?Или EEE только от микрософт проблема?
Зачем гугля возится с жыпег-XL? Есть же типа "преемники" - WebP и AVIF - с ними чо, ОПЯТЬ какие-то проблемы?
мы живём в мире, когда скриншоты смартфонов делают в JPEG по той причине, что они 2к в высоту, и при открытии предпросмотра галереи должны мгновенно декодироваться и отображатьсяни один формат этого не может. Apple в свои HEIF вшивают привью предпросмотра отдельной кртинкой
Корпоративная шизофрения. Один отдел развивает JPEG XL, второй - выпиливает его отовсюду, дабы подгадить первому.
31368 resave-png.png 20196 orig.jpg 19128 jpegoptim.jpg 17344 gimp-resave.jpg 5496 guetzli.jpg 3004 jpegli.jpg 1092 test_heic.heic 412 test_avif.avifэто успех, превзошли Guetzli по сжатию, при этом это все еще обычный прогрессивный JPEG для декодера.
AVIF конечно круче, но это уже друой формат.
PS: гусля час пыхтел сожрав 12 гигов памяти
>PS: гусля час пыхтел сожрав 12 гигов памятиПросто надо было guetzli-cuda-opencl собирать и запускать, она достаточно быстро работает.
в то время как обычный даже многопоточность не умеет и в принципе заброшен,
ведь в гугле занимаются всем подряд и бросают без сожаления, хотя некоторые наработки интересны. Возможно и JPEGLI ждет та же судьба
Как правильно использовать эти утилиты?
Я решил проверить это на фотографиях и сканах документов.
Из формата png конвертировал в jpeg. Был удивлен, что у меня после обработки libjpeg-62 файлы имеют меньший объем, чем после сжатия с помощью данной библиотеки от гугла. Это касается практически всех проверенных файлов.
Ожидаемого результата не достиг.