JPEG-XL повертається до роботи

Багато звичних нам форматів зображень існують десятиліттями. Всі добре знають JPEG і PNG, а GIF навіть пережив своєрідний ренесанс, коли маленькі надокучливі зациклені анімації знову стали модними в соціальних мережах. Однак зростає і кількість нових форматів, таких як WEBP та AVIF, які різні платформи та компанії впроваджують заради кращої ефективності, продуктивності та якості зображень.

Серед нових форматів, що претендують на актуальність, — JPEG XL. Його позиціонували як формат, що покращив можливості JPEG у стисненні з втратами, додавши також режим стиснення без втрат. Були великі сподівання, що він стане універсальною заміною для всіх існуючих растрових форматів в Інтернеті. Основною проблемою здавалося те, що Google, здавалося, був проти нього, але потім змінив позицію — і тепер формат має вийти на великий рівень з оновленою підтримкою від гігантського пошукового двигуна. Тож що відбувається?

Вам JPEG-нули

Стандарт JPEG XL є сучасним, але аж ніяк не новим. Він був вперше випущений 13 жовтня 2021 року, розроблений консорціумом Joint Photographic Experts Group, Google та Cloudinary. Він базується на попередніх напрацюваннях Jon Sneyers щодо універсального формату зображень Free Universal Image Format (FUIF) та роботах Google над форматом PIK.

Було вирішено, що результатний формат використовуватиме розширення файлу *.jxl. Специфікація визначила формат із широким спектром функцій, що значно перевершують можливості класичного JPEG. Він має стиснення без втрат, включно з альфа-каналом, а також стиснення з втратами, доступне в різних режимах для фотографічних та синтетичних зображень.

Декодування залишається швидким — майже таким самим, як у JPEG, і набагато швидшим, ніж у HEIC з x265. Ключовою функцією для майбутнього є можливість обробки 32-бітної точності вибірки та зображень з понад мільярдом пікселів з кожного боку — це терапіксель, якщо рахувати.

Широке коло великих технологічних компаній підтримувало стандарт протягом років після його випуску, від Meta до Adobe, Intel та Flickr. Хоча може здатися, що Google був повністю на борту з самого початку, беручи участь у розробці стандарту, історія складніша, як повідомляє TT Lab.

Chromium реалізував декодер на основі libjxl ще у 2021 році, що, здавалося, сигналізувало про майбутню підтримку JPEG-XL у Chrome та інших продуктах. Однак незабаром напрямок змінився. Наприкінці 2022 року його було заплановано до видалення з повідомленням про недостатню підтримку екосистемою для виправдання подальших зусиль із впровадження JPEG-XL.

У Chrome 110 вже не було й сліду — JPEG-XL не став частиною цього. І все ж, у наступні роки на трекері проблем Chrome вирували дебати щодо того, чи заробить новий формат своє включення. В іншому місці JPEG-XL боровся за своє місце. Apple інтегрувала його в Safari у 2023 році, тоді як Mozilla продовжувала вагатися, зазначаючи, що додавання ще одного декодера зображень на C++ є небажаним з міркувань безпеки пам’яті.

Новий поштовх стався в листопаді 2025 року, коли Рік Баєрс, керівник технічного напрямку Google Chrome, зазначив, що ландшафт змінився. Він написав, що зважаючи на додавання підтримки JPEG-XL до таких речей, як формат PDF і Safari, серед інших сигналів підтримки в ширшій екосистемі, команда розробників буде готова «інтегрувати продуктивний і безпечний декодер JPEG XL у Chromium».

Оскільки Chrome займає понад 65% ринку браузерів, це стало б переломним моментом для формату і, ймовірно, призвело б до стрімкого зростання його впровадження в Інтернеті. Залишалося лише фактично реалізувати його. Однак Баєрс обережно зазначив, що включення нового формату залежатиме від зобов’язань щодо довгострокової підтримки декодера.

