Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Google представил библиотеку jpegli для более эффективного сжатия JPEG-изрбражений "	+/–
Сообщение от opennews (??), 04-Апр-24, 11:50
Компания Google представила новую открытую библиотеку jpegli с реализацией кодировщика и декодировщика изображений в формате JPEG. Библиотека включает дополнительные оптимизации для повышения эффективности кодирования, позволяющие на 35% увеличить степень сжатия высококачественных изображений, по сравнению с традиционными кодеками JPEG. В сравнении с  libjpeg-turbo  библиотека jpegli  позволяет добиться аналогичного уровня качества при снижении битрейта на 32%. На уровне API и ABI библиотека полностью совместима с  libjpeg62 и может применяться для её прозрачной замены. Код библиотеки написан на языке С++ и распространяется под лицензией BSD... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60921
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Google представил библиотеку jpegli для более эффективного с..."	–7 +/–
Сообщение от Аноним (1), 04-Апр-24, 11:50
Ни webp, ни avif, ни jpeg-xl до сих пор не зашли... Удивительно, почему сразу не могли улучшать обычный jpeg, с обратной совместимостью?
Ответить | Правка | Наверх | Cообщить модератору

	4. "Google представил библиотеку jpegli для более эффективного с..."	–6 +/–
	Сообщение от Аноним (4), 04-Апр-24, 11:59
	Так потому и улучшают что альтернативно одарённые навязать не удаётся .
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Google представил библиотеку jpegli для более эффективного с..."	+5 +/–
	Сообщение от Аноним (30), 04-Апр-24, 13:13
	> Так потому и улучшают что альтернативно одарённые навязать не удаётся . Софт порой инерционен с поддержкой. Попробуйте анимированый webp вообще открыть чем?! Кроме хрома/файрфокса, конечно. И как, получается? Даже с анимацией? И всех версий webp? А чтоб еще и отредактировать анимаху и разобрать на фреймы - слабо?! Не, это даже ffmpeg не сожрет с его более 9000 форматов. Вот скроить это может - но билет в одну сторону! А потом это только в хроме и лисе и смотреть. И все, по сути. Write-only формат. Оказывается так можно было.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Google представил библиотеку jpegli для более эффективного с..."	–1 +/–
	Сообщение от Аноним (32), 04-Апр-24, 13:19
	В telegram же, ну
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Google представил библиотеку jpegli для более эффективного с..."	–2 +/–
	Сообщение от 12yoexpert (ok), 04-Апр-24, 13:52
	это та социалочка, которая хранит переписку в открытом виде?
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (63), 04-Апр-24, 15:55
	Сможешь прочитать мою переписку, раз она в открытом виде?
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от 12yoexpert (ok), 04-Апр-24, 16:42
	паша сможет и фсб. тебе мало?
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Google представил библиотеку jpegli для более эффективного с..."	–3 +/–
	Сообщение от Аноним (80), 04-Апр-24, 18:28
	В телеграмме ты сам можешь управлять уровнем приватности. Можешь пользоваться обычными чатами и иметь связанные с этим бонусы в виде сохранения истории, нормальной синхронизации между устройствами, возможности докачивания вложений и прочего. Или можешь пользоваться секретными чатами. Протокол открыт, клиенты опенсорсны. Был публичный конкурс с предложением его взломать с большими призовыми. Никто, вроде, приз так и не взял.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Google представил библиотеку jpegli для более эффективного с..."	+2 +/–
	Сообщение от балдымалдыбар (?), 04-Апр-24, 18:39
	>Протокол открыт может, скажем ему?...
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Google представил библиотеку jpegli для более эффективного с..."	–1 +/–
	Сообщение от Аноним (93), 04-Апр-24, 20:08
	Протокол открыт и это факт. Мне как-то коллега по работе уши прожужжал о его безопасности. Протокол то хорош, но большинство людей не настолько умны чтобы его использовать. Более того, вы уверены что прям ФСБ работает с телеграм? Я думаю это все слухи, потому что он не контролируется американскими силовыми ведомствами. Но помнится в скором времени владелец там что-то про IPO говорил, вот тогда его и возьмут за финансовые жабры. И судя по вашей логике ответов, вот тогда он станет демократичным и пригодным для использования. Какие же это двойные стандарты!
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 04-Апр-24, 23:36
	> Протокол открыт и это факт. Мне как-то коллега по работе уши прожужжал > о его безопасности. Протокол то хорош, но большинство людей не настолько > умны чтобы его использовать. Протокол никак не помогает - юзеров данонят кореляцией тележного ID <-> номер телефона и пробитием далее телефона по утекшам базам. И вот чем вам поможет хоть какой протокол от этого, если факап - в той логике? Для майоров есть даже комплекс автоматизирующий это, недавно как раз засветился в закупках, но такой уровень атаки - даже и васян сможет, если захочет. Большая часть юзерей забывает скрыть номер телефона - за что и огребает сполна, наслушавшись булшита про "безопасный месенжер" - и сев на десяток лет и более.
	Ответить | Правка | Наверх | Cообщить модератору

	127. Скрыто модератором	+/–
	Сообщение от Аноним (127), 05-Апр-24, 00:47
	Если пользователь, живя в тоталитарном государстве, желает выражать своё мнение, но не желает заботиться о конспирации — ССЗБ.
	Ответить | Правка | Наверх | Cообщить модератору

	136. Скрыто модератором	+/–
	Сообщение от Аноним (-), 05-Апр-24, 04:48
	> Если пользователь, живя в тоталитарном государстве, желает выражать своё мнение, но не > желает заботиться о конспирации — ССЗБ. Отлично, а зачем ему тогда безопасность обещают? Чтобы увеличить число залетчиков? Какие хорошие, белые и пушистые господа. И совсем не провокаторы даже.
	Ответить | Правка | Наверх | Cообщить модератору

	152. Скрыто модератором	+/–
	Сообщение от Аноним (127), 05-Апр-24, 12:44
	А ещё не предупреждали, что кошку в микроволновке сушить нельзя!
	Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

	185. Скрыто модератором	+/–
	Сообщение от Аноним (-), 07-Апр-24, 03:10
	> А ещё не предупреждали, что кошку в микроволновке сушить нельзя! Можете юродствовать сколько угодно - а я взамен буду считать что... 1) Высокие напряжения и интенсивные излучения - представляют неиллюзорную опасность и лучше с ними не связываться без острой на то нужды лишний раз. Иначе можно влегкую помереть или покалечиться. 2) Те кто обещает безопасность юзерам но не обеспечивает ее - в ответе за такую подставу и де факто что-то типа провокаторов.
	Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

	128. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (127), 05-Апр-24, 00:48
	Впрочем, как обычно, началось передёргивание. Кого-то сажали не за посты, а ЗА ПЕРЕПИСКУ?
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

	137. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 05-Апр-24, 04:55
	> Впрочем, как обычно, началось передёргивание. Кого-то сажали не за посты, а ЗА ПЕРЕПИСКУ? Легко. Примеры можно найти - вот прямо в той же телеге. Вооооон там господа прям с фоточками и скриншотиками показывают отловленных экземплярчиков - и что именно им инкриминируется. А чо, удобно же, подгрузка истории и все такое... осталось еще автоматические скриншоты запилить - и отсылку на товарищмайорский канал, чего майоры на кучу кликов время то тратят?! Уже б генералами были давно.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от Аноним (85), 04-Апр-24, 19:14
	> В телеграмме ты сам можешь управлять уровнем приватности. Можешь пользоваться Телеграмом, а можешь - не пользоваться. А если нет опции жить и не польжоваться - то можешь и не жить. Пофиксил.
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	110. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 04-Апр-24, 23:30
	> В телеграмме ты сам можешь управлять уровнем приватности. Можешь пользоваться обычными > чатами и иметь связанные с этим бонусы в виде сохранения истории, > нормальной синхронизации между устройствами, возможности докачивания вложений и прочего. Судя по количеству посаженных телеграмеров - с телеграмом ты можешь сам сесть на десять лет. Влегкую. А управление приватностью там в основном путем засовывания языка в ... и сидения тихо, судя по тому как телеграмеров пакуют в РАЗНЫХ юрисдикциях. Тенденция однако. > Или можешь пользоваться секретными чатами. Протокол открыт, клиенты опенсорсны. > Был публичный конкурс с предложением его взломать с большими призовыми. Никто, вроде, > приз так и не взял. А оно на практике нахрен не надо. Майор просто радостно загрузит историю. Не с девайса, так с сервера самодурова на соседнем девайсе. Синхра девайсов. Удобно же!
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	114. "Google представил библиотеку jpegli для более эффективного с..."	+2 +/–
	Сообщение от Аноним (127), 04-Апр-24, 23:54
	— покупаем симку у опсоса, подконтрольного майору; — регистрируемся с этим номером в мессенджере; — получаем срок за пост… кто виноват? ну конечно, мессенджер.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 05-Апр-24, 00:26
	> — покупаем симку у опсоса, подконтрольного майору; > — регистрируемся с этим номером в мессенджере; > — получаем срок за пост… кто виноват? ну конечно, мессенджер. Внезапно, да. Он это все затребовал от своих юзерей. Это он создал эту кореляцию. Он ее хранил. И же и слил ЭТО всем посторонним рожам, оптом, по дефолту! Так что - виноват. По полной программе. Эталонное создание юзерям подстав. С таким же успехом - можно говорить что если вас размотало на мине на дорожке, виноваты - вы, потому что пошли гулять без миноискателя. А могли бы обучиться саперному делу и убрать ее с дорожки, "как нормальный человев". Что за лох такой - без миноискателя и саперного костюма?!
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (127), 05-Апр-24, 00:45
	Если вас размотало на минном поле — да, сами виноваты.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от Аноним (-), 05-Апр-24, 04:58
	> Если вас размотало на минном поле — да, сами виноваты. Так паша самодуров из каждого рупора орал что все проверено, все безопасно, навесил табличку - мин нет. А виноват после этого пользователь. Логично, чо.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (120), 05-Апр-24, 00:32
	Ага, Паша так взял и дал ФСБ доступ, он не просто так отсюда уехал после истории с ВКонтакте. ФСБ последние кто сможет получить доступ к переписка телеграмма.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	139. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 05-Апр-24, 05:01
	> Ага, Паша так взял и дал ФСБ доступ, он не просто так > отсюда уехал после истории с ВКонтакте. ФСБ последние кто сможет получить > доступ к переписка телеграмма. Это совершенно не помешало им провести закупки комплекса по данону телеграмеров - который маппит тележный ID в номер телефона ибо по дефолту это вывешено всей толпе, и нагрести эти данные оптом не вопрос. А потом они по утекшим у операторов сотовым базам - всей толпой лукапают без всяких глупых запросов операторам что сие за тушки. Удобно однако! Вот вам и вся безопасность от паши самодурова. Все что о ней надо было знать. А ФСБ что, если оно вас за жабры возьмет, тут вот как раз история с сервака и подгрузитяс очень кстати. А после небольшого массажа почек - и всему отделу засинхронизируется.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от YetAnotherOnanym (ok), 05-Апр-24, 10:16
	> паша сможет и фсб И что за проблема? Шифруешь текстовый файлик openssl'ем и отправляешь файлом, или шифруешь сообщение, тут же кодируешь его в base64 и отправляешь как текст. Собеседник должен уметь в openssl? Ну дык, либо ты играешь в эти игры, и тогда ты играешь всерьёз, в том числе выбирая корреспондентов, с которыми можно вести тайные дела, либо не играешь вообще.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	111. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 04-Апр-24, 23:32
	> В telegram же, ну А что, он таки умеет анимаху на фреймы разбирать? Или что с ней там делать предлагается? Пойнт в том что после конверсии в этот формат - вы вообще ничего дальше с этим сделать особо уже не сможете. А постить ее можно и вебе.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	62. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (63), 04-Апр-24, 15:54
	> разобрать на фреймы - слабо?! Не, это даже 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-ani... А потом я собираю фреймы в mp4 через ffmpeg. Получается скрипт по перекодированию анимированного webp в mp4. Схема конечно муторнее, чем обычная ffmpeg команда перекодирования gif в mp4, но если надо, то сделать можно.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	91. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (91), 04-Апр-24, 20:07
	> Попробуйте анимированый webp вообще открыть чем?! Viewnior (gtk2) и Loupe (gtk4) анимированный WEBP открывают, как минимум, уже года два.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	113. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 04-Апр-24, 23:51
	>> Попробуйте анимированый webp вообще открыть чем?! > Viewnior (gtk2) и Loupe (gtk4) анимированный WEBP открывают, как минимум, уже года два. Зашибись! Целые 2 года - 2 программы про которые я впервые слышу. Чисто посмотреть. А сколько лет этому формату, не напомните? Я уже со счета сбился. ...но отредактировать то эту байду по человечески, с нормальным workflow вы не сможете, и даже просто конвертнуть в что-то другое придется еще поплясать. Воооон там какой-то креативщик с imagemagic'ом и потом ffmpeg'ом. Вот такое вот хреновое лето^W конверсие в мувик получается. Уровень поддержки формата в софте! И с каким-нибудь Jpeg XL врядли сильно лучше. А с хрена ли?
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (127), 04-Апр-24, 23:57
	> Зашибись! Целые 2 года - 2 программы про которые я впервые слышу. Чисто посмотреть. IrfanView (извините, что я с оффтопиком, да?) уже шесть лет умеет.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 05-Апр-24, 00:33
	>> Зашибись! Целые 2 года - 2 программы про которые я впервые слышу. Чисто посмотреть. > IrfanView (извините, что я с оффтопиком, да?) уже шесть лет умеет. И там прямо анимации, v2 формата и проч норм работает во всех комбо? Но посмотреть то можно и в браузере накрайняк. А вот разобрать допустим на фреймы или в другой формат это переделать... ээээ... :))
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (127), 05-Апр-24, 00:44
	Ещё я для такой мелочёвки софт искать буду. Давным-давно это через ezgif делается.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (179), 06-Апр-24, 15:33
	> А сколько лет этому формату, не напомните? Не интересовался. Но когда столкнулся с изображениями этого формата, мне было их чем открыть. > отредактировать Там imagmagick уже предлагали.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	5. "Google представил библиотеку jpegli для более эффективного с..."	+8 +/–
	Сообщение от DZgas (?), 04-Апр-24, 12:00
	Потому что сначала надо было придумать эти avif webp jpeg XL что бы брать от туда технологии, которые можно применить в jpeg Точно так же как с AQ-3 из HEVC в AVC Или та же технология butteraugli придуманная для jpeg XL и далее используемая в другом гугл jpeg кодировщике guetzli
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	8. "Google представил библиотеку jpegli для более эффективного с..."	–4 +/–
	Сообщение от Аноним (4), 04-Апр-24, 12:04
	Фичи можно было изначально для джпега разрабатывать , без прокладок и памперсов .
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Google представил библиотеку jpegli для более эффективного с..."	+4 +/–
	Сообщение от Аноним (24), 04-Апр-24, 13:00
	> без прокладок и памперсов А как ты тогда тут комментить будешь?
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (1), 04-Апр-24, 12:16
	> Точно так же как с AQ-3 из HEVC в AVC Можно подробнее? В интернете мало инфы.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	69. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от DZgas (?), 04-Апр-24, 17:13
	инфы нет вообще, только документация и сами кодеки x264 x265 с всвроенными инструкциями. (в интернете реально просто не существует описания некоторыех параметров кодеков, например Deadzone в x264. Единственное описание на какой то мёртвой вики, на которую ссылается весь интернет, это дизинформация.. такие дела, тыкай сам.) AQ-3 в AVC позволяет кодировать тёмные гардиенты (в темноте) без артефактов блочности
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (92), 04-Апр-24, 20:07
	> в интернете реально просто не существует описания некоторыех параметров кодеков, например 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
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (92), 04-Апр-24, 20:19
	http://akuvian.org/src/x264/overview_x264_v8_5.pdf Судя и по этому, --trellis 1 (пресет <=faster) или 2 (пресет <=slow) заменяет deadzone quantizer с его настройками (--deadzone-inter --deadzone-intra), поэтому ими не стоит забивать голову.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от DZgas (?), 04-Апр-24, 21:54
	Короче, алгоритм уменьшает коэффициенты, мыля картинку. Я это к чему говорю, в 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 там это всё.)
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

	118. "Google представил библиотеку jpegli для более эффективного с..."	–1 +/–
	Сообщение от Аноним (118), 05-Апр-24, 00:14
	AVC абсолютно на любом разрешении и любых параметрах дно, не спорь. Во всяком случае, я могу утверждать это про x264. А вот x265 терпимо и на sd и на hd+. Но там это, новый босс качалки пришёл, h266 лишён буквально всех недостатков недокодеков вроде vp9/av1 и совершенно идеален. >без проблем распараеливаясь не без проблем, если ты кодируешь avc больше чем в ~4 потока на fullhd качество кодирования улетает в пол.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 05-Апр-24, 06:16
	> AVC абсолютно на любом разрешении и любых параметрах дно, не спорь. Во > всяком случае, я могу утверждать это про x264. А вот x265 > терпимо и на sd и на hd+. Но там это, новый > босс качалки пришёл, h266 лишён буквально всех недостатков недокодеков вроде vp9/av1 > и совершенно идеален. А, вот почему ISO так судорожно кодеки строгает? А чего у вашего босса поджилки трясутся и из носа сопля свисает? Неужто получше никого не нашли?! И вот это чмище теперь попробует устроить патентный рэкет всему раёну? :)
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (118), 05-Апр-24, 09:08
	Так реально vvc даёт совершенно минимальный битрейт (и не раздувает его на пустом месте как vp9/av1, толку от качества, если битрейт улетает в небеса, а без битрейта сыпет жуткими глитчами), не размывает картинку так сильно (av1 даже на медленнейшем качестве и неограниченном битрейте более мыльный, чем быстрый vvc), лучше держит края. И то, что av1 противопоставляют в лучшем случае hevc (а чаще всего avc) достаточно показательно. Победитель уже известен.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 07-Апр-24, 03:33
	> Так реально 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, у него половины эффективных тулсов уменьшения битрейта на уровне формата потока нет. Отсталый прямо на момент дизайна формат. Потому исо и страгает новые в истеричном темпе, контроль над ситуацией утекает из их кривых лапок.
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (118), 07-Апр-24, 09:32
	Это всё хорошо, но hevc абсолютно повсюду уже 12 лет. Это вечность. И никуда уходить не собирается, это до сих пор единственный вариант для качественного контента до повсеместного распространения декодеров h266 ещё несколько лет пройдёт. А ты, наверное, хотел как с mpeg2? Так он лет 10 использовался, bd заменил dvd и до-свидания.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (92), 05-Апр-24, 00:37
	Но это ведь не замена, это фильтры для удаления такого-то шума в таких-то исходниках. Плюс решение не тюнить качество/размер_файла до посинения. Хз, должен ли 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
	Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

	187. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 07-Апр-24, 04:16
	> А если x265 с проблемами, то можно пойти по пути гуглокодеков - > смириться с плохим распараллеливанием на уровне энкодера и запускать их одновременно, > скармливая им по куску из видео (заранее разрезать на сцены) (всё > это кое-как автоматизировали в av1an). На самом базовом уровне проблема примерно такая: анализ глобальной избыточности и еще ряд оптимизаций представления проседает от нарезки на тайлы. И чем больше тайлов тем хуже потери. На жирном контенте несколько тайлов которые жуются независимо сильной погоды не делают, но некие лимиты есть. В случае h265 это впрочем не особая проблема - у этого крапа вообще нет толком глобальной коспенсации движения, CDEF и прочих продвинутостей - нельзя потерять то что у него никогда и не было. Однако при убогом формате потока еще и дополнительно нагнуть оптимизации кодирования спорное занятие.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (92), 07-Апр-24, 15:11
	> На жирном контенте несколько тайлов которые жуются независимо сильной погоды не делают, но некие лимиты есть. Но я не про тайлы (независимые части кадра для распараллеливания), а про "чанки", про видео, нарезанное по некоторым кадрам - по некоторым переходам между сценами. Если целиться на определённое качество, а не определённый битрейт, то особых проблем быть не должно. Может, есть смысл в гипотетической конструкции типа "2-й проход - параллельно по чанкам, 1-й - по всему видео, файл со статистикой как-то разрезать", но до такого никто не доходил. > Однако при убогом формате потока еще и дополнительно нагнуть... Я понимаю, что твоя вера сильна, но этот приём принят при кодировании не в H.265, а в гуглокодеках, из-за того, что они плохо параллелятся.
	Ответить | Правка | Наверх | Cообщить модератору

	10. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от нитгитлистер (?), 04-Апр-24, 12:10
	а разве только гугл причастна к разработке всех перечисленных вами форматов?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	12. "Google представил библиотеку jpegli для более эффективного с..."	+3 +/–
	Сообщение от Аноним (127), 04-Апр-24, 12:15
	Почему сразу перешли на полупроводники, а не улучшали электронные лампы с обратной совместимостью? Почему не взлетело — потому что не нужно уже. JPEG без цветовой субдискретизации и так покрывает 99% потребностей, а времена, когда размер картинок был так уж важен, прошли. Впрочем, насчёт WEBP это зря. Его как раз гугл пропихнул.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	14. "Google представил библиотеку jpegli для более эффективного с..."	+3 +/–
	Сообщение от прохожий (?), 04-Апр-24, 12:22
	"времена, когда размер картинок был так уж важен, прошли" Я что-то пропустил, или хранение данных резко подешевело?
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 04-Апр-24, 12:44
	Да, подешевело. Не так резко как хотелось бы, но с 2017 года примерно в 2 раза. С 3 центов на гиг, до примерно 1.5 В 2005 average cost per gigabyte было 65 центов, а в 2000 вообще за гиг приходилось отдавать 12 баксов) С другой стороны кол-во мегапикселей, телефонов с камерами и фотографий "я и моя сарная кошка" увеличилось, причем думаю не пропорцианально)
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Google представил библиотеку jpegli для более эффективного с..."	+3 +/–
	Сообщение от Аноним (127), 04-Апр-24, 12:46
	Соцсеточки всё равно пережмут всё в хлам и уменьшат до пары мегапикселей.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (102), 04-Апр-24, 21:00
	Причем тут хранение, проблема в объемах передаваемых данных. А изображения, помимо огромного куска js кода, которая грузится в сингле пэдж аппликатион, одно из основных объемов по трафику.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	131. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от Аноним (127), 05-Апр-24, 01:45
	Вы из какого года пишете? Основной объём трафика — это видео. Ну так о его ужатии как раз постоянно беспокоятся.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (127), 05-Апр-24, 00:00
	Как раз те, кто хранит гигантские объёмы контента (те же соцсети, например), от жпега отказываться не особо что-то спешат.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	96. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (91), 04-Апр-24, 20:15
	WEBP умеет в сжатие без потерь (lossless) и на этом поле обыгрывает популярный PNG на 20-30%.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	134. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 05-Апр-24, 04:41
	> WEBP умеет в сжатие без потерь (lossless) и на этом поле обыгрывает > популярный PNG на 20-30%. Не забыв при этом угробить цвета в скриншотах в хламину. Такой себе lossless, с subsampling'ом то.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (92), 05-Апр-24, 09:17
	lossless WebP это по сути отдельный кодек, в нём нет chroma subsampling, он не YUV, он RGBA. Но у него та же проблема, что и у lossy WebP - если уж слезать с jpg/png, то на jxl.
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 07-Апр-24, 04:40
	> lossless WebP это по сути отдельный кодек, в нём нет chroma subsampling, > он не YUV, он RGBA. Изначально в первой версии это таки тупо I-frame от VP8. И тот чисто технически ничего кроме YUV с subsampling не умел. В версии 2 вроде попустило, но ее поддержка софтом - в еще большей ж... чем первой версии. > Но у него та же проблема, что и у lossy WebP - если уж слезать с jpg/png, то на jxl. PNG вообще не замена JPG и насколько JXL хорошо дружит с line art и способен в его lossless представление с минимальным размером и без артефактов - это мы еще будем посмотреть.
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (92), 07-Апр-24, 14:45
	Всё-таки первый 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 JXL Lossless-представление с артефактами - всё-таки оксюморон.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Барабас (-), 04-Апр-24, 13:53
	Знаю несколько сайтов, где выкладывали HD-фотки в обычном jpeg, а потом стали конвертить их в webp, качество стало заметно хуже. Не знаю, какой в этом смысл, фотки занимают не так много места, а webp портит качество.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	49. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (49), 04-Апр-24, 14:35
	Скилл ишью. webp жмет по качеству не хуже чем jpeg с таким же параметром качества. Видимо его выкрутили пониже, чтобы жать сильнее, от сайта с hd-фотками в jpeg другого не стоит ожидать.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (118), 04-Апр-24, 14:45
	Вебп цвета прореживает.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Гость (??), 04-Апр-24, 15:21
	У WebP есть много опций сжатия, на которые большинство забивают, ограничиваясь одной цифрой "качества", которая работает совсем не как у jpeg.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (118), 04-Апр-24, 21:29
	> У 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).
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (127), 04-Апр-24, 17:16
	Так жмёт-то он из JPEG. Любой супер-пупер лосси алгоритм на каждом шаге что-то да теряет.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	81. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от namenotfound (?), 04-Апр-24, 18:36
	> а потом стали конвертить их в webp, качество стало заметно хуже потому что дважды пережато > фотки занимают не так много места у тебя. а у них это сохранение денег на хранении и получении доступа к терабайтам данных
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	98. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (91), 04-Апр-24, 20:21
	> webp портит качество Любое lossy-кодирование портит качество, включая JPEG. Пережимать лося в лося -- глупость. Нужно кодировать с одного RAW-источника в JPEG и WEBP, а затем сравнивать. Или не трогать лосей от греха. Не ходите на такие сайты, не пользуйтесь услугами идиотов, до добра это не доводит.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	104. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (118), 04-Апр-24, 21:10
	Например, jpegxl убирает артефакты кодирования jpeg в режиме с потерями и делает картинку визуально чище и приятнее. Понятно, что из q60 скажем q95 уже не получится, но, если исходник больше q95, то иногда вполне применимо, судя по моему опыту. Лично я предпочитаю перепаковывать jpeg в jpegxl, как есть, без сжатия -- это быстрая операция, и позволяет сэкономить ~20-99.9%. А jpeg даже с качеством 100 уже слишком убитый файл, чтобы корёжить его дальше. Но если тебя не уважают и предоставили только файлы с потерями, то тут ничего не поделать.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (118), 04-Апр-24, 21:19
	Кстати, если сравнивать jpegxl в режиме без потерь с типичным png, то, приняв размер файла png за 1, у jpegxl он будет 0.4 в среднем, и, кроме того он по-настоящему без потерь и не потеряет аттрибуты и экзотические цветовые пространства (png всё потеряет, да). Я не понимаю, какие конченные извращуги пропихнули avif в веб вместо него и кто им позволил -- он не конкурент даже webp.
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (179), 06-Апр-24, 15:41
	Вы со своими файлами работаете, на свой страх и риск, вам и карты в руки. А там чужие пачками портят, не глядя.
	Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

	52. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от КО (?), 04-Апр-24, 14:51
	Ну-ну, сравни сжатую мангу в "webp-архиве" с остальными
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	79. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (79), 04-Апр-24, 18:22
	webp вполне себе зашел. Как минимум в тырнете его довольно прилично.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	198. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от GG (ok), 10-Апр-24, 11:58
	webp прекрасно зашли
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Google представил библиотеку jpegli для более эффективного с..."	+/–
Сообщение от нитгитлистер (?), 04-Апр-24, 11:56
я правильно понимаю что эта технология сугубо для веба? или она всётаки в ближайшие полгода перекочует в графические проги?
Ответить | Правка | Наверх | Cообщить модератору

	7. "Google представил библиотеку jpegli для более эффективного с..."	+3 +/–
	Сообщение от Аноним (4), 04-Апр-24, 12:02
	Картинкам надо откуда то браться - появится и в прогах .
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (93), 04-Апр-24, 20:11
	А в поисковой системе Гугл нет картинок? Предполагаю что они это делали сугубо для себя, для экономии места под информацию. Может потому и поделились, чтоб себе любимым упростить работу с сайтами.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от microcoder (ok), 05-Апр-24, 14:31
	Во всех зеркалках и простых мыльницах используется JPEG, теперь есть возможность заменить
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	160. "Google представил библиотеку jpegli для более эффективного с..."	–1 +/–
	Сообщение от Аноним (127), 05-Апр-24, 15:23
	Кто-то покупает зеркалки, чтобы фотографировать в JPEG? А мыльницы фактически вымерли, остались игрушки, там никому не надо заменять JPEG на что-то эффективное.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от microcoder (ok), 05-Апр-24, 15:35
	> Кто-то покупает зеркалки, чтобы фотографировать в JPEG? Конечно, быстрый предпросмотр ещё никому не мешал. А RAW будет долго распаковывать и жрать аккум, что критично для фотика. Не таскать же за собой диз.станцию ))) + Зеркалки могут снимать видосики в MJPEG
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от Аноним (127), 05-Апр-24, 15:50
	Для быстрого предпросмотра на трёхдюймовом экранчике в один мегапиксель эти нюансы пережатия совершенно несущественны.
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от adolfus (ok), 10-Апр-24, 19:14
	Не на трехдюймовом, а на нормальном мониторе. Потому что, пока 20-и мегапиксельный файл на четыре 16-битных канала загрузится, пока из оригинального формата сгенерится тривосьмибитовый RGB для подачи в видеокарту, пройдет куча времени, а мы желаем листать отснятое без ощущаемых задержек в каталогах ФС с сотнями и более фото. Лично я могу с двухчасовой прогулки с детьми принести сотни три фото, которые нужно быстро просмотреть и существенно проредить¸ оставив дюжину, максимум полторы. Вот как раз для этого в RAW'ах (которые есть IFF) содержится чанк с джейпегом.
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (184), 07-Апр-24, 03:04
	Для быстрого предпросмотра в RAW кодируют урезанный вариант в JPEG, thumbnail называется
	Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

