The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Google представил библиотеку jpegli для более эффективного сжатия JPEG-изображений

04.04.2024 11:15

Компания Google представила новую открытую библиотеку jpegli с реализацией кодировщика и декодировщика изображений в формате JPEG. Библиотека включает дополнительные оптимизации для повышения эффективности кодирования, позволяющие на 35% увеличить степень сжатия высококачественных изображений, по сравнению с традиционными кодеками JPEG. В сравнении с libjpeg-turbo библиотека jpegli позволяет добиться аналогичного уровня качества при снижении битрейта на 32%. На уровне API и ABI библиотека полностью совместима с libjpeg62 и может применяться для её прозрачной замены. Код библиотеки написан на языке С++ и распространяется под лицензией BSD.

Повышение уровня сжатия достигается применением продвинутых технологий для сокращения шумов на изображении и увеличения качества, использующих более эффективные методы психовизуального моделирования для уменьшения возникающих артефактов. В частности, в jpegli задействована адаптивная эвристика квантования, используемая проектом JPEG XL, а также улучшенные алгоритмы выбора матриц квантования и расчёта промежуточных результатов.

Библиотека jpegli позволяет кодировать изображения с выделением 10 и более битов на цветовой компонент. При этом результат работы новых алгоритмов кодирования адаптируется для традиционной для формата JPEG модели, допускающей использование только 8 бит на цветовой компонент. Подобная особенность позволяет сохранить совместимость с уже существующими декодировщиками, рассчитанными на 8-битовое представление цветовых составляющих.