Справи пішли швидко, і коли Chrome 145 вийшов у лютому цього року, JPEG-XL був у порядку денному. Це стало можливим завдяки розробці декодера jxl-rs, реалізованого на Rust. Це було свідоме рішення з міркувань безпеки, оскільки Google покладався на «Правило двох» для захисту свого браузера. Однак новий декодер не було активовано за замовчуванням. Знадобилося ще близько півроку, перш ніж новий формат став мейнстрімною частиною Chrome, замість того, щоб залишатися за експериментальним прапором або чимось подібним. Однак, станом на Chrome 155, JPEG-XL буде повністю підтримуватися в браузері.

Не очікуйте негайно побачити безліч файлів *.jxl у глобальній мережі. Однак, оскільки новий формат пропонує на 30-50% краще стиснення, ніж JPEG, він буде привабливим для будь-якого постачальника контенту, який прагне скоротити витрати на передачу даних і прискорити завантаження сторінок. Коли приріст продуктивності почне настільки збільшувати трафік, щоб компенсувати втрату користувачів зі старих несумісних браузерів, очікуйте, що ситуація зміниться швидше.

Що це означає для вас, кінцевого користувача? Ймовірно, лише невеликі незручності. Вам доведеться час від часу стикатися з труднощами, коли ви завантажуєте файл *.jxl і намагаєтеся відкрити його у старому програмному забезпеченні, яке його не підтримує. Можливо, ви матимете пристрій, який фотографує у форматі JPEG-XL, а потім виявите, що не можете завантажити їх на старий вебсайт із застарілою формою завантаження зображень.

Це та сама проблема, з якою ми всі стикалися, коли HEIC, AVIF та WEBP почали з’являтися в Інтернеті, і нам доведеться пережити це знову. Принаймні, зрештою, ми матимемо трохи кращі зображення, які займатимуть трохи менше місця. Безумовно, це того варте.

• 
• 
• 
• 

Ananace каже: 28 жовтня 2026 о 7:40 ранку

JPEG-XL принаймні належним чином розроблений для Інтернету, включаючи кінцевий розмір зображення в першому заголовку, повністю підтримуючи часткове декодування — з підвищенням якості при завантаженні більшої частини зображення, і, звичайно, з можливістю кодування як з втратами, так і без втрат.
Мені особливо подобається, як дизайн дозволяє створювати мініатюри низької якості, просто обрізаючи зображення до вибраного розміру.

limroh каже: 28 жовтня 2026 о 7:50 ранку

webP — «перша стабільна версія… з підтримкою бібліотеки у квітні 2018 року»
AVIF — «перший випуск 19 лютого 2019 року»
HEIC — «впроваджено у 2015 році» (справді?!)
JPEG-XL — «перший випуск 13 жовтня 2021 року»

Мені ніколи не доводилося мати справу з HEIC чи AVIF, але XKCD про «просто ще один стандарт» насправді не стосується JXL, чи не так?
Це стосується webP, AVIF та HEIC.

Я маю на увазі, що JPEG-XL мав (має?!) широку підтримку в галузі, був буквально розроблений як наступник JPEG, є зворотно сумісним з JPEG (або JPEG є прямо сумісним з JXL?), краще стиснення / краща якість, подібна швидкість декодування тощо.
На мою думку, JXL кращий практично в усіх аспектах, тоді як три інші у кращому випадку кращі в одному-двох аспектах (кожний).