3. "Google представил библиотеку jpegli для более эффективного с..."	+3 +/–
Сообщение от Аноним (3), 04-Апр-24, 11:57
Просто праздник какой-то.
Ответить | Правка | Наверх | Cообщить модератору

6. "Google представил библиотеку jpegli для более эффективного с..."	+3 +/–
Сообщение от Аноним (6), 04-Апр-24, 12:00
> В частности, в jpegli задействован адаптивная эвристика квантования, используемая проектом JPEG XL… Только что Гугл пищал, что там ничего интересного и вообще не нужно.
Ответить | Правка | Наверх | Cообщить модератору

9. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
Сообщение от IdeaFix (ok), 04-Апр-24, 12:07
там же жпег2000 был и многие, очень многие решили форкаться...
Ответить | Правка | Наверх | Cообщить модератору

	182. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от InuYasha (??), 06-Апр-24, 21:47
	Он был максимально проприетарным, емнип.
	Ответить | Правка | Наверх | Cообщить модератору

11. "Google представил библиотеку jpegli для более эффективного с..."	–1 +/–
Сообщение от Аноним (11), 04-Апр-24, 12:12
Кто нибудь уже смотрел код? Интересно за счет чего бустится производительность, неужто SIMD используют?
Ответить | Правка | Наверх | Cообщить модератору

	23. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от Аноним (23), 04-Апр-24, 12:49
	SIMD не позволяет увеличить эффективность сжатия, он только скорость сжатия увеличивает
	Ответить | Правка | Наверх | Cообщить модератору

