Специфікація PNG: обгрунтування

1. REC-png.html Рекомендація W3C 01 жовтня-1996
2. 12.1. Чому новий формат файлу?
3. 12.2. Чому ці особливості?
4. 12.3. Чому б не ці особливості?
5. 12.4. Чому б не використовувати формат X?
6. 12.5. Порядок байтів
7. 12.6. Переплетення
8. 12.7. Чому гамма?
9. 12.8. Неперемножені альфа
10. 12.9. Фільтрація
11. 12.10. Текстові рядки
12. 12.11. Підпис файлу PNG
13. 12.12. Розкладка шматка
14. 12.13. Угоди про іменування шматка
15. 12.14. Гістограми палітри

REC-png.html

Рекомендація W3C 01 жовтня-1996

(Цей додаток не є частиною офіційної специфікації PNG.)

У цьому додатку наводяться аргументи деяких проектних рішень у PNG. Багато з цих рішень були предметом значних дискусій. Автори вільно визнають, що інша група могла приймати різні рішення; однак, ми вважаємо, що наш вибір є обґрунтованим і послідовним.

12.1. Чому новий формат файлу?

Чи дійсно світ потребує ще одного графічного формату? Ми віримо. GIF більше не можна вільно використовувати, але жоден інший широко використовуваний формат не може безпосередньо замінити його, як це обговорюється нижче. Можливо, було використано адаптацію існуючого формату, наприклад GIF, з непатентованою схемою стиснення. Але це все одно потребує нового коду; це було б не набагато простіше реалізувати, ніж новий формат файлу. (PNG розроблено так, щоб бути простим у реалізації, за винятком двигуна стиснення, який був би необхідний у будь-якому випадку.) Ми вважаємо, що це відмінна можливість розробити новий формат, який виправляє деякі відомі обмеження GIF.

12.2. Чому ці особливості?

Функції, вибрані для PNG, призначені для задоволення потреб програм, які раніше використовували спеціальні переваги GIF. Зокрема, GIF добре пристосований для онлайнових комунікацій завдяки своїй спроможності потокової передачі та прогресивному відображенню. PNG ділиться цими атрибутами.

Ми також розглянули деякі з широко відомих недоліків GIF. Зокрема, PNG підтримує образи truecolor. Ми не знаємо широко використовуваного формату зображень, які б стирали зображення без кольорів так само ефективно, як PNG. Ми сподіваємося, що PNG зробить використання зображень truecolor більш практичними та поширеними.

Деяка форма контролю прозорості є бажаною для додатків, в яких зображення відображаються на фоні або разом з іншими зображеннями. Для цієї мети GIF надала просту специфікацію прозорих кольорів. PNG підтримує повний альфа-канал, а також специфікації прозорих кольорів. Це дає змогу досягти високої гнучкості та ефективності стиснення.

Важливим фактором є надійність проти помилок передачі. Наприклад, зображення, передані через Інтернет, часто помилково обробляються як текст, що призводить до пошкодження файлів. PNG розроблений таким чином, що такі помилки можуть бути виявлені швидко і надійно.

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

12.3. Чому б не ці особливості?

Деякі функції спеціально опущені в PNG. Такий вибір було зроблено для спрощення реалізації PNG, сприяння перенесенню та взаємозамінності, а також максимально спрощений та надійний формат для користувачів. Зокрема:

• Не стиснутий варіант PNG. Можна зберігати нестиснені дані, використовуючи тільки нестиснуті блоки дефляції (функція, яка зазвичай використовується для гарантії того, що дефляція не робить нестисливих даних набагато більшими). Проте, програмне забезпечення PNG має підтримувати повне дефляцію / роздування; будь-яке програмне забезпечення, яке не відповідає стандарту PNG. Дві найважливіші особливості перенесення і стиснення PNG --- є абсолютними вимогами до онлайн-додатків, і користувачі вимагають їх. Нездатність підтримати повну дефляцію / роздуття компрометує обидві ці цілі.
• Немає стиснення з втратами в PNG. Існуючі формати, такі як JFIF, добре обробляють стиснення з втратами. Крім того, доступні методи стиснення з втратами (наприклад, JPEG) далекі від надійності --- поганий вибір рівня якості може зіпсувати зображення. Щоб уникнути плутанини користувача та ненавмисної втрати інформації, ми вважаємо, що найкраще зберігати формати з втратами та втратами. Крім того, стиснення втрат є складним для реалізації. Додавання підтримки JPEG до декодера PNG може збільшити його розмір на порядок. Це, безумовно, призведе до того, що деякі декодери опускають підтримку функції, що знищить нашу мету взаємозамінності.
• Немає підтримки CMYK або інших незвичайних колірних просторів. Знову ж таки, це в ім'я сприяння переносимості. CMYK, зокрема, є занадто залежним від пристрою, щоб бути корисним у якості портативного зображення.
• Немає стандартного фрагмента для перегляду ескізів зображень. У дискусіях з постачальниками програмного забезпечення, які використовують мініатюри у своїх продуктах, стало зрозуміло, що більшість не буде використовувати "стандартний" фрагмент мініатюр. По-перше, кожен виробник має інше уявлення про розміри та характеристики мініатюри. Крім того, деякі виробники зберігають мініатюри в окремих файлах для розміщення різноманітних форматів зображень; вони не збираються припиняти це просто через зменшення розміру ескізу в одному новому форматі. Фірмові шматки, що містять мініатюри, специфічні для постачальників, більш практичні, ніж звичайний формат ескізів.