1. jpa каже: 28 жовтня 2026 о 8:41 ранку

   Справді крута частина — це те, що більше не потрібно вибирати між jpeg і png.

   1. Maave каже: 28 жовтня 2026 о 10:03 ранку

      Але натомість користувач повинен вибрати правильний режим: з втратами чи без втрат. Отже, ми все ще будемо бачити час від часу гігантські файли зображень. Сподіваюся, програми на кшталт Photoshop автоматично визначатимуть відповіднішу компресію.

      1. Morpheus каже: 28 жовтня 2026 о 12:06 дня

         Немає нічого для автоматичного визначення, і це ніколи не було проблемою з іншими форматами до цього дня.
         Люди знають, чи хочуть вони зберегти зображення як стиснене з втратами (вибираючи рівень якості, що відповідає їхньому цільовому розміру файлу), чи без втрат.

         Для контексту, vardct — це стиснення в стилі JPEG (завжди з втратами), а modular — схожий на PNG (зазвичай без втрат, але може бути з втратами, як у «PNG з втратами»).
         Реалізатор може вибрати, яка поведінка є за замовчуванням, або як її налаштувати для свого розгортання.

         1. Metlosh каже: 29 жовтня 2026 о 6:09 ранку

            Справді? Кількість проблем із «завантаж аватари розміром до 256 КБ» та запитання в підтримку «чому я не можу завантажити професійне фото розміром 112 мегапікселів як аватар» значно покращується, якщо дозволити лише JPEG. Транскодування до потрібного розміру на сервері не дуже допомагає; квитки підтримки на кшталт «розмитий аватар під час завантаження» часто конкурують з декомпресійними бомбами, що аварійно зупиняють систему.

      2. jpa каже: 28 жовтня 2026 о 12:11 дня

         Я думав, що кодер повинен автоматично визначати це і бути здатним поєднувати різні режими в різних частинах зображення. Але так, це вимагає достатньо розумної реалізації стиснення.

   2. Soc Rat каже: 28 жовтня 2026 о 2:55 дня

      Ніхто ніколи не буде задоволений. Він має стиснення без втрат, але прямо зараз я працюю з мікроконтролером без спеціального JPEG-обладнання, і декодування Хаффмана пожирає цикли тактування. Як щодо надзвичайно втратного, але без Хаффмана? iDCT простий, Хаффман — не зовсім.

      1. Alan каже: 28 жовтня 2026 о 5:27 вечора

         Я дивлюся на полицю з прикладами коду на C / Java / Python, усі з використанням графічних зображень як прикладів кодування/декодування. Звучить так, ніби мені потрібна ще одна книга.
         Можливо, мені варто викинути одну зі старіших. «Керівництво програміста з EGA, VGA та SVGA» (Ferraro, 1994) покривається пилом, і є копія в Інтернет-архіві…

2. fuzzyfuzzyfungus каже: 28 жовтня 2026 о 8:23 ранку

   Це, очевидно, не довгострокова аргументація за або проти JPEG-XL; але для будь-кого, хто його використовує або має конфігурацію, де хтось може вирішити його використати, навіть якщо ви цього не робите; пам’ятайте, що він використовує Brotli-стиснення і підпадає під дію CVE-2026-111497. Встановіть патч.