15. "Google представил библиотеку jpegli для более эффективного с..."	–1 +/–
Сообщение от Zenitur (ok), 04-Апр-24, 12:22
Как знал, не переходил на libjpeg8 с libjpeg62! Сейчас заменю libjpeg62 на jpegli. Надеюсь, для сборки не потребуется какой-нибудь meson и llvm? Upd: уже глянул - cmake и clang-7 или новее. Норм, на apt.llvm.org есть готовая сборка LLVM 7 даже для Debian 7. Так что проблем со сборкой не возникнет.
Ответить | Правка | Наверх | Cообщить модератору

	17. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (118), 04-Апр-24, 12:30
	Мань, сабж на плюсах написан. И ты каждый раз бежишь внедрять все сырые поделки корп? Тот же guetzli оказался весьма дорого и крайне не без потерь, libjpeg-turbo хотя бы предсказуема. А что касается jpegxl, то я очень доволен. Кроме того случая, когда все прошлые файлы внезапно оказались битыми (декодируются с зелёными артефактами местами) для всех новых версий библиотеки, совместимость-с.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Zenitur (ok), 04-Апр-24, 12:46
	> И ты каждый раз бежишь внедрять все сырые поделки корп Я делаю домашние сборки некоторого ПО. Вот пример такой сборки: 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.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (118), 04-Апр-24, 13:07
	У плюсов перечень забавных приколов с аби и библиотекой раскрутки стека, это ещё если исключения не используются, такая библиотека менее универсальна и переносима. Зачем тебе чтобы софтина работала быстрее, ценой замены аутентичного компонента на непонятно что с непонятно какими непредсказуемыми последствиями? Наоборот, стоит бороться за сохранение и презервацию аутентичного кода для будущих поколений и тут чем меньше васянства и отклонений от оригинала, тем лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от Аноним (29), 04-Апр-24, 13:12
	>libpng15, который сегодня заменили на libpng16 Очнись! Твое "сегодня" - это сентябрь 2017 года.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	31. "Google представил библиотеку jpegli для более эффективного с..."	–1 +/–
	Сообщение от Zenitur (ok), 04-Апр-24, 13:14
	В RHEL всё ещё libpng15
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (33), 04-Апр-24, 13:24
	Потому что все остальные версии либы насквозь протроянены похуже xz.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от Zenitur (ok), 04-Апр-24, 13:27
	> Потому что все остальные версии либы насквозь протроянены похуже xz. Не, потому что последний RHEL релизнулся хрен знает когда. Я тут загуглил - оказывается, 9-й уже вышел... Я не знал. Тогда в актуальном RHEL уже libpng16. Извиняюсь, был не прав.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от cheburnator9000 (ok), 04-Апр-24, 18:05
	Зенитурушка ты что все старые пакеты всех RPM дистрибутивов у себя хранишь? Их же наверное уже не существует.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Зазнайка (?), 04-Апр-24, 19:42
	Зато существуют у него, у Вас от этого убыло что ли?
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 05-Апр-24, 01:10
	> Зенитурушка ты что все старые пакеты всех RPM дистрибутивов у себя хранишь? > Их же наверное уже не существует. Пусть качнет, чтоли, archive.debian.org себе. Если получится, сможет mirror'ом подрабатывать.
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	153. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Zenitur (ok), 05-Апр-24, 12:56
	> Зенитурушка ты что все старые пакеты всех RPM дистрибутивов у себя хранишь? > Их же наверное уже не существует. От CentOS я нашёл архивные зеркала + RPMFusion. От SLES 11 бэкапил, но пока что бэкап не понадобился: в интернете всё ещё есть пакеты.
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	95. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (93), 04-Апр-24, 20:12
	А в чем проблема с llvm?
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	151. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Zenitur (ok), 05-Апр-24, 12:19
	Обычно я осуществляю сборку в старых дистрах, чтобы бинарник запускался в широком диапазоне 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, и когда она не собралась, я понял, что я что-то запорол в своей системе - причём недавно. А значит, надо смотреть, какие пакеты я устанавливал в систему последними...
	Ответить | Правка | Наверх | Cообщить модератору