Варто зауважити, що приватні розширення PNG можуть легко додати ці функції. Проте ми не включимо їх як частину базового стандарту PNG.

PNG також не підтримує декілька зображень в одному файлі. Це обмеження є відображенням реальності, що багато програм не потребують і не підтримують кілька зображень на файл. У будь-якому випадку, окремі зображення є принципово іншим видом об'єкта з послідовностей зображень. Замість того, щоб робити помилкові обіцянки взаємозамінності, ми зробили чітке розмежування між форматами одного зображення та мульти-зображень. PNG є форматом одного зображення. (Але дивіться Розширення декількох зображень .)

12.4. Чому б не використовувати формат X?

Перед прийняттям рішення про розробку PNG розглядалися численні існуючі формати. Ніхто не може відповідати вимогам, які ми вважали важливими для PNG.

GIF більше не підходить як універсальний стандарт через правові заплутування. Хоча лише заміна методу стиснення GIF дозволила б уникнути цієї проблеми, GIF не підтримує зображення із зображеннями, альфа-каналами або гамма-корекцією. Спектр теж має більш тонкі проблеми. Тільки невелика підмножина специфікації GIF89 фактично є портативною через різноманітні реалізації, але не існує кодифікації самої портативної частини специфікації.

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

МКФ також було запропоновано, але не підходить до деталей: доступні зображення зображень занадто специфічні для машини або недостатньо стислі. Загальна структура блоку МКФ є корисною концепцією, від якої PNG ліберально запозичив, але ми не намагалися бути сумісними з біт-бітом з структурою фрагментів IFF. Знову ж таки, це пов'язано з детальними питаннями, зокрема, з тим, що ФОРМИ МКФ не призначені для серійного запису.

Lossless JPEG не підходить, оскільки не передбачає зберігання зображень з індексованими кольорами. Крім того, його стиснення без втрат без втрат часто поступається такому у PNG.

12.5. Порядок байтів

Було запитано, чому PNG використовує порядок байтів мережі. Ми вибрали порядок байтів і використовували його послідовно. Який порядок, зокрема, мало актуальний, але мережевий порядок байтів має ту перевагу, що підпрограми для перетворення в і з нього вже доступні на будь-якій платформі, яка підтримує мережу TCP / IP, включаючи всі платформи ПК. Функції тривіальні і будуть включені в еталонну реалізацію.

12.6. Переплетення

Двовимірна схема переплетення PNG є більш складною для реалізації, ніж GIF-лінія переплетення. Він також коштує трохи більше у розмірі файлу. Тим не менш, це дає початкове зображення у вісім разів швидше, ніж GIF (перший прохід передає лише 1/64 пікселів, порівняно з 1/8 для GIF). Хоча це початкове зображення є грубим, воно корисно в багатьох ситуаціях. Наприклад, якщо зображення є зображенням World Wide Web, який користувач бачив раніше, перший прохід PNG часто достатньо для визначення місця натискання. Схема PNG також виглядає краще, ніж GIF, оскільки горизонтальне та вертикальне дозвіл ніколи не відрізняються більш ніж у два рази; це дозволяє уникнути непарного "розтягування" виду, що спостерігається, коли переплетені GIF-файли заповнюються шляхом реплікації рядків сканування. Попередні результати показують, що невеликий текст у переплетеному зображенні PNG зазвичай читається приблизно в два рази швидше, ніж у еквівалентному GIF, тобто після п'ятого проходу PNG або 25% даних зображення, а не після третього переходу GIF або 50%. Це знову пояснюється більш збалансованим збільшенням роздільної здатності PNG.

