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 формат. Оказывается так можно было.
| |
|
|
|
|
|
8.80, Аноним (80), 18:28, 04/04/2024 [^] [^^] [^^^] [ответить] | –3 +/– | В телеграмме ты сам можешь управлять уровнем приватности Можешь пользоваться об... текст свёрнут, показать | |
|
|
10.93, Аноним (93), 20:08, 04/04/2024 [^] [^^] [^^^] [ответить] | –1 +/– | Протокол открыт и это факт Мне как-то коллега по работе уши прожужжал о его без... текст свёрнут, показать | |
|
9.110, Аноним (-), 23:30, 04/04/2024 [^] [^^] [^^^] [ответить] | +/– | Судя по количеству посаженных телеграмеров - с телеграмом ты можешь сам сесть на... большой текст свёрнут, показать | |
|
8.120, Аноним (120), 00:32, 05/04/2024 [^] [^^] [^^^] [ответить] | +/– | Ага, Паша так взял и дал ФСБ доступ, он не просто так отсюда уехал после истории... текст свёрнут, показать | |
|
|
|
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 формата и проч норм работает во всех комбо? Но посмотреть то можно и в браузере накрайняк. А вот разобрать допустим на фреймы или в другой формат это переделать... ээээ... :))
| |
|
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.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 качество кодирования улетает в пол.
| |
|
|
|
10.186, Аноним (-), 03:33, 07/04/2024 [^] [^^] [^^^] [ответить] | +/– | Это все - абстрактные блабла И вот что-что а AV1 в раздувании битрейта я бы уж ... большой текст свёрнут, показать | |
|
|
|
7.123, Аноним (92), 00:37, 05/04/2024 [^] [^^] [^^^] [ответить] | +/– | Но это ведь не замена, это фильтры для удаления такого-то шума в таких-то исходн... большой текст свёрнут, показать | |
|
8.187, Аноним (-), 04:16, 07/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 другого не стоит ожидать.
| |
|
|
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 вполне себе зашел. Как минимум в тырнете его довольно прилично.
| |
|
1.2, нитгитлистер (?), 11:56, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
я правильно понимаю что эта технология сугубо для веба? или она всётаки в ближайшие полгода перекочует в графические проги?
| |
|
|
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.6, Аноним (6), 12:00, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
> В частности, в jpegli задействован адаптивная эвристика квантования, используемая проектом JPEG XL…
Только что Гугл пищал, что там ничего интересного и вообще не нужно.
| |
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 года.
| |
|
|
6.33, Аноним (33), 13:24, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Потому что все остальные версии либы насквозь протроянены похуже xz.
| |
|
7.36, Zenitur (ok), 13:27, 04/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Потому что все остальные версии либы насквозь протроянены похуже xz.
Не, потому что последний RHEL релизнулся хрен знает когда. Я тут загуглил - оказывается, 9-й уже вышел... Я не знал.
Тогда в актуальном RHEL уже libpng16. Извиняюсь, был не прав.
| |
|
|
|
|
|
|
3.151, Zenitur (ok), 12:19, 05/04/2024 [^] [^^] [^^^] [ответить] | +/– | Обычно я осуществляю сборку в старых дистрах, чтобы бинарник запускался в широко... большой текст свёрнут, показать | |
|
|
|
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 [^] [^^] [^^^] [ответить]
| +/– |
использовать можно, не париться не получится - гугль еще не написал для него "более эффективного кодировщика" (и, главное - декодировщика). А референсный - тот еще тормоз (и никогда, разумеется, не будет сопоставим с жпегом со своими вейвлетами и прочей заумью)
| |
|
|
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 для скриншотов, доков, схем, чертежей и... большой текст свёрнут, показать | |
|
|
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.174, Аноним (92), 05:22, 06/04/2024 [^] [^^] [^^^] [ответить] | +/– | Проблема в твоих руках Lossless-режим в AV1 сделан для галочки, пользоваться им... большой текст свёрнут, показать | |
|
7.189, Аноним (-), 04:48, 07/04/2024 [^] [^^] [^^^] [ответить] | –1 +/– | То что совать непонятную проприетарь под винду на ресурсе про открытое ПО - это ... большой текст свёрнут, показать | |
|
8.191, Аноним (92), 14:37, 07/04/2024 [^] [^^] [^^^] [ответить] | +1 +/– | Но тебя перераскукожило до ошибок С обсуждаемой проприетарью optipng сравнить н... текст свёрнут, показать | |
|
|
|
|
|
|
2.55, Гость (??), 15:11, 04/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Сегодня пользователей тоже очень много, с PNG кэши браузеров быстро заполнятся и терабитные каналы забьются. Было бы иначе, всякие инстаграмы не жали бы картинки до предела худшего качества.
| |
|
1.25, Аноним (25), 13:04, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Пытаются оптимизировать йобибайты 100-мегапиксельных селфи в гуглофото... 35% от йобибайта это пара датацентров.
| |
|
2.51, google (??), 14:49, 04/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Почему jpegli, а не jpeglib?
у нас в rsx11m имена не 8.3 а только 6.3 (зато 6.3;1 !)
| |
|
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 назад это было по крайней мере одним из вариантов.
| |
|
|
|
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 века, а в итоге выкатили новый проект на старом языке :/
| |
|
|
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.178, namenotfound (?), 12:37, 06/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Так зачем было давать новый проект староязыковой команде? Пусть они поддерживали бы
> легаси код. А новую библиотеку можно было бы начать с чистого
> листа на новом современном языке.
почему вы думаете, что у них разделение по языкам? есть команда по кодекам (а скорее даже конкретно по фотокодекам), там в основном людям комфортно писать на плюсах, скорее всего
надо будет - перепишут хоть на расте, хоть на жабе, была бы необходимость/желание
| |
|
|
|
1.54, Аноним (54), 15:03, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Повышение уровня сжатия достигается применением продвинутых технологий для сокращения шумов на изображении и увеличения качества, использующих более эффективные методы психовизуального моделирования для уменьшения возникающих артефактов.
Перевожу: у вас будут рисунки вместо фотографий. Ведь вы этого достойны...
| |
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%, а иначе еще больше несоотвествий с оригиналом и проигрыш предыдущему энкодеру
так что очень советую тестировать самому, а не хайп ловить, энкодер неплох, но есть лучше
| |
|
|
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 файлы имеют меньший объем, чем после сжатия с помощью данной библиотеки от гугла. Это касается практически всех проверенных файлов.
Ожидаемого результата не достиг.
| |
|