18. "Google представил библиотеку jpegli для более эффективного с..."	+2 +/–
Сообщение от uis (??), 04-Апр-24, 12:35
Когда арифметическое кодирование?
Ответить | Правка | Наверх | Cообщить модератору

	61. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от Аноним (92), 04-Апр-24, 15:54
	>  Когда арифметическое кодирование? a) Патенты истекли лет 15 назад, но уже никогда - решили, что распространение таких jpeg'ов вредно из-за несовместимости со старым софтом. b) У себя лично можно давно использовать - пропустить файлы через jpegtran -arithmetic, это lossless-операция. c) А для распространения... Проблема из (a) решается сменой формата файла, чтобы арифметический жипег не выглядел обычным жипегом, но тогда и арифметического кодирования придерживаться не обязательно. Перепаковщиков жипега, работающих таким образом, много: ...jojpeg, packJPG, brunsli, lepton, JPEG-XL. Lossless-перепаковка jpeg'ов - одна из фич JPEG-XL, ему бы ещё поддержку в браузерах.
	Ответить | Правка | Наверх | Cообщить модератору

19. "Google представил библиотеку jpegli для более эффективного с..."	–3 +/–
Сообщение от Аноним (19), 04-Апр-24, 12:37
С сегодняшними скоростями Интернет можно PNG использовать и не париться.
Ответить | Правка | Наверх | Cообщить модератору

	26. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от нах. (?), 04-Апр-24, 13:04
	использовать можно, не париться не получится - гугль еще не написал для него "более эффективного кодировщика" (и, главное - декодировщика). А референсный - тот еще тормоз (и никогда, разумеется, не будет сопоставим с жпегом со своими вейвлетами и прочей заумью)
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (92), 04-Апр-24, 16:22
	Не знаю, при чём тут вейвлеты из старых жипегостандартов, но png ещё можно ускорить распараллеливанием: https://github.com/w3c/PNG-spec/issues/54
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от нах. (?), 04-Апр-24, 22:56
	Можно, но нельзя (потому что это w3c, они не умеют кодить) Ждите пока гугель захочет в png (а он не захочет).
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (127), 05-Апр-24, 00:37
	Там про декодирование, оно проблемой не является. «This would significantly reduce the wall-clock time involved in reading large (8k-32k) PNG files on modern machines» — прямо очень частый кейс, да.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	132. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (92), 05-Апр-24, 02:18
	Тем не менее, Apple такое реализовала. Картинки чаще просматривают, чем сжимают. Причём сжимать обычно нужно много за раз (и однопоточность не мешает), а просматриваются они по одной штуке. Ещё декодирование проблемнее, потому что только для него нужны новые стандартные метаданные. Глядишь, для сканов пригодится. Или нет. Сначала надо убедиться, что скорость fpng и wuffs PNG недостаточна: https://github.com/nigeltao/qoir/blob/main/doc/full_benchmar...
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (127), 05-Апр-24, 15:25
	Да пусть реализуют, спору нет. Просто 99,9% пользователей этого не заметит даже.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Google представил библиотеку jpegli для более эффективного с..."	–1 +/–
	Сообщение от Аноним (126), 05-Апр-24, 00:45
	> использовать можно, не париться не получится - гугль еще не написал для > него "более эффективного кодировщика" (и, главное - декодировщика). А референсный - > тот еще тормоз (и никогда, разумеется, не будет сопоставим с жпегом > со своими вейвлетами и прочей заумью) Они вообще разные. 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. И для чего-то типа скрина с компа - капец полный по цветности.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	133. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (92), 05-Апр-24, 02:34
	Среди оптимизаторов pingo и ECT лидировали. pingo и быстрый, и лучший по степени сжатия, ECT иногда вырывался вперёд на какое-то микроскопическое расстояние. https://css-ig.net/benchmark/png-lossless
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 05-Апр-24, 05:15
	> Среди оптимизаторов pingo и ECT лидировали. pingo и быстрый, и лучший по степени сжатия, С одним маленьким недостаточком - блоб онли варезок, под маздайку. В таком виде он мне нафиг не упал. > ECT иногда вырывался вперёд на какое-то микроскопическое расстояние. С PNG все не так просто: там кроме супер-сжатия еще префильтры есть и в зависимости от его выбора - optipng периодически показывает продвинутым пакерам с ломовым zlib'ом мастеркласс подыскав более удачный префильтр. Разумеется упомянуть этот тонкий момент авторы того блобика немного постеснялись. А суперкомбо ака подобие optimal parsing + брут префильтра таки займет весьма нетривиальное время, и вот нафиг кому пнг на 3% меньше - путем нагрева проца полдня? :) > https://css-ig.net/benchmark/png-lossless Сейчас бы, блин, на сайте автора того блоб онли варезка - смотреть объективные результаты бенчмарков то. Сразу после того как Get The Facts на сайте корпорации Майкрософт дочитаю.
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (92), 05-Апр-24, 09:17
	Не знаю, чего тебя так раскукожило, но: - мне запомнились именно эти две софтины, раньше у меня они показывали себя лучше, чем 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_.../
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (118), 05-Апр-24, 13:03
	Так avif вроде и не лосслесс ни в одном из смыслов. Ну, во всяком случае, libaom говорит, что лосслесс с нужными флагами, но просто раздует файл до невозможности и выдаст очень даже лосси под видом лосслесс (в частности, проредит цвета). Чё они там сравнивали?
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от анонимус (??), 05-Апр-24, 17:25
	Вот не надо, очень даже lossless, а цвета у тебя ломаются потому что надо было читать спецификацию, avif умеет в 8,10 и 12 битность и 400, 422 и 444 сабсэмплинг.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (118), 05-Апр-24, 18:00
	Неа, я прошёлся по всем параметрам кодера. А теперь рассказывай, как у тебя получился lossless avif? Сравнить соответствие оригиналу можешь с magick "${fsrc}" "${file}" -metric PAE -compare -format '%[distortion]' info: и цвета искажает даже со всеми дополнительными параметрами вроде -L -p chroma=444 --matrix_coefficients=0 (что заявлено как лосслесс с rgb).
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от анонимус (??), 05-Апр-24, 21:58
	>что заявлено как лосслесс с rgb вот тут и собака зарыта. avif не умеет в RGB, только в YUV, поэтому и потери в цвете. У jpeg xl этого недостатка нет.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (92), 06-Апр-24, 05:22
	Проблема в твоих руках. Lossless-режим в AV1 сделан для галочки, пользоваться им не надо и раньше баги в реализациях были, но сейчас проблема только в твоих руках. Посмотри на вывод ffprobe, в lossless-режиме yuv444p(бла-бла-бла) должен смениться на gbrp(бла-бла-бла), закодируй правильно, правильно сверь картинки. avifenc --lossless in.png out1.avif ffmpeg -i in.png -aom-params lossless=1 out2.avif ffmpeg -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-битами на канал нужен другой общий знаменатель, очевидно
	Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

	175. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (118), 06-Апр-24, 08:06
	Отмазки пошли. Какой же, к чёрту, это лосслесс тогда? Получается, проблема и не в моих руках вовсе.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (92), 06-Апр-24, 09:40
	...в твоих руках, а ещё глазах (и руках соседнего анонимуса). Если протереть глаза, то там описан процесс для исходника в RGB с 8 битами на канал. Lossy его превратит в YUV. Lossless - нет. Подходящий общий формат для битмапов: "-pix_fmt rgb24".
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (92), 06-Апр-24, 10:09
	И смотри какие чудеса, название забагованного энкодера не указываешь ты, а баг в нём вижу я. https://github.com/strukturag/libheif/issues/62#issuecomment...
	Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

	189. "Google представил библиотеку jpegli для более эффективного с..."	–1 +/–
	Сообщение от Аноним (-), 07-Апр-24, 04:48
	> Не знаю, чего тебя так раскукожило, но: То что совать непонятную проприетарь под винду на ресурсе про открытое ПО - это немного невежливо. И может крепко промазать с адресатом. > - мне запомнились именно эти две софтины, раньше у меня они показывали > себя лучше, чем 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 но их рабочая группа по видео - себя дискредитировала в хлам. Видимо в целом индустрия не очень доверяет и этой группе, хоть они и другие.
	Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

	191. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от Аноним (92), 07-Апр-24, 14:37
	Но тебя перераскукожило до ошибок. С обсуждаемой проприетарью optipng сравнить не можешь, но отвечаешь; свободный fhanau/ECT тоже внимания заслуживает. WebP2 у гугла до сих пор называется "WebP 2: experimental successor" и в сравнении по ссылке с реддита обе версии протестированы же. > Ну просто не в обиду ISO но их рабочая группа по видео - себя дискредитировала в хлам. Видимо в целом индустрия не очень доверяет и этой группе, хоть они и другие. Эта в целом индустрия называется Google и доверяет, конечно, своим WebP, WebP2, AVIF, AVIF@AV2. Но Google ещё, видимо, самодискредитацией занимается, принимая участие в разработке JXL.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от 12yoexpert (ok), 04-Апр-24, 13:49
	согласен, сейчас основной объём - это джаваскрипт
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	53. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от КО (?), 04-Апр-24, 14:51
	Вы не хотите поработать маркетологом?
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	74. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (74), 04-Апр-24, 17:29
	Разработчиком сайтов.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от Гость (??), 04-Апр-24, 15:11
	Сегодня пользователей тоже очень много, с PNG кэши браузеров быстро заполнятся и терабитные каналы забьются. Было бы иначе, всякие инстаграмы не жали бы картинки до предела худшего качества.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