12.7. Чому гамма?

Це може здатися природним для стандартизації на зберігання значень зразків, які є лінійно пропорційними інтенсивності світла (тобто мають гамму 1,0). Але насправді для зображень звичайно використовується гама менше 1. Існує три вагомих причини для цього:

• З причин, детально описаних у Гамма-підручник Всі відеокамери застосовують функцію "гамма-корекції" до інформації про інтенсивність. Це призводить до того, що відеосигнал має гаму близько 0,5 відносно інтенсивності світла в початковій сцені. Таким чином, зображення, отримані за допомогою захоплення відеокадрів, вже мають гаму близько 0,5.
• Людське око має нелінійну реакцію на інтенсивність, тому лінійне кодування зразків або витрачає коди зразків у яскравих областях зображення, або надає занадто мало кодів, щоб уникнути появу артефактів в темних областях зображення або обох. Щонайменше 12 біт на вибірку необхідні, щоб уникнути видимих ​​артефактів у лінійному кодуванні з діапазоном інтенсивності зображення 100: 1. Гамма-зображення в діапазоні від 0,3 до 0,5 виділяє значення зразків таким чином, що приблизно відповідає реакції очі, так що 8 біт / вибірки є достатніми, щоб уникнути артефактів, викликаних недостатньою точністю вибірки майже у всіх зображеннях. Це робить "гамма-кодування" набагато кращим способом зберігання цифрових зображень, ніж простіше лінійне кодування.
• Багато зображень створюються на ПК або робочих станціях без апаратного забезпечення для гамма-корекції та програмного забезпечення, яке б хотіло також забезпечити гамма-корекцію. У цих випадках зображення мають висвітлення та колір, обрані таким чином, щоб вони виглядали краще на цій платформі - їх можна вважати, що вбудована "ручна" корекція гами. такі зображення, що мають значення file_gamma в діапазоні 0,4-0,6, в залежності від рівня освітлення кімнати, в якому працював автор.

На практиці значення гами зображення близько 1,0 і близько 0,5 широко знайдені. Старі стандарти зображення, такі як GIF, часто не враховують цей факт. Стандарт JFIF вказує, що зображення у такому форматі повинні використовувати лінійні зразки, але багато зображення JFIF, знайдені в Інтернеті, фактично мають гаму десь близько 0,4 або 0,5. Різноманітність знайдених зображень і різноманітність систем, на яких вони відображаються, призвели до поширених проблем із зображеннями, які з'являються "надто темними" або "надто світлими".

PNG очікує, що глядачі компенсують гамму зображення під час відображення зображення. Інший можливий підхід полягає в тому, щоб очікувати, що кодери перетворюють всі зображення на однорідну гаму при кодуванні. Хоча цей метод трохи прискорить глядачів, він має основні недоліки:

• Гамма-корекція по суті є втратою внаслідок квантування та помилки округлення. Таким чином, вимагаючи перетворення при кодуванні, це призводить до незворотних втрат. Оскільки PNG має бути форматом зберігання без втрат, це небажано; ми повинні зберігати незмінені вихідні дані.
• Кодер може не знати значення джерела гами. Якщо декодер виконує гамма-корекцію під час перегляду, він може регулювати гаму (змінювати відображену яскравість) у відповідь на зворотний зв'язок від користувача. Кодер не має такого регресу.
• Якою б не була "стандартна" гамма, яку ми зупиняли б на деяких дисплеях. Тому глядачі все одно потребуватимуть можливості гамма-корекції.

Оскільки завжди будуть зображення без гами або неправильної записаної гами, хорошим глядачам доведеться у будь-якому випадку включити код регулювання гами. Гама-корекція під час перегляду є правильним шляхом.

Подивитися Гамма-підручник для отримання додаткової інформації.

12.8. Неперемножені альфа

PNG використовує "неасоційований" або "невчинений" альфа, так що зображення з окремими масками прозорості можуть зберігатися без втрат. Інша поширена методика, «премультифицированная альфа», зберігає значення пікселів, попередньо збільшені за допомогою альфа-фракції; насправді зображення вже складене на чорному тлі. Будь-які дані зображення, приховані маскою прозорості, безповоротно втрачаються цим методом, оскільки множення на нульове значення альфа завжди призводить до нуля.

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

Хоча кожна форма альфа-сховища має свої переваги, ми не хотіли вимагати від всіх переглядачів PNG обробляти обидві форми. Ми стандартизувалися на неперемножених альфа як без втрат і більш загальний випадок.

12.9. Фільтрація

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

