Hacker News Digest

Для сжатия фотографий с потерями в вебе AVIF почти всегда даёт файлы меньше, чем JPEG XL: при настройках усилия по умолчанию лучший результат JPEG XL обычно на 15–25% больше, а при максимальных настройках разрыв сокращается до 6–20%. Бывают исключения, где JPEG XL близок к AVIF или даже обгоняет его, поэтому для конкретного изображения стоит пробовать оба формата. Для скриншотов и иллюстраций AVIF заметно лучше: эквивалентный JPEG XL больше на 30–90% при обычных настройках и на 20–70% при максимальных. Для изображений с прозрачностью AVIF тоже выигрывает: версия libjxl больше на 31–44% и 61–70% соответственно, а jixel всегда кодирует прозрачность без потерь, из-за чего файлы в 2–3 раза крупнее, чем у AVIF.

Выбор кодера JPEG XL сильно влияет на результат: новый jixel обычно даёт меньшие файлы, чем libjxl, кроме изображений с детальной прозрачностью. AVIF в целом быстрее кодируется и требует меньше памяти с учётом размера файла, а декодируется в 2–3 раза быстрее JPEG XL при среднем качестве, хотя на очень высоких качествах разрыв сокращается. Повышенные настройки усилия оправданы для AVIF и jixel, но не для libjxl: они намного медленнее, расходуют больше памяти и почти не улучшают результат, иногда даже увеличивая файл. Режим 4:2:0 у AVIF не стоит делать значением по умолчанию — он редко уменьшает размер и затрудняет достижение высокого качества, хотя быстрее кодируется и декодируется; лучше использовать 4:4:4. Настройки качества работают надёжно у всех кодеров.

Анимированный AVIF по сути представляет собой переупаковку видео AV1 — MP4 можно преобразовать в AVIF и обратно без потерь, поэтому он так хорошо работает с движением. Однако в Chrome и Safari он воспроизводится плохо, хотя в Firefox всё в порядке: это чисто проблема реализации. При этом анимированный AVIF поддерживает прозрачность, чего нет у видео AV1.

Обсуждение дополняет статью практическими данными о качестве энкодеров, проблемами рендеринга в браузерах и специфическими сценариями использования (анимации, HDR, архивация), при этом подтверждая преимущество AVIF в размере файлов для веба.

• Спор: Пользователь @PaulHoule заметил потерю деталей в бликах на фото F1 в AVIF, однако @jaffathecake пояснил, что это было вызвано некорректной работой WASM-рендерера в браузере без поддержки JPEG XL, а не самим форматом.

• Спор: По мнению @linolevan, текущие энкодеры JPEG XL недостаточно оптимизированы: использование более качественного энкодера позволило ему уменьшить размер lossless-скриншота на 39% и иллюстрации на 30% по сравнению с результатами в статье.

• Совет: Для достижения максимального сжатия AVIF с сохранением прозрачности PNG @Metricon рекомендует использовать ffmpeg с параметрами: libaom-av1, crf 25, cpu-used 3 и специфическими настройками sharpness и chroma-deltaq.

• AVIF считается более подходящим форматом для замены GIF и создания анимаций с прозрачностью, так как он фактически является переупакованным видео AV1, оптимизированным под движение.

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

• Совет: По опыту @yhjc2692, медленная работа libjxl на высоких настройках (efforts >7) связана с итеративной оптимизацией метрики Butteraugli; для ускорения процесса он разработал GPU-порт gjxl (CUDA/Metal).

• AVIF выигрывает на маленьких изображениях, в то время как JPEG XL предпочтительнее для lossless-сжатия, высокобитрейтных изображений и прогрессивного рендеринга.

• Контейнерная архитектура AVIF может упростить будущий переход на новые кодеки (AV2, AV3) без необходимости повторного внедрения формата на сайтах.

I think people are really forgetting that JXL's encoders are bad right now. For instance, in TFA Jake presents- The Firefox screenshot w/ lossless JXL at 66.9kB, when with a better encoder you get get it down to like 40.7kB (39% smaller) — @linolevan

Перевод: Мне кажется, люди забывают, что энкодеры JXL сейчас работают плохо. Например, в статье Джейк приводит скриншот Firefox с lossless JXL размером 66,9 кБ, в то время как с более качественным энкодером его можно сжать до 40,7 кБ (на 39% меньше).

Исследователи из Hacktron обнаружили цепочку уязвимостей, позволившую им получить доступ к внутренним репозиториям OpenAI через компрометацию учётных записей сотрудников в ChatGPT и Codex. Атака началась с уязвимости переполнения кучи в библиотеке libheif, используемой для декодирования изображений формата HEIF/AVIF, которая присутствовала в устаревшей версии пакета в Docker-образе Discourse, форума OpenAI (community.openai.com). Через загрузку вредоносного изображения attackers достигли удалённого выполнения кода на форуме, что позволило им захватить сессии пользователей, включая сотрудников OpenAI, благодаря неправильной конфигурации единого входа (SSO) через auth.openai.com. Получив доступ к учётным записям ChatGPT и Codex, они использовали интеграцию с GitHub для создания пул-реквеста #1186742 во внутреннем монолитном репозитории openai/openai, тем самым доказав факт компрометации без доступа к敏感ным данным. Всё от первоначального обнаружения до подтверждения доступа заняло менее 72 часов. Уязвимость была оперативно закрыта после ответственного раскрытия, за которое исследователи получили вознаграждение в размере 6500 долларов. Они подчеркивают, что libheif является широко используемой библиотекой, и любые системы, обрабатывающие пользовательские изображения в форматах HEIC/HEIF/AVIF, потенциально уязвимы, рекомендуя обновлять зависимости и изолировать обработку изображений в песочницах. SaaS-пользователи Discourse уже защищены, но самодостаточным установкам необходимо пересобрать образ с исправленными пакетами.