3. JRD каже: 28 жовтня 2026 о 8:24 ранку

   Що сталося з JPEG-2000? Він провалився так повністю, що навіть не заслуговував на згадку?

   1. Mark Topham каже: 28 жовтня 2026 о 10:51 ранку

      Повністю інша технологія.

   2. Jensen каже: 28 жовтня 2026 о 11:56 ранку

      Він став популярним в інших секторах (медицина, архіви, цифрове кіно/IMAX, PDF), особливо в офлайн-режимі.

      І, всупереч поширеній думці, більшість популярних браузерів мали підтримку jp2, але це було як неминуча частина відповідного стандарту PDF-рідера, який вони постачають (pdfium, pdf.js та PDF-рідера Edge від Adobe), а не як частина самого браузера або рушія візуалізації.

      Оригінальний референсний кодер і декодер jp2 довго був у поганому стані, і реалізатори неправильно його використовували. До того часу, як це покращилося, техніка вейвлет-стиснення почала виходити з моди, а відео-кодеки почали привертати увагу.

   3. asheets каже: 28 жовтня 2026 о 1:17 дня

      Я пам’ятаю J2000… компанія, в якій я працював, використовувала його як формат зображень для своєї системи подання заявок на гарантійний ремонт. Ідея полягала в тому, що люди могли надсилати фотографії свого дефектного продукту.

      Ми отримали купу піксілів високої роздільної здатності.

      1. Alan каже: 28 жовтня 2026 о 5:31 вечора

         При мільярді пікселів з кожного боку, нові піксілі могли б показувати окремі клітини шкіри.

   4. rasz_pl каже: 28 жовтня 2026 о 3:54 дня

      JPEG-2000 опинився в кінотеатрах і став основою шахрайства, відомого як REDCODE RAW, де Red запатентувала «JPEG-2000, але у відеокамері, що стискає RAW дані».

   5. TbR каже: 29 жовтня 2026 о 1:02 ночі

      Інша технологія, і загалом дуже успішна, просто не так, як було задумано спочатку.

      Вона використовується в цифровому кіно, виробництві контенту, медицині (див. DICOM), супутникових знімках та багатьох інших галузях.

      Багато стандартів JPEG такі: використовуються за лаштунками, як-от JPEG XS (багато трансляцій та професійних AV-систем покладаються на це сьогодні). Завжди розроблені з нуля з жорсткими вимогами для вирішення конкретних випадків використання.

      На підтвердження цього: і 2000, і XS отримали премії «Еммі» за підкреслення їхньої важливості.

      JPEG XL — це, нарешті, справжнє сучасне оновлення JPEG-1, як і було задумано JPEG та підтримано галуззю. Останнє, звісно, найважливіше.