Алгоритми фільтрів визначаються для роботи на байтах, а не на пікселях; це збільшує простоту та швидкість з дуже низькою вартістю у процесі стиснення. Тести показали, що фільтрація зазвичай неефективна для зображень з меншим, ніж 8 біт на вибірку, тому надання піксельної фільтрації для таких зображень буде безглуздим. Для 16 біт / вибіркових даних фільтрування bytewise майже так само ефективно, як і піксельна фільтрація, тому що MSBs прогнозуються з сусідніх MSB, і LSBs прогнозуються з сусідніх LSB.

Кодеру дозволено змінювати фільтри для кожної нової лінії сканування. Це не створює додаткової складності для декодерів, оскільки декодер повинен містити логіку дефілірування для кожного типу фільтра. Єдиною вартістю є додатковий байт на кожну лінію сканування у потоці даних попереднього стиснення. Наші тести показали, що, коли для всіх ліній сканування вибрано один і той же фільтр, цей додатковий байт стискається практично нічого, тому вартість зберігання в порівнянні з фіксованим фільтром, визначеним для всього зображення, мало. І потенційні переваги адаптивної фільтрації занадто великі, щоб ігнорувати. Навіть з урахуванням спрощеної евристики до вибору фільтрів, адаптивна фільтрація зазвичай перевершує фіксовані фільтри. Зокрема, адаптивний фільтр може змінювати поведінку для послідовних пропусків переплетеного зображення; фіксований фільтр не може.

12.10. Текстові рядки

Більшість форматів графічних файлів містять можливість зберігати деякі текстові дані разом із зображенням. Але багатьом програмам потрібно більше, ніж вони: вони хочуть зберігати декілька фрагментів тексту. Наприклад, база даних з використанням файлів PNG для зберігання медичних рентгенівських знімків, ймовірно, захоче включати ім'я пацієнта, ім'я лікаря тощо. Простим способом зробити це в PNG було б винайти нові приватні шматки з текстом. Недоліком такого підходу є те, що інші програми не мали б уявлення про те, що було в цих шматках, і просто б їх ігнорувати. Замість цього ми рекомендуємо зберігати текстову інформацію в стандартних блоках tEXt з відповідними ключовими словами. Використання tEXt повідомляє будь-якому переглядачу PNG, що блок містить текст, який може становити інтерес для користувача. Таким чином, людина, яка переглядає файл з іншим переглядачем, все одно зможе побачити текст і навіть зрозуміти, що це таке, якщо ключові слова є досить зрозумілими. (Для цього ми рекомендуємо виписані ключові слова, а не абревіатури, які важко зрозуміти людині. Збереження декількох байт у ключовому слові є помилковою економією.)

Набір символів ISO 8859-1 (Latin-1) був обраний як компроміс між функціональністю та портативністю. Деякі платформи не можуть відображати нічого більше, ніж 7-бітові символи ASCII, тоді як інші можуть обробляти символи поза латинським набором. Ми вважали, що Latin-1 являє собою дуже корисний і досить портативний набір символів. Latin-1 є прямим підмножиною наборів символів, які зазвичай використовуються на популярних платформах, таких як Microsoft Windows і X Windows. Його також можна обробляти на системах Macintosh за допомогою простого перепризначення символів.

Наразі не існує положення для тексту, що містить інші набори символів, окрім Latin-1. Ми визнаємо, що потреба в інших наборах символів збільшиться. Однак PNG вже вимагає, щоб програмісти реалізували ряд нових і незнайомих функцій, а представлення тексту не є основною метою PNG. Оскільки PNG передбачає створення і публічну реєстрацію нових допоміжних блоків загального інтересу, ми очікуємо, що текстові шматки для інших наборів символів, наприклад Unicode, зрештою будуть зареєстровані і поступово збільшуватимуться за популярністю.

12.11. Підпис файлу PNG

Перші вісім байтів файлу PNG завжди містять такі значення: (десятковий) 137 80 78 71 13 10 26 10 (шістнадцятковий) 89 50 4e 47 0d 0a 1a 0a (нотація ASCII C) 21 PNG r \ t n

Цей підпис ідентифікує файл як файл PNG і забезпечує негайне виявлення поширених проблем із перенесенням файлів. Перші два байти відрізняють файли PNG від систем, які сподіваються, що перші два байти ідентифікують тип файлу однозначно. Перший байт вибирається як не-ASCII-значення, щоб зменшити ймовірність того, що текстовий файл може бути неправильно розпізнаний як файл PNG; Крім того, він ловить погані передачі файлів, які ясно біт 7. Байти два через чотири називати формат. Послідовність CR-LF ловить погані передачі файлів, які змінюють послідовності нового рядка. Символ control-Z зупиняє відображення файлів під MS-DOS. Останній рядок рядка перевіряє зворотну проблему перекладу CR-LF.

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