Кодируемые при помощи jpegli изображения полностью соответствуют стандарту JPEG, не требуют специфичных декодировщиков и могут просматриваться в существующих просмотрщиках JPEG и web-браузерах. Применение для распаковки изображений, сжатых при помощи jpegli, собственного декодировщика позволяет добиться дополнительного снижения артефактов. Скорость кодирования при помощи jpegli сопоставима с библиотеками libjpeg-turbo и MozJPEG.

  1. Главная ссылка к новости (https://opensource.googleblog....)
  2. OpenNews: Доступен MozJPEG 3.0, высокоэффективный кодировщик JPEG-изображений от проекта Mozilla
  3. OpenNews: Samsung обеспечил поддержку формата изображений JPEG XL
  4. OpenNews: Доступна библиотека libjpeg-turbo 3.0
  5. OpenNews: Новый проект для удаления артефактов из JPEG
  6. OpenNews: Компания Google открыла код эффективного JPEG-кодировщика Guetzli
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/60921-jpegli
Ключевые слова: jpegli, jpeg
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (181) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:50, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Ни webp, ни avif, ни jpeg-xl до сих пор не зашли... Удивительно, почему сразу не могли улучшать обычный jpeg, с обратной совместимостью?
     
     
  • 2.4, Аноним (4), 11:59, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Так потому и улучшают что альтернативно одарённые навязать не удаётся .
     
     
  • 3.30, Аноним (30), 13:13, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Так потому и улучшают что альтернативно одарённые навязать не удаётся .

    Софт порой инерционен с поддержкой. Попробуйте анимированый webp вообще открыть чем?! Кроме хрома/файрфокса, конечно. И как, получается? Даже с анимацией? И всех версий webp? А чтоб еще и отредактировать анимаху и разобрать на фреймы - слабо?! Не, это даже ffmpeg не сожрет с его более 9000 форматов. Вот скроить это может - но билет в одну сторону! А потом это только в хроме и лисе и смотреть. И все, по сути. Write-only формат. Оказывается так можно было.

     
     
  • 4.32, Аноним (32), 13:19, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В telegram же, ну
     
     
  • 5.45, 12yoexpert (ok), 13:52, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    это та социалочка, которая хранит переписку в открытом виде?
     
     
  • 6.63, Аноним (63), 15:55, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Сможешь прочитать мою переписку, раз она в открытом виде?
     
     
  • 7.66, 12yoexpert (ok), 16:42, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    паша сможет и фсб. тебе мало?
     
     
  • 8.80, Аноним (80), 18:28, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    В телеграмме ты сам можешь управлять уровнем приватности Можешь пользоваться об... текст свёрнут, показать
     
     
  • 9.83, балдымалдыбар (?), 18:39, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    может, скажем ему ... текст свёрнут, показать
     
     
  • 10.93, Аноним (93), 20:08, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Протокол открыт и это факт Мне как-то коллега по работе уши прожужжал о его без... текст свёрнут, показать
     
     
  • 11.112, Аноним (-), 23:36, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Протокол никак не помогает - юзеров данонят кореляцией тележного ID - номер те... текст свёрнут, показать
     
     
  • 12.127, Аноним (127), 00:47, 05/04/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 13.136, Аноним (-), 04:48, 05/04/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 14.152, Аноним (127), 12:44, 05/04/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 15.185, Аноним (-), 03:10, 07/04/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 12.128, Аноним (127), 00:48, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Впрочем, как обычно, началось передёргивание Кого-то сажали не за посты, а ЗА П... текст свёрнут, показать
     
     
  • 13.137, Аноним (-), 04:55, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Легко Примеры можно найти - вот прямо в той же телеге Вооооон там господа прям... текст свёрнут, показать
     
  • 9.85, Аноним (85), 19:14, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пофиксил ... текст свёрнут, показать
     
  • 9.110, Аноним (-), 23:30, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по количеству посаженных телеграмеров - с телеграмом ты можешь сам сесть на... большой текст свёрнут, показать
     
     
  • 10.114, Аноним (127), 23:54, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    8212 покупаем симку у опсоса, подконтрольного майору 8212 регистрируемся ... текст свёрнут, показать
     
     
  • 11.119, Аноним (-), 00:26, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Внезапно, да Он это все затребовал от своих юзерей Это он создал эту кореляцию... текст свёрнут, показать
     
     
  • 12.125, Аноним (127), 00:45, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если вас размотало на минном поле 8212 да, сами виноваты ... текст свёрнут, показать
     
     
  • 13.138, Аноним (-), 04:58, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так паша самодуров из каждого рупора орал что все проверено, все безопасно, наве... текст свёрнут, показать
     
  • 8.120, Аноним (120), 00:32, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, Паша так взял и дал ФСБ доступ, он не просто так отсюда уехал после истории... текст свёрнут, показать
     
     
  • 9.139, Аноним (-), 05:01, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это совершенно не помешало им провести закупки комплекса по данону телеграмеров ... текст свёрнут, показать
     
  • 8.148, YetAnotherOnanym (ok), 10:16, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И что за проблема Шифруешь текстовый файлик openssl ем и отправляешь файлом, ил... текст свёрнут, показать
     
  • 5.111, Аноним (-), 23:32, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > В telegram же, ну

    А что, он таки умеет анимаху на фреймы разбирать? Или что с ней там делать предлагается? Пойнт в том что после конверсии в этот формат - вы вообще ничего дальше с этим сделать особо уже не сможете. А постить ее можно и вебе.

     
  • 4.62, Аноним (63), 15:54, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > разобрать на фреймы - слабо?! Не, это даже ffmpeg не сожрет

    Imagemagick может.
    > If you have an old version of imagemagick the command is convert instead of magick

    https://superuser.com/questions/1688850/how-do-i-convert-animated-webp-to-vide
    А потом я собираю фреймы в mp4 через ffmpeg. Получается скрипт по перекодированию анимированного webp в mp4.
    Схема конечно муторнее, чем обычная ffmpeg команда перекодирования gif в mp4, но если надо, то сделать можно.

     
  • 4.91, Аноним (91), 20:07, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Попробуйте анимированый webp вообще открыть чем?!

    Viewnior (gtk2) и Loupe (gtk4) анимированный WEBP открывают, как минимум, уже года два.

     
     
  • 5.113, Аноним (-), 23:51, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> Попробуйте анимированый webp вообще открыть чем?!
    > Viewnior (gtk2) и Loupe (gtk4) анимированный WEBP открывают, как минимум, уже года два.

    Зашибись! Целые 2 года - 2 программы про которые я впервые слышу. Чисто посмотреть. А сколько лет этому формату, не напомните? Я уже со счета сбился.

    ...но отредактировать то эту байду по человечески, с нормальным workflow вы не сможете, и даже просто конвертнуть в что-то другое придется еще поплясать. Воооон там какой-то креативщик с imagemagic'ом и потом ffmpeg'ом. Вот такое вот хреновое лето^W конверсие в мувик получается. Уровень поддержки формата в софте!

    И с каким-нибудь Jpeg XL врядли сильно лучше. А с хрена ли?

     
     
  • 6.115, Аноним (127), 23:57, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Зашибись! Целые 2 года - 2 программы про которые я впервые слышу. Чисто посмотреть.

    IrfanView (извините, что я с оффтопиком, да?) уже шесть лет умеет.

     
     
  • 7.121, Аноним (-), 00:33, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> Зашибись! Целые 2 года - 2 программы про которые я впервые слышу. Чисто посмотреть.
    > IrfanView (извините, что я с оффтопиком, да?) уже шесть лет умеет.

    И там прямо анимации, v2 формата и проч норм работает во всех комбо? Но посмотреть то можно и в браузере накрайняк. А вот разобрать допустим на фреймы или в другой формат это переделать... ээээ... :))

     
     
  • 8.124, Аноним (127), 00:44, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё я для такой мелочёвки софт искать буду Давным-давно это через ezgif делаетс... текст свёрнут, показать
     
  • 6.179, Аноним (179), 15:33, 06/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > А сколько лет этому формату, не напомните?

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

    > отредактировать

    Там imagmagick уже предлагали.

     
  • 2.5, DZgas (?), 12:00, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Потому что сначала надо было придумать эти avif webp jpeg XL что бы брать от туда технологии, которые можно применить в jpeg
    Точно так же как с AQ-3 из HEVC в AVC
    Или та же технология butteraugli придуманная для jpeg XL и далее используемая в другом гугл jpeg кодировщике guetzli
     
     
  • 3.8, Аноним (4), 12:04, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Фичи можно было изначально для джпега разрабатывать , без прокладок и памперсов .
     
     
  • 4.24, Аноним (24), 13:00, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > без прокладок и памперсов

    А как ты тогда тут комментить будешь?

     
  • 3.13, Аноним (1), 12:16, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Точно так же как с AQ-3 из HEVC в AVC

    Можно подробнее? В интернете мало инфы.

     
     
  • 4.69, DZgas (?), 17:13, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    инфы нет вообще, только документация и сами кодеки x264 x265 с всвроенными инструкциями. (в интернете реально просто не существует описания некоторыех параметров кодеков, например Deadzone в x264. Единственное описание на какой то мёртвой вики, на которую ссылается весь интернет, это дизинформация.. такие дела, тыкай сам.)
    AQ-3 в AVC позволяет кодировать тёмные гардиенты (в темноте) без артефактов блочности
     
     
  • 5.92, Аноним (92), 20:07, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да ну, про него говорят, но только с высоты двадцати лет кодекостроения и двадца... большой текст свёрнут, показать
     
     
  • 6.97, Аноним (92), 20:19, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    http://akuvian.org/src/x264/overview_x264_v8_5.pdf

    Судя и по этому, --trellis 1 (пресет <=faster) или 2 (пресет <=slow) заменяет deadzone quantizer с его настройками (--deadzone-inter --deadzone-intra), поэтому ими не стоит забивать голову.

     
  • 6.107, DZgas (?), 21:54, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Короче, алгоритм уменьшает коэффициенты, мыля картинку. Я это к чему говорю, в 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 там это всё.)
     
     
  • 7.118, Аноним (118), 00:14, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    AVC абсолютно на любом разрешении и любых параметрах дно, не спорь. Во всяком случае, я могу утверждать это про x264. А вот x265 терпимо и на sd и на hd+. Но там это, новый босс качалки пришёл, h266 лишён буквально всех недостатков недокодеков вроде vp9/av1 и совершенно идеален.

    >без проблем распараеливаясь

    не без проблем, если ты кодируешь avc больше чем в ~4 потока на fullhd качество кодирования улетает в пол.

     
     
  • 8.142, Аноним (-), 06:16, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А, вот почему ISO так судорожно кодеки строгает А чего у вашего босса поджилки ... текст свёрнут, показать
     
     
  • 9.145, Аноним (118), 09:08, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Так реально vvc даёт совершенно минимальный битрейт и не раздувает его на пусто... текст свёрнут, показать
     
     
  • 10.186, Аноним (-), 03:33, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это все - абстрактные блабла И вот что-что а AV1 в раздувании битрейта я бы уж ... большой текст свёрнут, показать
     
     
  • 11.190, Аноним (118), 09:32, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это всё хорошо, но hevc абсолютно повсюду уже 12 лет Это вечность И никуда ухо... текст свёрнут, показать
     
  • 7.123, Аноним (92), 00:37, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Но это ведь не замена, это фильтры для удаления такого-то шума в таких-то исходн... большой текст свёрнут, показать
     
     
  • 8.187, Аноним (-), 04:16, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    На самом базовом уровне проблема примерно такая анализ глобальной избыточности ... большой текст свёрнут, показать
     
     
  • 9.193, Аноним (92), 15:11, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Но я не про тайлы независимые части кадра для распараллеливания , а про чанки ... текст свёрнут, показать
     
  • 2.10, нитгитлистер (?), 12:10, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    а разве только гугл причастна к разработке всех перечисленных вами форматов?
     
  • 2.12, Аноним (127), 12:15, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Почему сразу перешли на полупроводники, а не улучшали электронные лампы с обратной совместимостью?
    Почему не взлетело — потому что не нужно уже. JPEG без цветовой субдискретизации и так покрывает 99% потребностей, а времена, когда размер картинок был так уж важен, прошли.
    Впрочем, насчёт WEBP это зря. Его как раз гугл пропихнул.
     
     
  • 3.14, прохожий (?), 12:22, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    "времена, когда размер картинок был так уж важен, прошли"
    Я что-то пропустил, или хранение данных резко подешевело?
     
     
  • 4.20, Аноним (-), 12:44, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да, подешевело.
    Не так резко как хотелось бы, но с 2017 года примерно в 2 раза.
    С 3 центов на гиг, до примерно 1.5

    В 2005 average cost per gigabyte было 65 центов, а в 2000 вообще за гиг приходилось отдавать 12 баксов)

    С другой стороны кол-во мегапикселей, телефонов с камерами и фотографий "я и моя сарная кошка" увеличилось, причем думаю не пропорцианально)

     
     
  • 5.22, Аноним (127), 12:46, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Соцсеточки всё равно пережмут всё в хлам и уменьшат до пары мегапикселей.
     
  • 5.102, Аноним (102), 21:00, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Причем тут хранение, проблема в объемах передаваемых данных. А изображения, помимо огромного куска js кода, которая грузится в сингле пэдж аппликатион, одно из основных объемов по трафику.
     
     
  • 6.131, Аноним (127), 01:45, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы из какого года пишете? Основной объём трафика — это видео. Ну так о его ужатии как раз постоянно беспокоятся.
     
  • 4.116, Аноним (127), 00:00, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Как раз те, кто хранит гигантские объёмы контента (те же соцсети, например), от жпега отказываться не особо что-то спешат.
     
  • 3.96, Аноним (91), 20:15, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    WEBP умеет в сжатие без потерь (lossless) и на этом поле обыгрывает популярный PNG на 20-30%.
     
     
  • 4.134, Аноним (-), 04:41, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > WEBP умеет в сжатие без потерь (lossless) и на этом поле обыгрывает
    > популярный PNG на 20-30%.

    Не забыв при этом угробить цвета в скриншотах в хламину. Такой себе lossless, с subsampling'ом то.

     
     
  • 5.146, Аноним (92), 09:17, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    lossless WebP это по сути отдельный кодек, в нём нет chroma subsampling, он не YUV, он RGBA.

    Но у него та же проблема, что и у lossy WebP - если уж слезать с jpg/png, то на jxl.

     
     
  • 6.188, Аноним (-), 04:40, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > lossless WebP это по сути отдельный кодек, в нём нет chroma subsampling,
    > он не YUV, он RGBA.

    Изначально в первой версии это таки тупо I-frame от VP8. И тот чисто технически ничего кроме YUV с subsampling не умел. В версии 2 вроде попустило, но ее поддержка софтом - в еще большей ж... чем первой версии.

    > Но у него та же проблема, что и у lossy WebP - если уж слезать с jpg/png, то на jxl.

    PNG вообще не замена JPG и насколько JXL хорошо дружит с line art и способен в его lossless представление с минимальным размером и без артефактов - это мы еще будем посмотреть.

     
     
  • 7.192, Аноним (92), 14:45, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Всё-таки первый WebP умеет в RGB+lossless и этот режим прикручен отдельно как раз потому что с I-фреймом от VP8 так бы не получилось. Про lossless-режим в первом WebP говорили за 10 лет до WebP2:
    https://blog.chromium.org/2011/11/lossless-and-transparency-encoding-in.html

    > PNG вообще не замена JPG и насколько JXL хорошо дружит с line
    > art и способен в его lossless представление с минимальным размером и
    > без артефактов - это мы еще будем посмотреть.

    Но к чему это? Вот сравнимые кодеки:
    JPG => lossy WebP => lossy JXL
    PNG => lossless WebP => lossless JXL

    Lossless-представление с артефактами - всё-таки оксюморон.

     
  • 2.46, Барабас (-), 13:53, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Знаю несколько сайтов, где выкладывали HD-фотки в обычном jpeg, а потом стали конвертить их в webp, качество стало заметно хуже. Не знаю, какой в этом смысл, фотки занимают не так много места, а webp портит качество.
     
     
  • 3.49, Аноним (49), 14:35, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Скилл ишью. webp жмет по качеству не хуже чем jpeg с таким же параметром качества. Видимо его выкрутили пониже, чтобы жать сильнее, от сайта с hd-фотками в jpeg другого не стоит ожидать.
     
     
  • 4.50, Аноним (118), 14:45, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вебп цвета прореживает.
     
     
  • 5.57, Гость (??), 15:21, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    У WebP есть много опций сжатия, на которые большинство забивают, ограничиваясь одной цифрой "качества", которая работает совсем не как у jpeg.
     
     
  • 6.106, Аноним (118), 21:29, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > У 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).

     
  • 4.71, Аноним (127), 17:16, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Так жмёт-то он из JPEG. Любой супер-пупер лосси алгоритм на каждом шаге что-то да теряет.
     
  • 3.81, namenotfound (?), 18:36, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а потом стали конвертить их в webp, качество стало заметно хуже

    потому что дважды пережато

    > фотки занимают не так много места

    у тебя. а у них это сохранение денег на хранении и получении доступа к терабайтам данных

     
  • 3.98, Аноним (91), 20:21, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > webp портит качество

    Любое lossy-кодирование портит качество, включая JPEG. Пережимать лося в лося -- глупость. Нужно кодировать с одного RAW-источника в JPEG и WEBP, а затем сравнивать. Или не трогать лосей от греха. Не ходите на такие сайты, не пользуйтесь услугами идиотов, до добра это не доводит.

     
     
  • 4.104, Аноним (118), 21:10, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Например, jpegxl убирает артефакты кодирования jpeg в режиме с потерями и делает картинку визуально чище и приятнее. Понятно, что из q60 скажем q95 уже не получится, но, если исходник больше q95, то иногда вполне применимо, судя по моему опыту. Лично я предпочитаю перепаковывать jpeg в jpegxl, как есть, без сжатия -- это быстрая операция, и позволяет сэкономить ~20-99.9%. А jpeg даже с качеством 100 уже слишком убитый файл, чтобы корёжить его дальше. Но если тебя не уважают и предоставили только файлы с потерями, то тут ничего не поделать.
     
     
  • 5.105, Аноним (118), 21:19, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, если сравнивать jpegxl в режиме без потерь с типичным png, то, приняв размер файла png за 1, у jpegxl он будет 0.4 в среднем, и, кроме того он по-настоящему без потерь и не потеряет аттрибуты и экзотические цветовые пространства (png всё потеряет, да). Я не понимаю, какие конченные извращуги пропихнули avif в веб вместо него и кто им позволил -- он не конкурент даже webp.
     
  • 5.180, Аноним (179), 15:41, 06/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вы со своими файлами работаете, на свой страх и риск, вам и карты в руки. А там чужие пачками портят, не глядя.
     
  • 2.52, КО (?), 14:51, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну-ну, сравни сжатую мангу в "webp-архиве" с остальными
     
  • 2.79, Аноним (79), 18:22, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    webp вполне себе зашел. Как минимум в тырнете его довольно прилично.
     
  • 2.198, GG (ok), 11:58, 10/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    webp прекрасно зашли
     

     ....большая нить свёрнута, показать (76)

  • 1.2, нитгитлистер (?), 11:56, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    я правильно понимаю что эта технология сугубо для веба? или она всётаки в ближайшие полгода перекочует в графические проги?
     
     
  • 2.7, Аноним (4), 12:02, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Картинкам надо откуда то браться - появится и в прогах .
     
     
  • 3.94, Аноним (93), 20:11, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А в поисковой системе Гугл нет картинок? Предполагаю что они это делали сугубо для себя, для экономии места под информацию. Может потому и поделились, чтоб себе любимым упростить работу с сайтами.
     
  • 2.157, microcoder (ok), 14:31, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Во всех зеркалках и простых мыльницах используется JPEG, теперь есть возможность заменить
     
     
  • 3.160, Аноним (127), 15:23, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кто-то покупает зеркалки, чтобы фотографировать в JPEG?
    А мыльницы фактически вымерли, остались игрушки, там никому не надо заменять JPEG на что-то эффективное.
     
     
  • 4.162, microcoder (ok), 15:35, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто-то покупает зеркалки, чтобы фотографировать в JPEG?

    Конечно, быстрый предпросмотр ещё никому не мешал. А RAW будет долго распаковывать и жрать аккум, что критично для фотика. Не таскать же за собой диз.станцию )))

    + Зеркалки могут снимать видосики в MJPEG


     
     
  • 5.163, Аноним (127), 15:50, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для быстрого предпросмотра на трёхдюймовом экранчике в один мегапиксель эти нюансы пережатия совершенно несущественны.
     
     
  • 6.199, adolfus (ok), 19:14, 10/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не на трехдюймовом, а на нормальном мониторе. Потому что, пока 20-и мегапиксельный файл на четыре 16-битных канала загрузится, пока из оригинального формата сгенерится тривосьмибитовый RGB для подачи в видеокарту, пройдет куча времени, а мы желаем листать отснятое без ощущаемых задержек в каталогах ФС с сотнями и более фото. Лично я могу с двухчасовой прогулки с детьми принести сотни три фото, которые нужно быстро просмотреть и существенно проредить¸ оставив дюжину, максимум полторы. Вот как раз для этого в RAW'ах (которые есть IFF) содержится чанк с джейпегом.
     
  • 5.184, Аноним (184), 03:04, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Для быстрого предпросмотра в RAW кодируют урезанный вариант в JPEG, thumbnail называется
     

  • 1.3, Аноним (3), 11:57, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Просто праздник какой-то.
     
  • 1.6, Аноним (6), 12:00, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > В частности, в jpegli задействован адаптивная эвристика квантования, используемая проектом JPEG XL…

    Только что Гугл пищал, что там ничего интересного и вообще не нужно.

     
  • 1.9, IdeaFix (ok), 12:07, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    там же жпег2000 был и многие, очень многие решили форкаться...
     
     
  • 2.182, InuYasha (??), 21:47, 06/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Он был максимально проприетарным, емнип.
     

  • 1.11, Аноним (11), 12:12, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Кто нибудь уже смотрел код? Интересно за счет чего бустится производительность, неужто SIMD используют?
     
     
  • 2.23, Аноним (23), 12:49, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    SIMD не позволяет увеличить эффективность сжатия, он только скорость сжатия увеличивает
     

  • 1.15, Zenitur (ok), 12:22, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Как знал, не переходил на libjpeg8 с libjpeg62! Сейчас заменю libjpeg62 на jpegli. Надеюсь, для сборки не потребуется какой-нибудь meson и llvm?

    Upd: уже глянул - cmake и clang-7 или новее. Норм, на apt.llvm.org есть готовая сборка LLVM 7 даже для Debian 7. Так что проблем со сборкой не возникнет.

     
     
  • 2.17, Аноним (118), 12:30, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Мань, сабж на плюсах написан. И ты каждый раз бежишь внедрять все сырые поделки корп? Тот же guetzli оказался весьма дорого и крайне не без потерь, libjpeg-turbo хотя бы предсказуема. А что касается jpegxl, то я очень доволен. Кроме того случая, когда все прошлые файлы внезапно оказались битыми (декодируются с зелёными артефактами местами) для всех новых версий библиотеки, совместимость-с.
     
     
  • 3.21, Zenitur (ok), 12:46, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Я делаю домашние сборки некоторого ПО Вот пример такой сборки https github c... большой текст свёрнут, показать
     
     
  • 4.28, Аноним (118), 13:07, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    У плюсов перечень забавных приколов с аби и библиотекой раскрутки стека, это ещё если исключения не используются, такая библиотека менее универсальна и переносима. Зачем тебе чтобы софтина работала быстрее, ценой замены аутентичного компонента на непонятно что с непонятно какими непредсказуемыми последствиями? Наоборот, стоит бороться за сохранение и презервацию аутентичного кода для будущих поколений и тут чем меньше васянства и отклонений от оригинала, тем лучше.
     
  • 4.29, Аноним (29), 13:12, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >libpng15, который сегодня заменили на libpng16

    Очнись! Твое "сегодня" - это сентябрь 2017 года.

     
     
  • 5.31, Zenitur (ok), 13:14, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В RHEL всё ещё libpng15
     
     
  • 6.33, Аноним (33), 13:24, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что все остальные версии либы насквозь протроянены похуже xz.
     
     
  • 7.36, Zenitur (ok), 13:27, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Потому что все остальные версии либы насквозь протроянены похуже xz.

    Не, потому что последний RHEL релизнулся хрен знает когда. Я тут загуглил - оказывается, 9-й уже вышел... Я не знал.

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

     
     
  • 8.77, cheburnator9000 (ok), 18:05, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Зенитурушка ты что все старые пакеты всех RPM дистрибутивов у себя хранишь Их ж... текст свёрнут, показать
     
     
  • 9.88, Зазнайка (?), 19:42, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Зато существуют у него, у Вас от этого убыло что ли ... текст свёрнут, показать
     
  • 9.129, Аноним (-), 01:10, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Пусть качнет, чтоли, archive debian org себе Если получится, сможет mirror ом п... текст свёрнут, показать
     
  • 9.153, Zenitur (ok), 12:56, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    От CentOS я нашёл архивные зеркала RPMFusion От SLES 11 бэкапил, но пока что ... текст свёрнут, показать
     
  • 2.95, Аноним (93), 20:12, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А в чем проблема с llvm?
     
     
  • 3.151, Zenitur (ok), 12:19, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Обычно я осуществляю сборку в старых дистрах, чтобы бинарник запускался в широко... большой текст свёрнут, показать
     

     ....большая нить свёрнута, показать (13)

  • 1.18, uis (??), 12:35, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Когда арифметическое кодирование?
     
     
  • 2.61, Аноним (92), 15:54, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  Когда арифметическое кодирование?

    a) Патенты истекли лет 15 назад, но уже никогда - решили, что распространение таких jpeg'ов вредно из-за несовместимости со старым софтом.

    b) У себя лично можно давно использовать - пропустить файлы через jpegtran -arithmetic, это lossless-операция.

    c) А для распространения... Проблема из (a) решается сменой формата файла, чтобы арифметический жипег не выглядел обычным жипегом, но тогда и арифметического кодирования придерживаться не обязательно. Перепаковщиков жипега, работающих таким образом, много: ...jojpeg, packJPG, brunsli, lepton, JPEG-XL.

    Lossless-перепаковка jpeg'ов - одна из фич JPEG-XL, ему бы ещё поддержку в браузерах.

     

  • 1.19, Аноним (19), 12:37, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    С сегодняшними скоростями Интернет можно PNG использовать и не париться.
     
     
  • 2.26, нах. (?), 13:04, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    использовать можно, не париться не получится - гугль еще не написал для него "более эффективного кодировщика" (и, главное - декодировщика). А референсный - тот еще тормоз (и никогда, разумеется, не будет сопоставим с жпегом со своими вейвлетами и прочей заумью)

     
     
  • 3.65, Аноним (92), 16:22, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю, при чём тут вейвлеты из старых жипегостандартов, но png ещё можно ускорить распараллеливанием: https://github.com/w3c/PNG-spec/issues/54
     
     
  • 4.108, нах. (?), 22:56, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Можно, но нельзя (потому что это w3c, они не умеют кодить)

    Ждите пока гугель захочет в png (а он не захочет).

     
  • 4.122, Аноним (127), 00:37, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Там про декодирование, оно проблемой не является. «This would significantly reduce the wall-clock time involved in reading large (8k-32k) PNG files on modern machines» — прямо очень частый кейс, да.
     
     
  • 5.132, Аноним (92), 02:18, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тем не менее, Apple такое реализовала. Картинки чаще просматривают, чем сжимают. Причём сжимать обычно нужно много за раз (и однопоточность не мешает), а просматриваются они по одной штуке. Ещё декодирование проблемнее, потому что только для него нужны новые стандартные метаданные.

    Глядишь, для сканов пригодится. Или нет. Сначала надо убедиться, что скорость fpng и wuffs PNG недостаточна: https://github.com/nigeltao/qoir/blob/main/doc/full_benchmarks.txt#L63C59-L63C

     
     
  • 6.161, Аноним (127), 15:25, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да пусть реализуют, спору нет. Просто 99,9% пользователей этого не заметит даже.
     
  • 3.126, Аноним (126), 00:45, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Они вообще разные JPEG для фоточек, PNG для скриншотов, доков, схем, чертежей и... большой текст свёрнут, показать
     
     
  • 4.133, Аноним (92), 02:34, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Среди оптимизаторов pingo и ECT лидировали. pingo и быстрый, и лучший по степени сжатия, ECT иногда вырывался вперёд на какое-то микроскопическое расстояние.

    https://css-ig.net/benchmark/png-lossless

     
     
  • 5.140, Аноним (-), 05:15, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    С одним маленьким недостаточком - блоб онли варезок, под маздайку В таком виде ... большой текст свёрнут, показать
     
     
  • 6.147, Аноним (92), 09:17, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю, чего тебя так раскукожило, но:
    - мне запомнились именно эти две софтины, раньше у меня они показывали себя лучше, чем 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_formats_comparison

     
     
  • 7.155, Аноним (118), 13:03, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Так avif вроде и не лосслесс ни в одном из смыслов. Ну, во всяком случае, libaom говорит, что лосслесс с нужными флагами, но просто раздует файл до невозможности и выдаст очень даже лосси под видом лосслесс (в частности, проредит цвета). Чё они там сравнивали?
     
     
  • 8.166, анонимус (??), 17:25, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вот не надо, очень даже lossless, а цвета у тебя ломаются потому что надо было ч... текст свёрнут, показать
     
     
  • 9.167, Аноним (118), 18:00, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Неа, я прошёлся по всем параметрам кодера А теперь рассказывай, как у тебя полу... текст свёрнут, показать
     
     
  • 10.173, анонимус (??), 21:58, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    вот тут и собака зарыта avif не умеет в RGB, только в YUV, поэтому и потери в ц... текст свёрнут, показать
     
  • 8.174, Аноним (92), 05:22, 06/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема в твоих руках Lossless-режим в AV1 сделан для галочки, пользоваться им... большой текст свёрнут, показать
     
     
  • 9.175, Аноним (118), 08:06, 06/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Отмазки пошли Какой же, к чёрту, это лосслесс тогда Получается, проблема и не ... текст свёрнут, показать
     
     
  • 10.176, Аноним (92), 09:40, 06/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    в твоих руках, а ещё глазах и руках соседнего анонимуса Если протереть гла... текст свёрнут, показать
     
  • 10.177, Аноним (92), 10:09, 06/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И смотри какие чудеса, название забагованного энкодера не указываешь ты, а баг в... текст свёрнут, показать
     
  • 7.189, Аноним (-), 04:48, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    То что совать непонятную проприетарь под винду на ресурсе про открытое ПО - это ... большой текст свёрнут, показать
     
     
  • 8.191, Аноним (92), 14:37, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Но тебя перераскукожило до ошибок С обсуждаемой проприетарью optipng сравнить н... текст свёрнут, показать
     
  • 2.43, 12yoexpert (ok), 13:49, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    согласен, сейчас основной объём - это джаваскрипт
     
  • 2.53, КО (?), 14:51, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вы не хотите поработать маркетологом?
     
     
  • 3.74, Аноним (74), 17:29, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Разработчиком сайтов.
     
  • 2.55, Гость (??), 15:11, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сегодня пользователей тоже очень много, с PNG кэши браузеров быстро заполнятся и терабитные каналы забьются. Было бы иначе, всякие инстаграмы не жали бы картинки до предела худшего качества.
     

     ....большая нить свёрнута, показать (24)

  • 1.25, Аноним (25), 13:04, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пытаются оптимизировать йобибайты 100-мегапиксельных селфи в гуглофото... 35% от йобибайта это пара датацентров.
     
  • 1.35, Аноним (35), 13:26, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Почему jpegli, а не jpeglib?
     
     
  • 2.51, google (??), 14:49, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Почему jpegli, а не jpeglib?

    у нас в rsx11m имена не 8.3 а только 6.3 (зато 6.3;1 !)

     
  • 2.68, Самый умный аноним (?), 16:54, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Суффикс li не имеет никакого отношения к lib
     
     
  • 3.70, Аноним (35), 17:16, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А к чему имеет?
     
     
  • 4.84, Самый умный аноним (?), 19:06, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Такое же как в brotli и zopfli
     
     
  • 5.89, Зазнайка (?), 19:45, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    library interface?
     
     
  • 6.100, Аноним (92), 20:39, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    уменьшительно-ласкательный суффикс из швейцарско-немецкого диалекта - https://news.ycombinator.com/item?id=39923731
     
     
  • 7.101, Максим (??), 20:59, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А Гугл разве немецкая или швейцарская компания?
     
     
  • 8.103, Аноним (92), 21:07, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Там отсылают к In Z 252 rich arbeiten 252 ber 5 8217 000 Googler innen ... текст свёрнут, показать
     
  • 8.130, Аноним (-), 01:12, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не, там Jirki Alakuyala надеюсь правильно написал - ключевой чувак по компресс... текст свёрнут, показать
     

  • 1.37, Аноним (37), 13:28, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Не очень понял. Если это новая разработка гугла, почему они её написали на загибающихся плюсах?
     
     
  • 2.40, Аноним (35), 13:45, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Наверно потому что С и С++ на данный момент единственные универсальные языки, с помощью которых можно просто сделать свою работу, а не заниматься "высшей алгоритмической акробатикой". А то, что кто-то там загибается - это сказки для Васянов в шортиках на гироскутерах.
     
     
  • 3.144, laindono (ok), 08:37, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это два разных языка, которые на текущий момент имеют лишь историческую связь. Это во первых. А во вторых они как минимум с появления Java перестали быть универсальными.

    На чистом няшном си всерьёз сейчас пишут только под сильно нестандартные архитектуры.

    На крестах пишут всякую системную требуху или числодробилки.

    Это если мы говорим о новых проектах. Разумеется что на одном, что на другом куча готового кода. Переписывать его на другой язык не имеет смысла, кроме случая, когда переписывание требуется само по себе.

     
     
  • 4.156, Аноним (35), 13:26, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > На чистом няшном си всерьёз сейчас пишут только под сильно нестандартные архитектуры

    Не смеши) На Си и плюсах сейчас дохрена всего пишется. Во-первых, тонны существующих проектов, которые будут существовать ещё минимум лет 50, и это нельзя не учитывать. Во-вторых, новые проекты. Вот пожалуйста, сам ультрапрогрессивный Гугл выкатил абсолютно новый проект на старом-добром С++, а не на каком-нибудь "модном-молодёжном".

     
     
  • 5.170, laindono (ok), 18:56, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Речь о том, что сишечка с крестами являются нишевыми языками по состоянию на 2к24 год. Если ты боишься, что вот прям всё-всё-всё перепишут и у тебя работы не останется, то могу тебя успокоить. С другой стороны яб не назвал всякие Java/C#/Python/JS и кучу другого "модным-молодёжным". Но кучу задач с C/C++ они определённо сняли. Согласись, несколько непродуктивно писать на них, скажем, веб-бекенд или что-то вроде того. Хотя каких-то лет 30 назад это было по крайней мере одним из вариантов.
     
  • 4.169, Аноним (169), 18:20, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ну так libjpeg это и есть числодробилка
     
  • 2.42, 12yoexpert (ok), 13:48, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    просто гугл из загнивающего запада. логично, что они используют загибающиеся плюсы
     
  • 2.58, Аноним (11), 15:22, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Загибающихся? Лол, уже минимум лет 20 слышно что вот вот и все, выкинем эту вашу сишку с плюсами, ведь буквально завтра придумали новый языкнейм!
     
  • 2.60, Аноним (35), 15:46, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Самое интересное, почему не на Go? Пилили-пилили свой новый язык, который должен был исправить все недостатки языков программирования XX века, а в итоге выкатили новый проект на старом языке :/
     
     
  • 3.158, microcoder (ok), 14:37, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Самое интересное, почему не на Go?

    А почему не на Rust? )))

     
     
  • 4.159, Аноним (35), 14:55, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что на нём с Си переписывают, а это новая библиотека, исходников на Си нет)
     
  • 3.168, Аноним (169), 18:19, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Go пилили не для того, чтобы исправить все недостатки всех языков, а для того, чтобы был узкоспециализированный язык для удобного написания i/o-bound сервисов с event loop. Чтобы по простоте как nodejs, но по производительности близко к C.

    В libjpeg это вообще не надо.

    "Исправить все недостатки" - это к анонимам с опеннета :-)

     
     
  • 4.171, Аноним (35), 18:57, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Из Википедии: "Go может рассматриваться как попытка создать замену языкам С и C++ с учётом изменившихся компьютерных технологий и накопленного опыта разработки крупных систем[15]. По словам Роба Пайка[15], «Go был разработан для решения реальных проблем, возникающих при разработке программного обеспечения в Google»"

    Выходит, что всё-таки хотели создать свой универсальный язык на замену С и С++, но что-то пошло не так...

     
  • 2.82, namenotfound (?), 18:38, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    потому что там разные команды работают? кому-то проще/привычнее на плюсах писать, наверное
     
     
  • 3.87, Аноним (35), 19:29, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Так зачем было давать новый проект староязыковой команде? Пусть они поддерживали бы легаси код. А новую библиотеку можно было бы начать с чистого листа на новом современном языке.
     
     
  • 4.90, Зазнайка (?), 19:48, 04/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Так зачем было давать новый проект древнеязычной команде?

    //fixed

     
  • 4.178, namenotfound (?), 12:37, 06/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Так зачем было давать новый проект староязыковой команде? Пусть они поддерживали бы
    > легаси код. А новую библиотеку можно было бы начать с чистого
    > листа на новом современном языке.

    почему вы думаете, что у них разделение по языкам? есть команда по кодекам (а скорее даже конкретно по фотокодекам), там в основном людям комфортно писать на плюсах, скорее всего

    надо будет - перепишут хоть на расте, хоть на жабе, была бы необходимость/желание

     

  • 1.39, Аноним12345 (?), 13:38, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    а нет ли тут бэкдора ?
     
  • 1.54, Аноним (54), 15:03, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Повышение уровня сжатия достигается применением продвинутых технологий для сокращения шумов на изображении и увеличения качества, использующих более эффективные методы психовизуального моделирования для уменьшения возникающих артефактов.

    Перевожу: у вас будут рисунки вместо фотографий. Ведь вы этого достойны...

     
  • 1.64, DEF (?), 16:22, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    MozJPEG больше не нужен?
     
  • 1.86, Аноним (86), 19:16, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Так jpegli входит в jpeg-xl
     
  • 1.109, голос из леса (?), 23:06, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >> методы психовизуального моделирования для уменьшения возникающих артефактов.

    А можно вообще ИИ генерить, пофигу что там в исходнике было. Пользователь только спасибо скажет и еще с лопаты слижет.

     
     
  • 2.117, Аноним (127), 00:03, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да, в стандартной-то жпеговской мазне любой пользователь с ходу определяет, что там было.
     
     
  • 3.141, Аноним (-), 05:24, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну да, в стандартной-то жпеговской мазне любой пользователь с ходу определяет, что
    > там было.

    А что, нет чтоли? Это тебе любой фильм про шпионов подтвердит! Видишь - там за километр авто, номер размером с прыщик? А вот раз, раз, раз, digital enhancement - и вот уже вместо мазни вполне себе како-нибудь х123ер. Правда, злые языки поговаривают что секретная экспериментальная технология недопилена - и работает почему-то только в фильмах :)

     

  • 1.143, penetrator (?), 08:14, 05/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    протестил я алгоритм на реальных картинках для сайта, мыло мыльное даже на большем размере, чем то что пожато другим энкодером
     
     
  • 2.149, devl547 (ok), 11:31, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >мыло мыльное

    Зато от артефактов классического жипега ушли, да.
    Это собственно особенность всех современных форматов - они дают мыло вместо блоков, это хорошо видно на всяких сравнениях.

     
     
  • 3.154, Аноним (35), 13:02, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Лучше уж артефакты, чем мыло. К артефактам глаз уже привых и они особо не мешают, а когда мыло, то кажется, что у тебя или с глазами, или с монитором что-то - нечёткое изображение.
     
  • 3.194, penetrator (?), 17:24, 08/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    на тех размерах что тестировал, артефактов нет или они незаметны без увеличения, а вот потеря деталей на новых алгоритмах очень сильно заметна, картинка получается "мертвая", пластиковая, так мало того, еще и выходной файл больше получался чем у прошлого моего энкодера на 10-20%, а иначе еще больше несоотвествий с оригиналом и проигрыш предыдущему энкодеру

    так что очень советую тестировать самому, а не хайп ловить, энкодер неплох, но есть лучше

     
  • 2.183, InuYasha (??), 21:49, 06/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Интересно. А со старымы декомпрессорами оно, кстати, совместимо?
     

  • 1.150, Scondo (?), 12:02, 05/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Меня одного пугает указание на "использование собственного декодировщика приводит к снижению артефактов"?

    Или EEE только от микрософт проблема?

     
  • 1.164, Аноним (164), 16:08, 05/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Зачем гугля возится с жыпег-XL? Есть же типа "преемники" - WebP и AVIF - с ними чо, ОПЯТЬ какие-то проблемы?
     
     
  • 2.172, DZgas (?), 20:43, 05/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    мы живём в мире, когда скриншоты смартфонов делают в JPEG по той причине, что они 2к в высоту, и при открытии предпросмотра галереи должны мгновенно декодироваться и отображаться

    ни один формат этого не может. Apple в свои HEIF вшивают привью предпросмотра отдельной кртинкой

     

  • 1.165, Аноним (165), 16:53, 05/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Корпоративная шизофрения. Один отдел развивает JPEG XL, второй - выпиливает его отовсюду, дабы подгадить первому.
     
  • 1.181, Sylvia (ok), 20:20, 06/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    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 гигов памяти

     
     
  • 2.195, devl547 (ok), 22:29, 08/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >PS: гусля час пыхтел сожрав 12 гигов памяти

    Просто надо было guetzli-cuda-opencl собирать и запускать, она достаточно быстро работает.

     
     
  • 3.197, Sylvia (ok), 22:54, 09/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    в то время как обычный даже многопоточность не умеет и в принципе заброшен,
    ведь в гугле занимаются всем подряд и бросают без сожаления, хотя некоторые наработки интересны. Возможно и JPEGLI ждет та же судьба
     

  • 1.196, MihaNix (ok), 03:49, 09/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как правильно использовать эти утилиты?
    Я решил проверить это на фотографиях и сканах документов.
    Из формата png конвертировал в jpeg. Был удивлен, что у меня после обработки libjpeg-62 файлы имеют меньший объем, чем после сжатия с помощью данной библиотеки от гугла. Это касается практически всех проверенных файлов.
    Ожидаемого результата не достиг.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру