1.1, Аноним (1), 11:50, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
Ни webp, ни avif, ни jpeg-xl до сих пор не зашли... Удивительно, почему сразу не могли улучшать обычный jpeg, с обратной совместимостью?
|
|
|
2.4, Аноним (4), 11:59, 04/04/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
Так потому и улучшают что альтернативно одарённые навязать не удаётся .
|
|
|
3.30, Аноним (30), 13:13, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Так потому и улучшают что альтернативно одарённые навязать не удаётся .
Софт порой инерционен с поддержкой. Попробуйте анимированый webp вообще открыть чем?! Кроме хрома/файрфокса, конечно. И как, получается? Даже с анимацией? И всех версий webp? А чтоб еще и отредактировать анимаху и разобрать на фреймы - слабо?! Не, это даже ffmpeg не сожрет с его более 9000 форматов. Вот скроить это может - но билет в одну сторону! А потом это только в хроме и лисе и смотреть. И все, по сути. Write-only формат. Оказывается так можно было.
|
|
|
2.5, DZgas (?), 12:00, 04/04/2024 [^] [^^] [^^^] [ответить]
| +4 +/– |
Потому что сначала надо было придумать эти avif webp jpeg XL что бы брать от туда технологии, которые можно применить в jpeg
Точно так же как с AQ-3 из HEVC в AVC
Или та же технология butteraugli придуманная для jpeg XL и далее используемая в другом гугл jpeg кодировщике guetzli
|
|
|
3.8, Аноним (4), 12:04, 04/04/2024 [^] [^^] [^^^] [ответить]
| –3 +/– |
Фичи можно было изначально для джпега разрабатывать , без прокладок и памперсов .
|
|
|
4.24, Аноним (24), 13:00, 04/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
> без прокладок и памперсов
А как ты тогда тут комментить будешь?
|
|
|
3.13, Аноним (1), 12:16, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Точно так же как с AQ-3 из HEVC в AVC
Можно подробнее? В интернете мало инфы.
|
|
|
2.12, Аноним (12), 12:15, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Почему сразу перешли на полупроводники, а не улучшали электронные лампы с обратной совместимостью?
Почему не взлетело — потому что не нужно уже. JPEG без цветовой субдискретизации и так покрывает 99% потребностей, а времена, когда размер картинок был так уж важен, прошли.
Впрочем, насчёт WEBP это зря. Его как раз гугл пропихнул.
|
|
|
3.14, прохожий (?), 12:22, 04/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
"времена, когда размер картинок был так уж важен, прошли"
Я что-то пропустил, или хранение данных резко подешевело?
|
|
|
4.20, Аноним (-), 12:44, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Да, подешевело.
Не так резко как хотелось бы, но с 2017 года примерно в 2 раза.
С 3 центов на гиг, до примерно 1.5
В 2005 average cost per gigabyte было 65 центов, а в 2000 вообще за гиг приходилось отдавать 12 баксов)
С другой стороны кол-во мегапикселей, телефонов с камерами и фотографий "я и моя сарная кошка" увеличилось, причем думаю не пропорцианально)
|
|
|
5.22, Аноним (12), 12:46, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Соцсеточки всё равно пережмут всё в хлам и уменьшат до пары мегапикселей.
|
|
|
|
|
2.46, Барабас (-), 13:53, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Знаю несколько сайтов, где выкладывали HD-фотки в обычном jpeg, а потом стали конвертить их в webp, качество стало заметно хуже. Не знаю, какой в этом смысл, фотки занимают не так много места, а webp портит качество.
|
|
|
3.49, Аноним (49), 14:35, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Скилл ишью. webp жмет по качеству не хуже чем jpeg с таким же параметром качества. Видимо его выкрутили пониже, чтобы жать сильнее, от сайта с hd-фотками в jpeg другого не стоит ожидать.
|
|
|
|
1.2, нитгитлистер (?), 11:56, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
я правильно понимаю что эта технология сугубо для веба? или она всётаки в ближайшие полгода перекочует в графические проги?
|
|
1.6, Аноним (6), 12:00, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
> В частности, в jpegli задействован адаптивная эвристика квантования, используемая проектом JPEG XL…
Только что Гугл пищал, что там ничего интересного и вообще не нужно.
|
|
1.11, Аноним (11), 12:12, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Кто нибудь уже смотрел код? Интересно за счет чего бустится производительность, неужто SIMD используют?
|
|
|
2.23, Аноним (23), 12:49, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
SIMD не позволяет увеличить эффективность сжатия, он только скорость сжатия увеличивает
|
|
|
1.15, Zenitur (ok), 12:22, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Как знал, не переходил на libjpeg8 с libjpeg62! Сейчас заменю libjpeg62 на jpegli. Надеюсь, для сборки не потребуется какой-нибудь meson и llvm?
Upd: уже глянул - cmake и clang-7 или новее. Норм, на apt.llvm.org есть готовая сборка LLVM 7 даже для Debian 7. Так что проблем со сборкой не возникнет.
|
|
|
2.17, Аноним (50), 12:30, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Мань, сабж на плюсах написан. И ты каждый раз бежишь внедрять все сырые поделки корп? Тот же guetzli оказался весьма дорого и крайне не без потерь, libjpeg-turbo хотя бы предсказуема. А что касается jpegxl, то я очень доволен. Кроме того случая, когда все прошлые файлы внезапно оказались битыми (декодируются с зелёными артефактами местами) для всех новых версий библиотеки, совместимость-с.
|
|
|
3.21, Zenitur (ok), 12:46, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> И ты каждый раз бежишь внедрять все сырые поделки корп
Я делаю домашние сборки некоторого ПО. Вот пример такой сборки:
https://github.com/OpenXRay/xray-16/files/14234005/S.T.A.L.K.E.R.-.Call.of.Pri
Свои сборки линкую с libpng12 и libjpeg62. Я выбрал их для совместимости: эти версии библиотек у всех есть (в отличие от libpng15, который сегодня заменили на libpng16, а завтра заменят на libpng17).
Однако хочется же с libjpeg8 слинковаться? Чтобы софтина работала быстрее. Но вдруг у юзера нет этой библиотеки? Я понимаю что "стандарт де-факто", но вдруг завтра поломают ABI и выпустят libjpeg9? Такое уже было с libjpeg7.
Поэтому я сейчас положу в архив с моей сборкой - сабж. Он такой же быстрый, как libjpeg8, но при этом имеет прежний ABI libjpeg62.
|
|
|
4.28, Аноним (50), 13:07, 04/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
У плюсов перечень забавных приколов с аби и библиотекой раскрутки стека, это ещё если исключения не используются, такая библиотека менее универсальна и переносима. Зачем тебе чтобы софтина работала быстрее, ценой замены аутентичного компонента на непонятно что с непонятно какими непредсказуемыми последствиями? Наоборот, стоит бороться за сохранение и презервацию аутентичного кода для будущих поколений и тут чем меньше васянства и отклонений от оригинала, тем лучше.
|
|
4.29, Аноним (29), 13:12, 04/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
>libpng15, который сегодня заменили на libpng16
Очнись! Твое "сегодня" - это сентябрь 2017 года.
|
|
|
|
6.33, Аноним (34), 13:24, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Потому что все остальные версии либы насквозь протроянены похуже xz.
|
|
|
7.36, Zenitur (ok), 13:27, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Потому что все остальные версии либы насквозь протроянены похуже xz.
Не, потому что последний RHEL релизнулся хрен знает когда. Я тут загуглил - оказывается, 9-й уже вышел... Я не знал.
Тогда в актуальном RHEL уже libpng16. Извиняюсь, был не прав.
|
|
|
|
|
|
|
|
1.19, Аноним (19), 12:37, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
С сегодняшними скоростями Интернет можно PNG использовать и не париться.
|
|
|
2.26, нах. (?), 13:04, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
использовать можно, не париться не получится - гугль еще не написал для него "более эффективного кодировщика" (и, главное - декодировщика). А референсный - тот еще тормоз (и никогда, разумеется, не будет сопоставим с жпегом со своими вейвлетами и прочей заумью)
|
|
|
1.25, Аноним (25), 13:04, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Пытаются оптимизировать йобибайты 100-мегапиксельных селфи в гуглофото... 35% от йобибайта это пара датацентров.
|
|
|
2.51, google (??), 14:49, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Почему jpegli, а не jpeglib?
у нас в rsx11m имена не 8.3 а только 6.3 (зато 6.3;1 !)
|
|
|
1.37, Аноним (37), 13:28, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Не очень понял. Если это новая разработка гугла, почему они её написали на загибающихся плюсах?
|
|
|
2.40, Аноним (35), 13:45, 04/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Наверно потому что С и С++ на данный момент единственные универсальные языки, с помощью которых можно просто сделать свою работу, а не заниматься "высшей алгоритмической акробатикой". А то, что кто-то там загибается - это сказки для Васянов в шортиках на гироскутерах.
|
|
2.42, 12yoexpert (ok), 13:48, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
просто гугл из загнивающего запада. логично, что они используют загибающиеся плюсы
|
|
|
1.41, 12yoexpert (ok), 13:47, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
почему не на раст? о чём думали разработчики? о том, чтобы это работало и не жрало ресурсы? абсурд
|
|
|