4. RunnerPack каже: 28 жовтня 2026 о 9:00 ранку

   Я цілком впевнений, що зображення з 10^9 пікселів з кожного боку буде зображенням у ексапікселях, оскільки воно базується на (приблизній) загальній кількості пікселів.

   1. ialonepossesthetruth каже: 28 жовтня 2026 о 12:18 дня

      Автор був правий.
      «понад мільярд пікселів з кожного боку — це терапіксель»
      З кожного боку, а не на зображення.

      1. css каже: 28 жовтня 2026 о 6:49 вечора

         Хіба це не буде гігапіксель (мільярд, 10^9), а не терапіксель (трильйон, 10^12)? Якщо тільки не було дивного ліміту 10^9 на 10^3 для найширших співвідношень сторін. Або ми говоримо про довжину, а не площу, але вдаємося до довгої/короткої шкали.

         З того, що я розумію, реальний ліміт становить приблизно мільярд пікселів з кожного боку (зокрема, 2^30 на 2^30-1, або 1 073 741 824 на 1 073 741 823) для загальної можливої кількості близько ексапікселя — тобто, приблизно 10^18 або 2^60 пікселів на зображенні.

         Я дозволю собі бути аматорським редактором, але я підозрюю, що автор HaD взяв рядок «терапіксель» з незграбного перефразовування статті у Вікіпедії: «зображення надвисокої чіткості (до 1 терапікселя) з розмірами понад мільярд (2^30-1) пікселів з кожного боку», де цитоване джерело просто згадує «величезні зображення (гігапікселі або навіть терапікселі)». Оскільки звичайний JPEG обмежений 2^16-1 на 2^16-1, або близько 4 гігапікселів, це був просто неформальний спосіб сказати «більші зображення, ніж звичайний JPEG».

         Багато експонент у цьому коментарі; сподіваюся, всі ці карети не викличуть випадково катастрофи форматування.

   2. prosper каже: 28 жовтня 2026 о 10:03 ранку
      

      Однак, оскільки новий формат пропонує на 30-50% краще стиснення, ніж JPEG, він буде привабливим для будь-якого постачальника контенту, який прагне скоротити витрати на передачу даних і прискорити завантаження сторінок.

      А як щодо того, щоб припинити використовувати 10 мегабайт незграбного JavaScript і 3/4 сторінки, присвяченої рекламі?

      1. Dan каже: 28 жовтня 2026 о 12:41 дня

         👏 👏 👏

         Дивно, але 10 мегабайт незграбного JS — це зазвичай реклама/трекінг/оптимізація конверсій, яку маркетинг змусив додати в кінці проекту розробки.

         Не дивно, що компанії-паразити, які займаються рекламою та трекінгом, не дбають про досвід користувача та конфіденційність.

   3. M каже: 28 жовтня 2026 о 1:11 дня

      1 мільярд * 1 мільярд — це квінтільйон. Це 1 квінтільйон пікселів (?), а не терапіксель

      1. Troy каже: 28 жовтня 2026 о 4:01 дня

         Це один петапіксель. 1 гіга = 10^9, 1G x 1G = 10^18 = пета

   4. Aknup каже: 28 жовтня 2026 о 6:54 вечора

      Я намагався зберегти якусь анімацію у цьому форматі, але навіть FFMpeg, здається, не може цього зробити, оскільки за замовчуванням немає бібліотеки для цього.

      Знадобиться багато часу, щоб все програмне забезпечення підтримувало його функціональність, але до того часу він може бути знову замінений. Я читав, що скоро YouTube перейде на AV2 для відео, а я навіть не чув, що таке існує, зітхаю, але це показує постійний потік YAF (ще один новий формат). Я дивуюся, чи це суто для ефективності, чи це частина того лайна, яке вони роблять, щоб ви постійно оновлювали програмне забезпечення, що, як я підозрюю, робиться для того, щоб вони могли прослизнути туди погані речі через задні двері, коли люди натискають «так», як це іноді трапляється. Одночасно вони «оновлюють» EULA і додають «білінг» та/або «телеметрію», якщо це можливо.

      1. Aknup каже: 28 жовтня 2026 о 6:55 вечора

         ВИПРАВЛЕННЯ:
         Я мав на увазі сказати «навіть FFMpeg, здається, не може цього зробити»
         Вибачте за помилку «подвійного заперечення».

   5. tahome каже: 28 жовтня 2026 о 10:37 вечора

      А як щодо JPEG2000?

      1. macsimki каже: 29 жовтня 2026 о 1:41 ночі

         це настільки ж JPEG1999…

   6. TbR каже: 29 жовтня 2026 о 12:52 ночі

      Ну, замість того, щоб робити коментар про офіційне лого JPEG XL, стаття могла б використати його належним чином зверху замість менш офіційного логотипу 🙂 У будь-якому разі, це не надто важливо…

      1. Elliot Williams каже: 29 жовтня 2026 о 2:56 ночі

         Це була моя вина. Офіційне лого не є дуже привабливим. Логотип спільноти є більш візуально привабливим.

   7. Petr Polášek каже: 29 жовтня 2026 о 2:41 ночі

      Файли зазвичай більші за AVIF, а декодування повільніше, але… ураааа!

      Якщо вам потрібен справді цікавий формат зображень, подивіться на QOI, який складається лише з 300 рядків коду C
      https://qoiformat.org/

   8. El Gru каже: 29 жовтня 2026 о 6:29 ранку

      JPG з якістю 100 фактично є без втрат.

      Якщо вам потрібен контейнер, який може робити все і навіть більше, просто використовуйте TIFF.

      Одна з реальних переваг JPG полягає в тому, що він дотримується правила *nix: роби одну річ і роби її добре. Як і PNG.

   9. paulvdh каже: 29 жовтня 2026 о 8:04 ранку

      В Інтернеті вже повно піксельних речей, і це мене не надихає. Я все ще чекаю на широко прийнятий векторний формат. Звичайно, є SVG, і веб-браузери зараз його підтримують, але якщо, наприклад, ви завантажуєте .SVG зображення на форум, воно здебільшого просто не працює.

Залишити відповідьСкасувати відповідь

Будьте ввічливими та шанобливими, щоб зробити розділ коментарів чудовим. (Політика коментування)

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.

Подробиці можна знайти на сайті: hackaday.com