Обсуждение дополняет статью, раскрывая критические проблемы безопасности OpenAI: использование уязвимых C-библиотек, слабые практики обновления пакетов, неправильную изоляцию сервисов и заниженные выплаты по программе баг-баунти ($6,500 за компрометацию внутренних репозиториев несоразмерны капитализации компании в $1.2 трлн и потенциальному ущербу). Основные рекомендации и выводы: * **Работа с медиаданными:** Зависимость веб-сервисов от небезопасных нативных библиотек (libheif, libpng, ImageMagick, ffmpeg) создает системные риски. Рекомендуется использовать простые JPEG вместо HEIF/AVIF, заменять C-библиотеки на Rust и внедрять многоуровневую защиту (defense in depth), так как патчинг отдельных уязвимостей не исключает появления новых. * **Изоляция и архитектура:** Для защиты внешних бинарников рекомендуется использовать landlock-сандбокс и переход на Vips (опыт Discourse). Следует ограничить интеграции ChatGPT/Codex с внешними сервисами (GitHub, Slack, email), чтобы сократить поверхность атаки. * **Инфраструктура и доступ:** Использование публичного GitHub для внутренних репозиториев недопустимо для компании со стратегически ценным IP; необходимы внутренние сети или VPN. Сотрудники-клиенты должны иметь строго ограниченные учетные записи, изолированные от обычных пользователей. * **Обновления и CVE:** Самохостинг требует еженедельных обновлений из-за высокой скорости появления CVE. Важно помнить, что не все уязвимости получают CVE, и многие исправления в upstream-репозиториях не помечаются как безопасные, что ведет к пропуску бэкпортов в дистрибутивах. * **Влияние AI:** Использование моделей для эксплуатации уязвимостей требует пересмотра подходов к безопасности. Существует спор: одни полагают, что LLM помогут быстро найти все RCE и сделать ПО безопаснее, другие — что это лишь ускорит атаки. Также обсуждается целесообразность использования AI для аудита собственной безопасности при риске манипуляции моделями для создания эксплойтов.

JPEG XL — технически впечатляющий кодек, превосходящий JPEG и более универсальный, чем WebP, но его место в браузерах под вопросом. Хотя он был отклонён Chrome в 2023 году, появление Rust-декодера в Firefox и Chrome может сигнализировать о пересмотре позиции, особенно на фоне уязвимости WebP 2023 года. Однако автор, ранее поддерживавший JPEG XL, теперь считает, что его преимущества для веба исчерпаны. По объёму веб-контента подавляющее большинство изображений обслуживается с потерями, а без потерь JPEG XL выигрывает лишь около 11,9% перед WebP — на искусственном наборе данных (157 Мп фото, 10 Мп иллюстраций, 27 Мп книг), неrepresenting типичный веб. Это слишком мало, чтобы оправдать внедрение нового кодекса в браузеры, особенно учитывая, что в lossy-сжатии JPEG XL уступает конкурентам.

Современные энкодеры, включая AV1, достигли лучшего соотношения скорости и качества на бит благодаря perceptual tuning на основе человеческих испытаний. AVIF теперь доминирует во всём диапазоне fidelity, нивелируя единственное реальное преимущество JPEG XL. Автор отмечает, что дискуссия вокруг JPEG XL часто отражает желание большего выбора для разработчиков, а не техническую необходимость, особенно на фоне политики вокруг Google и AV1. Тем не менее, JPEG XL остаётся ценным для профессиональных сценариев вне веба — фотографии, печать, медицинская визуализация — где его возможности могут быть востребованы. В браузерах же его внедрение сейчас не кажется оправданным.

Обсуждение подтверждает сомнения автора в перспективах JPEG XL для веба, добавляя данные о производительности, сложности реализации и ограничениях аппаратного декодирования, а также подчёркивая политические и патентные факторы, влияющие на его принятие, но указывает на потенциальные ниши в профессиональном фото‐ и RAW‐рабочем процессе. libjxl и cjpegli позволяют получать компактные, высококачественные изображения даже для контента с высоким частотным спектром, например комиксов, где другие кодеки требуют компромиссов. WebP‐lossless ограничен 8‐битным RGB, поэтому отдельный формат для истинно lossless‐изображений остаётся необходимым. JXL‐preview в macOS сильно нагружает процессор и память из‐за вычисления «prime», что делает его потенциальным вектором DoS даже для небольших файлов. JXL выигрывает в lossless‐сжатии над WebP и PNG, но в lossy‐режиме часто уступает AVIF и даже обычному JPEG. Аппаратные декодеры AVIF ограничены профилем Main (4:2:0), что делает его менее подходящим для фотосъёмки, где предпочтителен 4:4:4 и 10‐бит. Спор: Некоторые считают, что отсутствие поддержки браузерами препятствует использованию JXL вне веба, в то время как другие указывают, что основные сценарии (например, отправка фото по e‐mail) всё равно требуют транс‐кодирования. Спор: Вопрос открытости: JXL полностью открытый, тогда как AVIF основан на AV1, который хотя и royalty‐free, но имеет патентные споры (Sisvel/Access, Dolby vs Snap), что меняет баланс сравнения. Камеры пока не поддерживают JPEG XL; поддержка ограничивается HEIF, а JPEG остаётся доминирующим форматом из‐за совместимости. Adobe включил JPEG XL в PDF, что может заставить браузеры добавить поддержку формата для корректного отображения PDF‐документов. Совет: Для веб‐публикаций рекомендуется удалять метаданные и транскодировать в уже поддерживаемый формат, поскольку экономия трафика от JXL не компенсирует совместимостиных проблем.