25. "Google представил библиотеку jpegli для более эффективного с..."	+/–
Сообщение от Аноним (25), 04-Апр-24, 13:04
Пытаются оптимизировать йобибайты 100-мегапиксельных селфи в гуглофото... 35% от йобибайта это пара датацентров.
Ответить | Правка | Наверх | Cообщить модератору

35. "Google представил библиотеку jpegli для более эффективного с..."	+/–
Сообщение от Аноним (35), 04-Апр-24, 13:26
Почему jpegli, а не jpeglib?
Ответить | Правка | Наверх | Cообщить модератору

	51. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от google (??), 04-Апр-24, 14:49
	> Почему jpegli, а не jpeglib? у нас в rsx11m имена не 8.3 а только 6.3 (зато 6.3;1 !)
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Самый умный аноним (?), 04-Апр-24, 16:54
	Суффикс li не имеет никакого отношения к lib
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	70. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (35), 04-Апр-24, 17:16
	А к чему имеет?
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Самый умный аноним (?), 04-Апр-24, 19:06
	Такое же как в brotli и zopfli
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Зазнайка (?), 04-Апр-24, 19:45
	library interface?
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (92), 04-Апр-24, 20:39
	уменьшительно-ласкательный суффикс из швейцарско-немецкого диалекта - https://news.ycombinator.com/item?id=39923731
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от Максим (??), 04-Апр-24, 20:59
	А Гугл разве немецкая или швейцарская компания?
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (92), 04-Апр-24, 21:07
	Там отсылают к "In Zürich arbeiten über 5’000 Googler*innen"
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 05-Апр-24, 01:12
	> А Гугл разве немецкая или швейцарская компания? Не, там Jirki Alakuyala (надеюсь правильно написал) - ключевой чувак по компрессии в гугле - откуда-то оттуда. Ну и пошла такая традиция. Вообще что-то типа сортов хлебушков так то.
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

37. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
Сообщение от Аноним (37), 04-Апр-24, 13:28
Не очень понял. Если это новая разработка гугла, почему они её написали на загибающихся плюсах?
Ответить | Правка | Наверх | Cообщить модератору

	40. "Google представил библиотеку jpegli для более эффективного с..."	+8 +/–
	Сообщение от Аноним (35), 04-Апр-24, 13:45
	Наверно потому что С и С++ на данный момент единственные универсальные языки, с помощью которых можно просто сделать свою работу, а не заниматься "высшей алгоритмической акробатикой". А то, что кто-то там загибается - это сказки для Васянов в шортиках на гироскутерах.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от laindono (ok), 05-Апр-24, 08:37
	Это два разных языка, которые на текущий момент имеют лишь историческую связь. Это во первых. А во вторых они как минимум с появления Java перестали быть универсальными. На чистом няшном си всерьёз сейчас пишут только под сильно нестандартные архитектуры. На крестах пишут всякую системную требуху или числодробилки. Это если мы говорим о новых проектах. Разумеется что на одном, что на другом куча готового кода. Переписывать его на другой язык не имеет смысла, кроме случая, когда переписывание требуется само по себе.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (35), 05-Апр-24, 13:26
	> На чистом няшном си всерьёз сейчас пишут только под сильно нестандартные архитектуры Не смеши) На Си и плюсах сейчас дохрена всего пишется. Во-первых, тонны существующих проектов, которые будут существовать ещё минимум лет 50, и это нельзя не учитывать. Во-вторых, новые проекты. Вот пожалуйста, сам ультрапрогрессивный Гугл выкатил абсолютно новый проект на старом-добром С++, а не на каком-нибудь "модном-молодёжном".
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Google представил библиотеку jpegli для более эффективного с..."	–1 +/–
	Сообщение от laindono (ok), 05-Апр-24, 18:56
	Речь о том, что сишечка с крестами являются нишевыми языками по состоянию на 2к24 год. Если ты боишься, что вот прям всё-всё-всё перепишут и у тебя работы не останется, то могу тебя успокоить. С другой стороны яб не назвал всякие Java/C#/Python/JS и кучу другого "модным-молодёжным". Но кучу задач с C/C++ они определённо сняли. Согласись, несколько непродуктивно писать на них, скажем, веб-бекенд или что-то вроде того. Хотя каких-то лет 30 назад это было по крайней мере одним из вариантов.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (169), 05-Апр-24, 18:20
	ну так libjpeg это и есть числодробилка
	Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

	42. "Google представил библиотеку jpegli для более эффективного с..."	+4 +/–
	Сообщение от 12yoexpert (ok), 04-Апр-24, 13:48
	просто гугл из загнивающего запада. логично, что они используют загибающиеся плюсы
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	58. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от Аноним (11), 04-Апр-24, 15:22
	Загибающихся? Лол, уже минимум лет 20 слышно что вот вот и все, выкинем эту вашу сишку с плюсами, ведь буквально завтра придумали новый языкнейм!
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	60. "Google представил библиотеку jpegli для более эффективного с..."	+2 +/–
	Сообщение от Аноним (35), 04-Апр-24, 15:46
	Самое интересное, почему не на Go? Пилили-пилили свой новый язык, который должен был исправить все недостатки языков программирования XX века, а в итоге выкатили новый проект на старом языке :/
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	158. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от microcoder (ok), 05-Апр-24, 14:37
	> Самое интересное, почему не на Go? А почему не на Rust? )))
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (35), 05-Апр-24, 14:55
	Потому что на нём с Си переписывают, а это новая библиотека, исходников на Си нет)
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (169), 05-Апр-24, 18:19
	Go пилили не для того, чтобы исправить все недостатки всех языков, а для того, чтобы был узкоспециализированный язык для удобного написания i/o-bound сервисов с event loop. Чтобы по простоте как nodejs, но по производительности близко к C. В libjpeg это вообще не надо. "Исправить все недостатки" - это к анонимам с опеннета :-)
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	171. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (35), 05-Апр-24, 18:57
	Из Википедии: "Go может рассматриваться как попытка создать замену языкам С и C++ с учётом изменившихся компьютерных технологий и накопленного опыта разработки крупных систем[15]. По словам Роба Пайка[15], «Go был разработан для решения реальных проблем, возникающих при разработке программного обеспечения в Google»" Выходит, что всё-таки хотели создать свой универсальный язык на замену С и С++, но что-то пошло не так...
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от namenotfound (?), 04-Апр-24, 18:38
	потому что там разные команды работают? кому-то проще/привычнее на плюсах писать, наверное
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	87. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (35), 04-Апр-24, 19:29
	Так зачем было давать новый проект староязыковой команде? Пусть они поддерживали бы легаси код. А новую библиотеку можно было бы начать с чистого листа на новом современном языке.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от Зазнайка (?), 04-Апр-24, 19:48
	> Так зачем было давать новый проект древнеязычной команде? //fixed
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от namenotfound (?), 06-Апр-24, 12:37
	> Так зачем было давать новый проект староязыковой команде? Пусть они поддерживали бы > легаси код. А новую библиотеку можно было бы начать с чистого > листа на новом современном языке. почему вы думаете, что у них разделение по языкам? есть команда по кодекам (а скорее даже конкретно по фотокодекам), там в основном людям комфортно писать на плюсах, скорее всего надо будет - перепишут хоть на расте, хоть на жабе, была бы необходимость/желание
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