Зауважте, що в підписі немає номера версії, а також ніде у файлі. Це навмисно: механізм блоку забезпечує кращий, більш гнучкий спосіб обробки розширень формату, як пояснено в Угоди про іменування шматка .

12.12. Розкладка шматка

Конструкція шматка дозволяє декодерам пропускати нерозпізнані або нецікаві шматки: просто необхідно пропустити відповідне число байтів, як визначено з поля довжини.

Обмеження довжини фрагмента до (2 ^ 31) -1 байт дозволяє уникнути можливих проблем для реалізацій, які не можуть зручно обробляти 4-байтові значення без знака. На практиці, шматки, як правило, набагато коротше.

Для кожного блоку передбачений окремий CRC для того, щоб максимально швидко виявити погано передані зображення. Зокрема, критичні дані, такі як розміри зображення, можуть бути перевірені перед використанням.

Довжина шматка виключається з CRC, так що CRC може бути обчислена, як дані генеруються; це дозволяє уникнути другого пропуску даних у випадках, коли довжина шматка не відома заздалегідь. Виключення довжини з CRC не створює додаткового ризику невдалого виявлення пошкодження файлів, оскільки, якщо довжина є неправильною, перевірка CRC не вдасться: CRC буде обчислено на неправильному наборі байтів, а потім буде перевірено на неправильний значення з файлу.

12.13. Угоди про іменування шматка

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

Гіпотетичний фрагмент для векторної графіки буде критичним фрагментом, оскільки, якщо їх ігнорувати, важливі частини передбачуваного зображення відсутні. Шматок, що несе в собі координати Мандельброта для фрактального зображення, буде допоміжним, оскільки інші програми можуть відображати зображення без розуміння того, що зображує зображення. Загалом, тип блоку повинен бути критичним тільки тоді, коли неможливо відобразити розумне зображення потрібного зображення без інтерпретації цього фрагмента.

Біт відкритої / приватної властивості гарантує, що будь-яке нове ім'я загальнодоступного типу шматка не може конфліктувати з власними шматками, які можуть використовуватися десь. Однак, це не захищає користувачів приватних імен шматок від можливості того, що хтось інший може використовувати одне ім'я блоку з іншою метою. Це гарна ідея поставити додаткову ідентифікаційну інформацію на початку даних для будь-якого приватного типу блоку.

Коли файл PNG змінено, певні допоміжні шматки можуть бути змінені, щоб відобразити зміни в інших фрагментах. Наприклад, фрагмент гістограми повинен бути змінений, якщо дані зображення змінюються. Якщо редактор файлів не розпізнає фрагменти гістограми, їх копіювання в новій вихідний файл сліпо невірно; такі шматки слід відкинути. Біт безпечної / небезпечної властивості дозволяє відповідним чином позначити допоміжні шматки.

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

У деяких ситуаціях може бути неминуче зробити один допоміжний шматок залежним від іншого. Незважаючи на те, що біти блоків властивостей недостатні для представлення цього випадку, доступне просте рішення: у залежному шматку записувати CRC блоку залежить від. Потім може бути визначено, чи був цей блок змінений іншою програмою.

Така ж методика може бути корисною для інших цілей. Наприклад, якщо програма покладається на палітру в певному порядку, вона може зберігати приватний шматок, що містить CRC блоку PLTE. Якщо це значення збігається, коли файл знову читається, то він забезпечує високу впевненість у тому, що палітру не було змінено. Зверніть увагу на те, що при використанні цього методу не потрібно позначати небезпечний для копіювання приватний фрагмент; таким чином, такий приватний фрагмент може пережити інше редагування файлу.

12.14. Гістограми палітри

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

Інші формати зображень зазвичай вирішували цю проблему, вказавши, що записи палітри повинні з'являтися в порядку частоти використання. Це є нижчим рішенням, тому що не дає глядачеві стільки ж інформації: глядач не може визначити, скільки шкоди буде завдано за допомогою останнього кольору. Також відсортована палітра не дає достатньо інформації для вибору цільової палітри для згладжування, якщо глядачеві необхідно істотно зменшити кількість кольорів. Гістограма палітри надає інформацію, необхідну для вибору такої цільової палітри, не пропускаючи дані зображення.