39. "Google представил библиотеку jpegli для более эффективного с..."	+2 +/–
Сообщение от Аноним12345 (?), 04-Апр-24, 13:38
а нет ли тут бэкдора ?
Ответить | Правка | Наверх | Cообщить модератору

54. "Google представил библиотеку jpegli для более эффективного с..."	+/–
Сообщение от Аноним (54), 04-Апр-24, 15:03
> Повышение уровня сжатия достигается применением продвинутых технологий для сокращения шумов на изображении и увеличения качества, использующих более эффективные методы психовизуального моделирования для уменьшения возникающих артефактов. Перевожу: у вас будут рисунки вместо фотографий. Ведь вы этого достойны...
Ответить | Правка | Наверх | Cообщить модератору

64. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
Сообщение от DEF (?), 04-Апр-24, 16:22
MozJPEG больше не нужен?
Ответить | Правка | Наверх | Cообщить модератору

86. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
Сообщение от Аноним (86), 04-Апр-24, 19:16
Так jpegli входит в jpeg-xl
Ответить | Правка | Наверх | Cообщить модератору

109. "Google представил библиотеку jpegli для более эффективного с..."	+/–
Сообщение от голос из леса (?), 04-Апр-24, 23:06
>> методы психовизуального моделирования для уменьшения возникающих артефактов. А можно вообще ИИ генерить, пофигу что там в исходнике было. Пользователь только спасибо скажет и еще с лопаты слижет.
Ответить | Правка | Наверх | Cообщить модератору

	117. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (127), 05-Апр-24, 00:03
	Ну да, в стандартной-то жпеговской мазне любой пользователь с ходу определяет, что там было.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Аноним (-), 05-Апр-24, 05:24
	> Ну да, в стандартной-то жпеговской мазне любой пользователь с ходу определяет, что > там было. А что, нет чтоли? Это тебе любой фильм про шпионов подтвердит! Видишь - там за километр авто, номер размером с прыщик? А вот раз, раз, раз, digital enhancement - и вот уже вместо мазни вполне себе како-нибудь х123ер. Правда, злые языки поговаривают что секретная экспериментальная технология недопилена - и работает почему-то только в фильмах :)
	Ответить | Правка | Наверх | Cообщить модератору

143. "Google представил библиотеку jpegli для более эффективного с..."	+/–
Сообщение от penetrator (?), 05-Апр-24, 08:14
протестил я алгоритм на реальных картинках для сайта, мыло мыльное даже на большем размере, чем то что пожато другим энкодером
Ответить | Правка | Наверх | Cообщить модератору

	149. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от devl547 (ok), 05-Апр-24, 11:31
	>мыло мыльное Зато от артефактов классического жипега ушли, да. Это собственно особенность всех современных форматов - они дают мыло вместо блоков, это хорошо видно на всяких сравнениях.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Google представил библиотеку jpegli для более эффективного с..."	+2 +/–
	Сообщение от Аноним (35), 05-Апр-24, 13:02
	Лучше уж артефакты, чем мыло. К артефактам глаз уже привых и они особо не мешают, а когда мыло, то кажется, что у тебя или с глазами, или с монитором что-то - нечёткое изображение.
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Google представил библиотеку jpegli для более эффективного с..."	+1 +/–
	Сообщение от penetrator (?), 08-Апр-24, 17:24
	на тех размерах что тестировал, артефактов нет или они незаметны без увеличения, а вот потеря деталей на новых алгоритмах очень сильно заметна, картинка получается "мертвая", пластиковая, так мало того, еще и выходной файл больше получался чем у прошлого моего энкодера на 10-20%, а иначе еще больше несоотвествий с оригиналом и проигрыш предыдущему энкодеру так что очень советую тестировать самому, а не хайп ловить, энкодер неплох, но есть лучше
	Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

	183. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от InuYasha (??), 06-Апр-24, 21:49
	Интересно. А со старымы декомпрессорами оно, кстати, совместимо?
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

150. "Google представил библиотеку jpegli для более эффективного с..."	+/–
Сообщение от Scondo (?), 05-Апр-24, 12:02
Меня одного пугает указание на "использование собственного декодировщика приводит к снижению артефактов"? Или EEE только от микрософт проблема?
Ответить | Правка | Наверх | Cообщить модератору

164. "Google представил библиотеку jpegli для более эффективного с..."	+/–
Сообщение от Аноним (164), 05-Апр-24, 16:08
Зачем гугля возится с жыпег-XL? Есть же типа "преемники" - WebP и AVIF - с ними чо, ОПЯТЬ какие-то проблемы?
Ответить | Правка | Наверх | Cообщить модератору

	172. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от DZgas (?), 05-Апр-24, 20:43
	мы живём в мире, когда скриншоты смартфонов делают в JPEG по той причине, что они 2к в высоту, и при открытии предпросмотра галереи должны мгновенно декодироваться и отображаться ни один формат этого не может. Apple в свои HEIF вшивают привью предпросмотра отдельной кртинкой
	Ответить | Правка | Наверх | Cообщить модератору

165. "Google представил библиотеку jpegli для более эффективного с..."	–2 +/–
Сообщение от Аноним (165), 05-Апр-24, 16:53
Корпоративная шизофрения. Один отдел развивает JPEG XL, второй - выпиливает его отовсюду, дабы подгадить первому.
Ответить | Правка | Наверх | Cообщить модератору

181. "Google представил библиотеку jpegli для более эффективного с..."	+/–
Сообщение от Sylvia (ok), 06-Апр-24, 20:20
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 гигов памяти
Ответить | Правка | Наверх | Cообщить модератору

	195. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от devl547 (ok), 08-Апр-24, 22:29
	>PS: гусля час пыхтел сожрав 12 гигов памяти Просто надо было guetzli-cuda-opencl собирать и запускать, она достаточно быстро работает.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Google представил библиотеку jpegli для более эффективного с..."	+/–
	Сообщение от Sylvia (ok), 09-Апр-24, 22:54
	в то время как обычный даже многопоточность не умеет и в принципе заброшен, ведь в гугле занимаются всем подряд и бросают без сожаления, хотя некоторые наработки интересны. Возможно и JPEGLI ждет та же судьба
	Ответить | Правка | Наверх | Cообщить модератору

196. "Google представил библиотеку jpegli для более эффективного с..."	+/–
Сообщение от MihaNix (ok), 09-Апр-24, 03:49
Как правильно использовать эти утилиты? Я решил проверить это на фотографиях и сканах документов. Из формата png конвертировал в jpeg. Был удивлен, что у меня после обработки libjpeg-62 файлы имеют меньший объем, чем после сжатия с помощью данной библиотеки от гугла. Это касается практически всех проверенных файлов. Ожидаемого результата не достиг.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема