Надаю увазі читачу свій скромний переклад специфікації Міжнародного Стандарту для всесвітньо розповсюдженого графічного формату файлів/потоків даних під назвою PNG. Скромний, оскільки не являюсь професійним перекладачем. Через це можливі неточності і наступні правки даного документу. Для мене даний формат привабливий, перш за все, своєю відкритістю - жоден з його аспектів чи алгоритмів створення не закритий патентами і відповідно не потребує грошових переказів. По-друге, даний формат також привабливий підтримкою каналу прозорості зображення, що дозволяє його використання для створення цікавих ефектів. Наприклад, його можливо використовувати у програмах, які відображають трьохвимірну графіку за допомогою OpenGL, у якості текстури для частково прозорих матеріалів (напівпрозоре скло, вітраж), або-що. Як завжди, технології обмежені лише уявою людини.

Призначення

Даний документ описує PNG (Portable Network Graphics), розширюваний формат файлів для безвтратного, переносимого між різними операційними системами, стисненого збереження растрових зображень. PNG забезпечує не закритий патентами замінник формату GIF і також у багатьох випадках може заміняти формат TIFF. Підтримуються зображення, які складаються з індексів кольорів, градації сірого, і "truecolor" (дійсний колір), в добавок з не обов'язковим компонентом прозорості. Розмах глибини семплів від 1 до 16 біт. PNG розроблений для роботи у мережевих програмах перегляду, на подобі World Wide Web, отож він повністю підтримує потоковість з прогресивною опцією відображення. PNG є стійкий, забезпечує перевірку цілісності і простий спосіб визначення типових помилок передачі. Також, PNG може зберігати гамму і дані кольору для покращення відображення кольору у неоднорідних платформах. Дана специфікація визначає Тип Даних Інтернету (Internet Media Type) image/png.

Статус даного документу

Дана секція описує статус даного документу на момент його публікації. Інші документи можуть витісняти даний. Список поточних публікацій W3C і останню ревізію даного технічного звіту можуть бути знайденими за адресою www.w3.org/TR/. Даний документ являється рекомендаціями до специфікації PNG від 14 Жовтня 2003, друга ревізія. Він також являється Міжнародним Стандартом, ISO/IEC 15948:2003. Два документи мають однаковий вміст окрім сторінок заголовку і відмінності у оформленні, спричинених форматуванням різних організацій. Даний міжнародний стандарт базується на рекомендаціях W3C 'Специфікація PNG версії 1.0', який був переглянутий членами W3C, затверджені у якості Рекомендацій W3C і опубліковані у жовтні 1996 року. Дане друге видання включає в себе усі поправки і уточнення. Повний перегляд документу виконаний ISO/IEC/JTC 1/SC 24 у співпраці з W3C і групою розробниками PNG (автори оригінального PNG 1.0), щоб перетворити Рекомендації у міжнародний стандарт ISO/IEC. Головна ціль розробки під час даного перегляду полягала у запобіганні змін, які зроблять несумісними існуючі файли, редактори, або переглядачі, які відповідають Рекомендаціям Специфікації W3C PNG Версії 1.0. Специфікацію PNG задовільняє хороший рівень реалізації з хорошою сумісністю. На момент публікації більш ніж 180 оглядачів зображень могли відображати зображення у форматі PNG і більш ніж 100 редакторів зображень могли читати з записувати валідні файли PNG. Повна підтримка PNG вимагається для переглядачів, які відповідають стандарту SVG; в момент публікації усі вісімнадцять переглядачів SVG мали підтримку PNG. Стандарт HTML не вимагає підтримки форматів, але більш ніж 60 переглядачів інтернету (браузерів) мали хоча б базову підтримку формату PNG. Вітаються коментарі публіки даного документу Специфікації W3C. Будь-ласка, надсилайте їх до архівованого списку png-group@w3.org. Найновіша інформація щодо патентів, які відносяться до даного документу доступна у мережі. Щодо цієї публікації, Групі PNG невідомі аспекти формату, які закриваються патентами. Даний документ був створений ISO/IEC JTC1 SC24 і Групою PNG у якості частини програми Графічної Активності (Graphics Activity) в W3C Interaction Domain. Зверніть увагу: для забезпечення найкращої якості зображень, дана специфікація використовує SVG діаграми з PNG, використовуючи об'єктні елементи HTML (переклад містить растрові зображення). Браузери, які підтримують SVG будуть в змозі відображати  SVG-діаграми з можливістю виділення тексту, інші браузери будуть відображати растрові версії PNG. W3C попереджає, що існує відома несумісність між непідтримуваною бета-версією SVG-плагіна для Лінукс і версій Mozilla вищих ніж 0.9.9 через зміни у API плаґіна, які спричиняють аварійне завершення роботи браузера. Однак, доступна альтернативна версія з PNG діаграмами, яка не використовує об'єктні елементи. В усьому іншому ці дві версії аналогічні.

Доступні мови

Версія даного документу на Англійській мові являється єдиною нормативною версією. Однак, для перегляду перекладів на інші мови перейдіть за адресою: www.w3.org/Consortium/Translation/.

Вступ

Цілі розробки даного Міжнародного Стандарту були наступними: а. Переносимість: кодування, декодування і передача повинні бути програмно і платформенно незалежними. б. Завершеність: необхідно мати можливість відобразити "truecolor" (дійсний колір), індексовані кольори, і зображення з градаціями сірого, в кожному випадку з можливою підтримкою прозорості у кожному випадку, інформацію про простір кольору, і допоміжну інформацію на подобі текстових компонентів. в. Серійне кодування і декодування: необхідно мати можливість серійно генерувати і читати потоки даних, дозволяючи використовувати формат потоку даних для генерації під час виконання (on-the-fly) і відображення зображень між декількома потоками комунікації. ґ. Прогресивна презентація: необхідно мати можливість передавати потоки даних так, щоб зображення могло відображатись одразу, поступово покращуючи його якість по мірі отримання остальної інформації потоку. д. Завадостійкість відносно помилок передачі: необхідно мати можливість надійно виявляти помилки передачі потоку даних. е. Безвтратність: фільтрування і компресія повинні зберігати усю інформацію. є. Швидкодія: будь-яке фільтрування, компресія і прогресивне представлення зображень повинні бути спроектованими для ефективного декодування і представлення. Швидке кодування являється менш важливою ціллю ніж швидке декодування. Швидкість декодування може бути досягнутою завдяки зменшення швидкодії кодування. ж. Компресія: зображення повинні стискатися ефективно, відповідно до інших цілей проектування. з. Простота: розробники повинні мати можливість легко реалізувати стандарт. и. Взаємозамінність: будь-який відповідний стандарту PNG декодер повинен мати можливість читати усі потоки даних PNG. і. Гнучкість: стандарт повинен дозволяти майбутні розширення і приватні додавання без втрати сумісності з потоками даних PNG. ї. Свобода від обмежень законом: жодний алгоритм не повинен бути використаний, якщо він закритий патентами.

1 Сфера

Даний Міжнародний Стандарт описує потоки даних і асоційовані з ним формати файлів, Portable Network Graphics (вимовляється як "пінґ"), для безвтратних, сумісних, стиснених, відокремлених зображень комп'ютерної графіки, які можливо передавати через Інтернет. Підтримуються колір-індексні, градації сірого і зображення "truecolor", з необов'язковою прозорістю. Розмах глибини семплів від 1 до 16 бітів. PNG являється повністю потоковим з опцією прогресивного відображення. Він являється стійким, забезпечуючи перевірку цілісності і простий механізм визначення розповсюджених помилок передачі. PNG може зберігати гамму і дані кольорів так само як колірні ICC профілі для об'єктивного відображення кольору на різноманітних платформах. Даний стандарт визначає тип Медіа Інтернету "image/png". Потік даних і асоційований формат файлів мають значення не тільки для головних цілей проектування.

2 Нормативні виноски

Наступні нормативні документи містять положення, які, окрім виносок у цьому тексті, являють собою положення даного Міжнародного Стандарту. Не застосовуються Правлені документи або ревізії існуючих публікацій. Однак, учасники засновники цього Міжнародного Стандарту, повинні розробляти можливість введення останніх редакцій нормативних документів, перечислених нижче. Для недатованих виносок, застосовуються останні нормативні документи. Члени організацій ISO і IEC підтримують реєстрацію поточних валідних Міжнародних Стандартів. ISO 639:1988, Коди для представлення імен національних мов. ISO/IEC 646:1991, Міжнародна Організація Стандартизації, Інформаційні технології -- ISO 7-бітний набір кодування символів для обміну інформацією. ISO/IEC 3309:1993, Інформаційна Технологія - Телекомунікації і обмін інформацією між системами - процедури High-level data link control (HDLC) - структура кадру. ISO/IEC 8859-1:1998, Інформаційна технологія - 8-бітний кодований одно байтний  графічний набір символів - Частина 1: Латинська абетка №1. Для зручності надається не-нормативний звичайний текстовий файл, який опису коди і асоційовані імена символів. ISO/IEC 9899:1990(R1997), Мова програмування - C. ISO/IEC 10646-1:1993/AMD.2, Інформаційна технологія - Універсальні багатооктетні Набори Символів (UCS) - Частина 1: Архітектура і Базовий багатомовний набір. IEC 61966-2-1, Мультимедійні системи і устаткування - управління і виміри кольору - Частини 2-1: Типовий простір набору кольорів RGB - sRGB, доступний за адресою http://www.iec.ch/. CIE-15.2, CIE, "Colorimetry, Second Edition". CIE Publication 15.2-1986. ISBN 3-900-734-00-3. ICC-1, International Color Consortium, "Specification ICC.1: 1998-09, File Format for Color Profiles", 1998, доступний за адресою http://www.color.org/ ICC-1A, International Color Consortium, "Specification ICC.1A: 1999-04, Addendum 2 to ICC.1: 1998-09", 1999, доступний за адресою http://www.color.org/ RFC-1123, Braden, R., Editor, "Requirements for Internet Hosts — Application and Support", STD 3, RFC 1123, USC/Information Sciences Institute, October 1989. http://www.ietf.org/rfc/rfc1123.txt RFC-1950, Deutsch, P. and Gailly, J-L., "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, Aladdin Enterprises, May 1996. http://www.ietf.org/rfc/rfc1950.txt RFC-1951, Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, Aladdin Enterprises, May 1996. http://www.ietf.org/rfc/rfc1951.txt, Специфікація алгоритму стискання даних формату DEFLATE версія 1.3 (RFC1951 - kytok.org.ua) RFC-2045, Freed, N. and Borenstein, N. , "MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996. http://www.ietf.org/rfc/rfc2045.txt RFC-2048, Freed, N., Klensin, J. and Postel, J., "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, Innosoft, MCI, ISI, November 1996. http://www.ietf.org/rfc/rfc2048.txt RFC-3066, Alvestrand, H., "Tags for the Identification of Languages", RFC 3066, Cisco Systems, January 2001. (Obsoletes RFC 1766.) http://www.ietf.org/rfc/rfc3066.txt

3 Визначення

Наступні визначення використовуються в даному Міжнародному Стандарті.

3.1.1 alpha (компонент прозорості)

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

3.1.2 alpha compaction (стиснення компоненту прозорості)

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

3.1.3 розділення компоненту прозорості (alpha separation)

Розділення каналу прозорості у якому кожен піксель являється повністю непрозорим; значення компоненту прозорості мають максимальне значення. Факт того, що усі пікселі являються повністю непрозорими вказується неявно.

3.1.4 таблиця компоненту прозорості (alpha table)

Індексована таблиця значень семплів компоненту прозорості, які у зображенні з індексованими кольорами визначають значення компоненту прозорості. Таблиця компоненту прозорості має таку ж кількість позицій, як у палітрі.

3.1.5 підлегла послідовність (ancillary chunk)

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

3.1.6 біти глибини (bit depth)

Для зображень з індексованою палітрою кількість бітів на індекс палітри. Для інших типів зображень, кількість бітів на семпл зображення. Дане значення з'являється у послідовності IHDR.

3.1.7 байт (byte)

8 бітів; також називається октетом. Найвищий біт (значення 128) байту має номер 7; найменший біт (значення 1) має номер 0.

3.1.8 порядок байтів (byte order)

Порядок байтів для багатобайтних даних у PNG-файлі або потоку даних PNG. PNG використовує мережевий порядок байтів.

3.1.9 канал (channel)

Масив усієї інформації певного типу для кожного пікселя зображення. Існує п'ять типів інформації: червоний, зелений, синій, значення відтінку сірого, і значення компоненту прозорості. Наприклад, канал компоненту прозорості зображення являється масивом значень компоненту прозорості у зображенні.

3.1.10 кольоровість (chromaticity - CIE)

Пара значень x,y які точно визначають колір, окрім інформації про яскравість.

3.1.11 послідовність (chunk)

Секція потоку даних PNG. Кожна послідовність має свій визначений тип. Більшість послідовностей також включають у себе дані. Формат і значення даних у послідовності визначаються за типом даної послідовності. Кожна послідовність являється або критичною (critical chunk) або підлеглою (ancillary chunk).

3.1.12 тип кольору (colour type)

Значення, яке показує, як у PNG-зображенні вказуються колір і компонент прозорості. Тип кольору являється сумою наступних значень: 1 - використовується палітра, 2 - використовується truecolor, 4 - використовується компонент прозорості. Дозволені значення типу кольору складають наступний список: 0, 2, 3, 4 і 6.

3.1.13 композит (composite)

Для формування зображення за допомогою об'єднання головного і фонового зображення, використовуючи інформацію прозорості для визначення місця і ступеня видимості фонового зображення. Головне зображення вважається "композитом" по відношенню до фонового.

3.1.14 критична послідовність (critical chunk)

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

3.1.15 потік даних (datastream)

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

3.1.16 deflate

Назва конкретного алгоритму компресії. Даний алгоритм використовується у режимі компресії 0. Алгоритм Deflate входить у сімейство компресійних алгоритмів LZ77. Він визначений у документі RFC-1951 (Cпецифікація алгоритму стискання даних формату DEFLATE версія 1.3 (RFC1951) (deflate - kytok.org.ua)).

3.1.17 отримане зображення (deliverade image)

Зображення сконструйоване з декодованого потоку даних PNG.

3.1.18 фільтр (filter)

Перетворення застосоване до масиву сканрядків для покращення їхнього ступеня стиснення. Формат PNG використовує тільки безвтратні (відновлювальні) алгоритми фільтрування.

3.1.19 буфер кадру (frame buffer)

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

3.1.20 гамма (gamma)

Експонента, яка описує приближення до певних не лінійних функцій, які зустрічаються у захопленні і відображенні зображення. У цьому Міжнародному Стандарті, гамма являється експонентою у функції перетворення з значення display_output до image_sample: image_sample = display_output gamma де, значення display_output i image_sample масштабуються до проміжку від 0 до 1.

3.1.21 відтінок сірого (greyscale)

Представлення зображення у якому кожен піксель визначений одним семплом інформації про колір, яка представляє яскравість (в проміжку між чорним і білим) і опціонально семпл компоненту прозорості (в такому випадку це називається відтінки сірого з компонентом прозорості - greyscale with alpha).

3.1.22 дані зображення (image data)

Одновимірний масив сканрядків зображення.

3.1.23 індексний колір (indexed-colour)

Спосіб представлення зображення у якому кожен піксель являє собою один індекс з палітри кольорів. Обрані входження палітри визначають фактичний колір пікселя.

3.1.24 індексування (indexing)

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

3.1.25 interlaced PNG image

Послідовність зменшених зображень створених з PNG зображення за допомогою послідовного витягнення (pass extraction).

3.1.26 безвтратна компресія (lossless compression)

Метод стиснення даних, який дозволяє повну реконструкцію оригінальних даних.

3.1.27 компресія з втратами (lossy compression)

Метод стиснення даних, який дозволяє приблизну реконструкцію оригінальних даних.

3.1.28 яскравість (luminance)

Формальне визначення яскравості міститься у [CIE-15.2]. Неформально - це сприйняття яскравості, або рівень відтінку сірого, кольору. Яскравість і кольоровість разом повністю визначають колір, який сприймається.

3.1.29 LZ77

Алгоритм стиснення даних описаний Зівом (Ziv) і Лeмпельом (Lempel) у статті 1977 [ZL].

3.1.30 мережевий порядок байтів (network byte order)

Порядок байтів у якому найбільш значущі байти трапляються першими, тоді як менш значущі байти йдуть у оберненому порядку значущості (MSB LSB для двохбайтових цілих, MSB B2 B1 LSB для чотирибайтових цілих).

3.1.31 палітра (palete)

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

3.1.32 прогресивне отримання (pass extraction)

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

3.1.33 піксель (pixel)

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

3.1.34 потік даних PNG (PNG datastream)

Результат кодування зображення PNG. Потік даних PNG складається з PNG сигнатури після якої розміщуються послідовності.

3.1.35 PNG декодер (PNG decoder)

Процес або пристрій який реконструює оригінальне зображення з потоку даних PNG і генерує відповідне отримане зображення.

3.1.36 Редактор PNG (PNG editor)

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

3.1.37 кодер PNG (PNG encoder)

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

3.1.38 PNG файл (PNG file)

Потік даних PNG збережений у вигляді файлу.

3.1.39 чотирибайтове ціле знакове (PNG four-byte signed integer)

Чотирибайтове знакове ціле обмежене значеннями у проміжку від -(232-1) до 231-1. Обмеження спричинене через мови, які мають труднощі з значенням -231.

3.1.40 чотирибайтове беззнакове ціле (PNG four-byte unsigned integer)

Чотирибайтове беззнакове ціле у проміжку від 0 до 231-1. Обмеження спричинене через мови, які мають труднощі з цілими чотирибайтовими значеннями.

3.1.41 зображення PNG (PNG image)

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

3.1.42 сигнатура PNG (PNG signature)

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

3.1.43 зменшене зображення (reduced image)

Отримання чергового порядкового зображення PNG, витягненого з зображення PNG за допомогою прогресивного отримання.

3.1.44 оригінальне зображення (reference image)

Прямокутний масив прямокутних пікселів, кожен має однакову кількість семплів: три (червоний, зелений, синій), або чотири (червоний, зелений, синій і компонент прозорості). Кожне оригінальне зображення може бути представлене точно за допомогою потоку даних PNG і кожний потік даних PNG може бути перетворений у оригінальне зображення. Кожний канал має глибину семпла, яка міститься у проміжку від 1 до 16 бітів. Усі семпли у одному каналі мають однакову глибину семпла. Різні канали можуть мати різну глибину семплів.

3.1.45 об'єднання RGB (RGB merging)

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

3.1.46 семпл (sample - зразок)

Переріз множини каналів з множиною пікселів у зображенні.

3.1.47 глибина семплів (sample depth)

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

3.1.48 масштабування глибини семплів (sample depth scaling)

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

3.1.49 скан-рядок (scanline)

Рядок пікселів у зображенні або порядковому зображенні PNG.

3.1.50 джерельне зображення (source image)

Зображення, яке представляється для PNG кодера.

3.1.51 дійсний колір (truecolour)

представлення зображення у якому кожен піксель визначається семлами, які представляються червоним, зеленим і синім примірниками і необов'язковим семплом компоненту прозорості (у даному випадку це називається дійсний колір з компонентом прозорості - truecolour with alpha).

3.1.52 біла точка (white point)

Кольоровість номінального білого значення дисплею комп'ютера.

3.1.53 zlib

Певний формат даних, які були стисненими використовуючи компресію DEFLATE. Також назва бібліотеки, яка містить реалізацію даного методу. Формат визначений у документів RFC-1950.

3.2 Абривіатури

3.2.1 CRC

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

3.2.2 CRT

Катод-променева труба (Cathode Ray Tube): розповсюджений тип апаратного дисплею.

3.2.3 LSB

Найменш значущий біт (Least Signigicant Byte) багатобайтового значення.

3.2.4 LUT

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

3.2.5 MSB

Найбільш значущий байт (Most Significant Byte) багатобайтового значення.

4 Основні поняття

4.1 Зображення

Даний Міжнародний Стандарт визначає потік даних PNG, і накладає деякі вимоги на кодери PNG, які генерують потоки даних PNG, PNG декодери, які інтерпретують потоки даних PNG, і редактори PNG, які перетворюють один потік даних PNG у інший. Він не визначає інтерфейс між програмою і кодером PNG, декодером або редактором. Точна форма у якій зображення представляється для кодера або доставляється до декодера не визначається. Розрізняються чотири типи зображень. а. Джерельне зображення являється зображення представлене до кодера PNG. б. Оригінальне зображення, яке існує тільки концептуально, являється прямокутним масивом прямокутних пікселів, які мають однакову ширину і висоту, і усі містять однакову кількість беззнакових цілочисельних семплів, або трьох (червоний, зелений і синій), або чотирьох (червоний, зелений і синій з компонентом прозорості). Масив з усіма семплами певного типу (червоний, зелений, синій або компонент прозорості) називається каналом. Кожен канал має глибину семплу у проміжку від 1 до 16 бітів, які використовуються для кожного семплу каналу. Різні канали можуть мати різні глибини семплів. Червоний, зелений  і синій семпли визначають інтенсивність червоного зеленого і синього компонентів кольору пікселя; якщо усі вони мають значення нуля, піксель являється чорним, і якщо усі вони мають максимальне значення (2глибина семплу-1), піксель являється білим. Семпл компоненту прозорості визначає ступінь непрозорості пікселя, де значення нуль означає повну прозорість і максимальне значення означає повну непрозорість. У трьохканальному оригінальному зображенні усі пікселі являються повністю непрозорими. (Також можливо, щоб чотириканальне оригінальне зображення мало усі пікселі непрозорими; різниця полягає у тому, що останнє має певну глибину семплів, а інше ні) Кожний горизонтальний рядок пікселів називається скан-рядком. Пікселі розміщені зліва на право у кожному сканрядку, і сканрядки розміщуються зверху в низ. Декодер PNG може перетворювати джерельне зображення прямо у зображення PNG, але концептуально він спочатку перетворює джерельне зображення у оригінальне зображення, і після цього перетворює оригінальне зображення у зображення PNG. В залежності від типу джерельного зображення, перетворення з джерельного зображення у оригінальне зображення може вимагати втрату інформації. Дане перетворення міститься поза межами даного Міжнародного Стандарту. Оригінальне зображення, однак, може завжди бути відновлене у точній формі з потоку даних PNG. в. Зображення PNG отримане з оригінального зображення за допомогою серій перетворень: розділення компоненту прозорості, індексування, об'єднання RGB, ущільнення компоненту прозорості, і масштабування глибини семплів. Визначаються п'ять типів зображень PNG (перегляньте 6.1: Типи кольорів і значення). (Якщо кодер PNG перетворює джерельне зображення прямо у зображення PNG, і формат джерельного зображення являється подібним до формату зображень PNG, кодер може пропускати деякі з цих перетворень). Хоча не усі глибини семплів у проміжку від 1 до 16 бітів безпосередньо підтримуються у зображенні PNG, кількість значущих бітів у кожному каналі оригінального зображення можуть бути записаними. Усі канали зображення PNG можуть мати однакову глибину семплів. Кодер PNG генерує потік даних PNG з зображення PNG. Декодер PNG бере потік даних PNG і відтворює зображення PNG. г. Доставлене зображення конструюється з зображення PNG отримане з декодування потоку даних PNG. Немає спеціального формату, який визначає формат доставленого зображення. Переглядач представляє зображення для користувача як це можливо найближче до оригінального джерела зображення. Взаємозв'язок між чотирма типами зображень проілюстроване на діаграмі 4.1. [caption id="attachment_1610" align="aligncenter" width="1070"]діаграма 4.1 - взаємовідношення чотирьох типів зображень діаграма 4.1 - взаємовідношення чотирьох типів зображень[/caption] Взаємозв'язок між семплами, каналами, пікселями і глибиною семплів проілюстровану у діаграмі 4.2. [caption id="attachment_1612" align="aligncenter" width="900"]діаграма 4.2 - звязок між семплом каналом глибиною і пікселем.odg діаграма 4.2 - звязок між семплом каналом глибиною і пікселем[/caption]

4.2 Простір кольорів

Простір кольорів RGB у якому розташовані семпли кольору можуть бути вказаними за допомогою одного з наступних трьох способів: а. за допомогою профілю ICC; б. за допомогою безпосереднього вказування, що простір кольору являється sRGB коли семпли відповідають цьому простору кольорів; в. за допомогою вказування значення гами і 1931 CIE кольоровості x, y червоного, зеленого і синього компонентів, які використовуються у зображенні. Для програм з розвинутими додатковими можливостями перший метод забезпечує найбільшу гнучкість і контроль. Другий метод дозволяє один певний простір кольорів. Третій метод дозволяє вказування точних даних кольоровості, разом з застосуванням (перегляньте Додаток C: Гама і кольоровість) гамма корекції (степенева функція, яка зв'язує бажаний вивід з семплами зображення). Рекомендується, щоб безпосередня інформація гами постачалась під час використання першого і другого методу, для використання PNG декодерами, які повністю не підтримують профілі ICC або простір кольорів sRGB. Такі декодери PNG можуть все-одно використовувати інформацію про гамму. Рекомендується щоб PNG декодери використовували дану інформацію додатково з інформацією про систему дисплею для представлення зображення для переглядача у спосіб, який репродукує найближчий можливий вигляд переглянутий автором оригіналу. Якщо присутня, гамма корекція не застосовується до каналу компоненту прозорості. Семпли компоненту прозорості завжди представляють лінійне перетворення непрозорості.

4.3 Перетворення оригінального зображення у зображення PNG.

4.3.1 Вступ

До оригінального зображення застосовуються певна кількість перетворень, щоб створити зображення PNG. Перетворення застосовуються у наступному порядку, де квадратні дужки означають, що перетворення являється необов'язковим (опціональним):
[розділення компоненту прозорості]

індексування або ( [об'єднання RGB] [ущільнення компоненту прозорості])

масштабування глибини семплів
Коли кожен піксель являється повністю прозорим або не прозорим, розділення компоненту прозорості, ущільнення компоненту прозорості і перетворення індексування можуть спричини відмінність відтвореного оригінального зображення від початково оригінального зображення у глибині семплів компоненту прозорості, або у відсутності каналу компоненту прозорості. Це не відображається у зміні ступеня прозорості будь-якого пікселя. Два оригінальних зображення вважаються еквівалентними і перетворення вважаються безвтратними. Кодери, які бажають зберегти глибину семплу компоненту прозорості можуть обрати не виконувати наступні перетворення, які змінять глибину семплів компоненту прозорості. [caption id="attachment_1615" align="aligncenter" width="681"]діаграма 4.3 — Перетворення з оригінального зображення у зображення PNG. діаграма 4.3 — Перетворення з оригінального зображення у зображення PNG.[/caption]

4.3.2 Розділення компоненту прозорості

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

4.3.3 Індексування

Якщо сума різних значень пікселів складає 256 або менше значень, і глибина семплів RGB являється не більшою ніж 8 біт, і канал компоненту прозорості відсутній, або має точно 8 біт глибини для кожного пікселя, або кожен піксель являється повністю прозорим або непрозорим, тоді можна використати альтернативне представлення, яке називається індексуванням кольорів, що може виявитись ефективнішим для кодування. Кожен піксель замінюється індексом палітри. Палітра являється списком входжень, які містять три 8-бітних семплів (червоний, зелений і синій). Якщо присутній канал компоненту прозорості, також існує паралельна таблиця 8-бітних семплів компоненту прозорості. [caption id="attachment_1617" align="aligncenter" width="922"]4.3- індекс-колірне зображення діаграма 4.3 - індекс-колірне зображення[/caption] Можуть бути сконструйованими палітра або декілька палітр, навіть якщо зображення PNG не являється колір-індексним для підтримки переглядачів, які спроможні відтворювати тільки обмежену кількість кольорів. Для колір-індексних зображень, кодери можуть реорганізувати палітру так, щоб входження таблиці з максимальним значенням компоненту прозорості були згрупованими в кінці. У даному випадку таблиця може бути закодована у скороченій формі, і не включати дані рядки.

4.3.4 Об'єднання RGB

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

4.3.5 Ущільнення компоненту прозорості

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

4.3.6 Масштабування глибини семплів

У зображенні PNG підтримуються не усі глибини семплів (перегляньте 6.1 Типи кольорів і значення), і усі канали повинні мати однакову глибину. Усі канали зображення PNG використовують найменшу можливу глибину семплів, що не являється меншою ніж будь-яка глибина семплу оригінального зображення, і можливі значення семплів у оригінальному зображенні лінійно перетворюються у наступний дозволений проміжок для зображення PNG. Діаграма 4.5 показує, як семпли глибини 3 біта можуть бути перетвореними у глибину 4 біта. [caption id="attachment_1620" align="aligncenter" width="474"]Діаграма 4.5 - масштабування глибини семплів Діаграма 4.5 - масштабування глибини семплів[/caption] Обмеження глибин семплів декількома значеннями зменшує кількість випадків з якими декодери будуть мати справу. Масштабування глибини семплів є зворотнім процесом з відсутністю втрат даних, тому що глибини семплів оригінального зображення можуть бути записаними у потоку даних PNG. За відсутності записів глибини семплів, глибини семплів оригінального зображення дорівнюють глибині семплів зображення PNG. Перегляньте 12.5: Масштабування глибини семплів і 13.12: Ремасштабування глибини семплів. [caption id="attachment_1622" align="aligncenter" width="920"]4.6 Мижливі типи пікселsd у PNG Діаграма 4.6. Можливі типи пікселів у PNG[/caption]

4.4 Зображення PNG.

Перетворення оригінального зображення призводить до одного з п'яти типів зображення PNG (перегляньте діаграма 4.6): а. Дійсний колір з компонентом прозорості: кожен піксель складається з чотирьох семплів: червоний, зелений, синій і компонент прозорості. б. Градації сірого з компонентом прозорості: кожен піксель складається з двох семплів: сірого і компоненту прозорості. в. Дійсний колір: кожен піксель складається з трьох семплів: червоний, зелений і синій. Канал компоненту прозорості може бути представлений за допомогою одного значення пікселя. Пікселі, які збігаються з даним значенням являються повністю прозорими, і усі інші пікселі являються не прозорими. Якщо канал компоненту прозорості не вказаний цим способом, усі пікселі являються не прозорими. г. Градація сірого: кожен піксель складається з одного семплу: сірого. Канал компоненту прозорості може бути представлений за допомогою одного значення пікселя, як у попередньому випадку. Якщо канал компоненту прозорості не представлений у даний спосіб, усі пікселі являються не прозорими. ґ. Індекс-колірні: кожен піксель складається з індексу палітри (і асоційованої таблиці значень компоненту прозорості, якщо присутня). Формат кожного пікселя залежить від типу зображення PNG і глибини бітів. Для типів PNG зображення відмінних від індекс-колірних, глибини бітів вказує кількість бітів виділених на один семпл, а не повну кількість бітів на один піксель. Для індекс-колірних зображень, глибина бітів вказує кількість бітів на кожен індекс палітри, а не глибину семплів кольорів у палітрі або таблиці компоненту прозорості. Значення одного пікселя з'являються у наступному порядку, в залежності від типу зображення PNG. а. Дійсний колір з компонентом прозорості: червоний, зелений, синій і компонент прозорості. б. Градації сірого з компонентом прозорості: сірий, і компонент прозорості. в. Дійсний колір: червоний, зелений і синій. г. Градації сірого: сірий. ґ. Колір-індексні: індекс палітри.

4.5 Кодування зображення PNG.

4.5.1 Вступ

Концептуальна модель процесу кодування зображення PNG надана на діаграмі 4.7. Кроки відносяться до операцій масиві пікселів або індексів зображення PNG. Палітра і таблиця компоненту прозорості кодуються іншим шляхом. а. Прогресивне отримання: щоб дозволити прогресивне відображення, зображення PNG може бути реорганізоване для формування менших зображень, які називаються зменшені зображення для отримання. б. Отримання скан-рядків: зображення розбивається на скан-рядки. Пікселі розміщуються зліва на право у скан-рядку, скан-рядки розміщуються зверху в низ. в. Фільтрування: кожен скан-рядок перетворюється на фільтрований скан-рядок, використовуючи один з визначених типів фільтрів для підготування скан-рядка для компресії зображення. г. Стиснення: застосовується до усіх фільтрованих скан-рядків у зображенні. ґ. Створення послідовностей (chunking): стиснене зображення розділяється на послідовності з необхідним розміром. Код виявлення помилки додається до кожної послідовності. д. Створення потоку даних: послідовності вставляються в потік даних.

4.5.2 Прогресивне отримання.

Прогресивне отримання (перегляньте діаграму 4.8) розділяє зображення PNG у послідовність зменшених зображень, де перше зображення визначає грубий огляд і наступні зображення покращують це грубе представлення поки останнє зображення не завершить повне зображення PNG. Набір зменшених зображень також називаються зображеннями PNG, які накладаються. В даному Міжнародному Стандарті визначаються два методи накладання. Перший метод являється методом null; пікселі зберігаються послідовно зліва на право і скан-рядки зверху в низ. Другий метод робить велику кількість сканувань на зображенні для створення послідовності сімох зменшених зображень. Приклад сімох проходів зображення зображено на діаграмі 4.8. Перегляньте пункт 8: Накладання і прогресивне витягнення. [caption id="attachment_1624" align="aligncenter" width="907"]Діаграма 4.7 - Кодування зображення PNG Діаграма 4.7 - Кодування зображення PNG[/caption] [caption id="attachment_1625" align="aligncenter" width="1164"]Діаграма 4.8 прогресивне отримання Діаграма 4.8 прогресивне отримання[/caption]

4.5.3 Серіалізація скан-рядків.

Кожен рядок пікселів, що називається скан-рядок, представляється послідовністю байтів.

4.5.4 Фільтрування

PNG стандартизує один метод фільтрації і декілька типів фільтрів, які можуть використовуватись для підготування даних до компресії. Він перетворює послідовність байтів у скан-рядку на послідовності байтів одинакової довжини, яким передує байт типу фільтру (перегляньте діаграму 4.9 для прикладу). Байт типу фільтру визначає застосування певного фільтру до певного скан-рядку. Кодер повинен використовувати один метод фільтру до зображення PNG, але різні типи фільтрів до кожного скан-рядку у зменшеному зображені. Перегляньте параграф 9: Фільтрування. [caption id="attachment_1628" align="aligncenter" width="911"]Діаграма 4.9 - Серіалізація і фльорування скан-рядку Діаграма 4.9 - Серіалізація і фльорування скан-рядку[/caption]

4.5.5 Коспресія

Послідовність фільтрованих скан-рядків стискається в проході або проходах зображення PNG (перегляньте діаграму 4.10) за допомогою одного з визначених методів. Об'єднані фільтровані скан-рядки з введення до стадії компресії. Вивід з стадії компресії являється один стиснений потік даних. Перегляньте параграф 10: Компресія.

4.5.6 Створення послідовностей.

Створення послідовностей забезпечує зручну розбивку стисненого потоку даних у легкі в управлінні послідовності (перегляньте діаграму 4.10). Кожна послідовність має свою власну перевірку надмірності (CRC). Перегляньте параграф 11: Специфікації послідовностей. [caption id="attachment_1630" align="aligncenter" width="1138"]Діаграма 4.10 - Компресія Діаграма 4.10 - Компресія[/caption]

4.6 Додаткова інформація

З зображенням може асоціюватися підлегла інформація. Декодери можуть ігнорувати усю або деяку додаткову інформацію. Типи додаткової інформації описані у таблиці 4.1.
Колір фону Суцільний колір фону, який потрібно використовувати для представлення зображення, якщо немає іншого кращого параметру.
Гамма і кольоровість Характеристики гамми зображення з урахуванням бажаної вихідної інтенсивності.
Профіль ICC Опис простору кольору (у формі профілю Міжнародного Консорціюму Кольору - ICC) до яких відповідають семпли у зображенні.
Гістограма зображення Оцінює, як часто зображення використовує кожний колір палітри.
Фізичні виміри пікселів Призначений розмір пікселів і співвідношення сторін, які повинні використовуватись для представлення зображення PNG.
Значущі біти кількість бітів, які є значущими у семплах.
Простір кольору sRGB Намір рендерингу (як визначено Міжнародним Консорціюм Кольору - ICC) і показник, що семпли зображення відповідають цьому простору кольору.
Пропонована палітра Зменшена палітра, яка може використовуватися коли пристрій дисплею не в змозі відобразити повний проміжок кольорів зображення.
Текстові дані Текстова інформація (яка може бути стисненю) асоційована з цим зображенням.
Час Час у який зображення PNG востаннє модифікувалося.
Прозорість Інформація компоненту прозорості, яка дозволяє реконструювати оригінальне зображення коли канал компоненту прозорості не вказаний у зображенні PNG.

4.7 Потік даних PNG

4.7.1 Послідовності

Потік даних PNG складається з сигнатури PNG (перегляньте 5.2: Сигнатура PNG) за якою йдуть послідовності даних PNG (перегляньте параграф 11: Визначення послідовностей). Кожна послідовність має свій тип, який вказує на її функцію.

4.7.2 Типи послідовностей

Існують 18 типів послідовностей визначених даним Міжнародним Стандартом. Типи послідовностей являються чотирибайтновими послідовностями, обраними так, щоб вони відповідали читабельним міткам під час інтерпретації у якості набору символів стандарту ISO 646.IRV:1991. Перші чотири являються критичними послідовностями, які повинні бути зрозумілими і коректно інтерпретованими відносно положень даного Міжнародного Стандарту. Вони наступні: а. IHDR: заголовок зображення, який являється першою послідовністю у потоку даних PNG. б. PLTE: таблиця палітрів асоційована з індексними зображеннями PNG. в. IDAT: послідовності даних зображення. г. IEND: остання послідовність, яка завершує потік даних PNG. Інші 14 типів послідовностей називаються підпорядкованими типами послідовностей, які кодери можуть генерувати і декодери інтерпретувати. а. Інформація прозорості: tRNS (перегляньте 11.3.2: Інформація прозорості). б. Інформація простору кольору: cHRM, gAMA, iCCP, sBIT, sRGB (перегляньте 11.3.3: Інформація простору кольору). в. Текстова інформація: iTXt, tEXt, zTXt (перегляньте 11.3.4 Текстова інформація). г. Різна інформація: bKGD, hIST, pHYs, sPLT (перегляньте 11.3.5: Різна інформація). ґ. Інформація часу: tIME (перегляньте 11.3.6: Інформація мітки часу).

4.8 Обробка помилок.

Помилки у потоку даних PNG зводяться до двох загальних класів: а. помилки передачі або пошкодження комп'ютерної файлової системи, що може спричинити псування частини або усього потоку даних. б. помилки синтаксису, які з'являються у якості неправильних значень послідовностей, або втрачені чи неправильно розміщені послідовності. Синтаксичні помилки можуть бути спричинені не тільки помилками кодування, але також за використання реєстрованих або приватних значень, якщо дані значення являються невідомими для декодера. Декодери PNG повинні виявляти помилки як найраніше, за можливості відновити помилкові дані, і вивести помилку в іншому випадку. Філософія обробки помилок детально описується у 13.2: Обробка помилок.

4.9 Розширення і реєстрація.

Для деяких можливостей у PNG, існує деяка кількість визначених альтернатив, і даний Міжнародний Стандарт дозволяє визначати інші альтернативи за допомогою реєстрації. У відповідності до правил позначення і операції реєстрації у Директивах ISO/IEC, Ради ISO i IEC позначили наступний реєстраційний орган: The World-Wide Web Consortium Host at ERCIM The Registration Authority for PNG INRIA- Sophia Antipolis BP 93 06902 Sophia Antipolis Cedex FRANCE Email:png-group@w3.org Щоб забезпечити своєчасну обробку, контакт з Органом Реєстрації повинен відбуватися через електронне листування (email). Наступні сутності можуть бути зареєстрованими: а. тип послідовності; б. текстове ключове слово. Наступні сутності зарезервовані для майбутньої стандартизації: а. невизначені значення полів з значеннями меншими 128; б. метод фільтрації; в. тип фільтрів; г. метод накладання; ґ. метод компресії.

5. Структура потоку даних

5.1 Вступ

Даний параграф визначає сигнатуру PNG і базові властивості послідовностей. Індивідуальні типи послідовності обговорені у параграфі 11: Специфікація послідовностей.

5.2 Сигнатура PNG

Перші вісім байтів потоку даних PNG завжди містять наступні (десяткові) значення:

137 80 78 71 13 10 26 10

Дана сигнатура вказує, що заголовок потоку містить одне зображення PNG, яке складається з серії послідовностей, що розпочинаються з послідовності типу IHDR і закінчуються послідовністю IEND.

5.3 Макет послідовності

Кожна послідовність складається з трьох або чотирьох полів (перегляньте діаграму 5.1). Значення полів описано у Таблиці 5.1. Послідовність може не містити даних.

[caption id="attachment_1635" align="aligncenter" width="969"]Діаграма 5.1 - Частини послідовності Діаграма 5.1 - Частини послідовності[/caption] Таблиця 5.1 Поля послідовності.
Довжина Чотирибайтне беззнакове ціле, яке відображає кількість байтів у полі даних послідовності. Довжина містить розмір тільки області даних, а не всього себе, типу послідовності або CRC. Нуль являється допустимим значенням. Хоча кодери і декодери повинні трактувати дане поле у якості беззнакового цілого, його значення не повинно перевищувати значення 231-1
Тип послідовності Послідовність з чотирьох байтів, які визначають тип послідовності. Кожен байт типу послідовності обмежений у десяткових значеннях від 65 до 90 і від 97 до 122. Дані значення відповідають символам у верхньому і нижньому регістрах кодування ISO 646 (A-Z i a-z) відповідно для зрозумілості опису і перевірки потоків даних PNG. Кодери і декодери повинні трактувати типи у якості фіксованих бінарних значеннях, а не у вигляді рядків символів. Наприклад, не буде коректно для представлення типу послідовності IDAT еквівалентами даних символів у кодуванні символів USC 2. Додаткові узгодження для типів послідовностей обговорюються у 5.4: Узгодження назв послідовностей.
Дані послідовності Байти даних у відповідності до типу послідовності, якщо такі присутні. Дане поле може мати нульову довжину.
CRC Чотирибайтова сума CRC (Cyclic Redundancy Code) обчислена відносно попередніх байтів послідовності, включаючи тип поля послідовності і поля даних послідовностей, але не включаючи поле довжини. CRC може використовуватися для перевірки пошкодження даних. Сума CRC завжди присутня, навіть для послідовностей, які не містять даних. Перегляньте 5.5: Алгоритм Циклічного Коду Надлишковості.
Довжина даних послідовності може містити будь-яке число байтів, навіть максимальне; однак, розробники програмного забезпечення не можуть припускати, що послідовності вирівнюються відносно будь-яких меж більших ніж байти.

5.4 Узгодження щодо назви послідовностей.

Типи послідовностей обираються так, щоб представляти зрозумілі імена під час інтерпретування поля типу послідовності у якості літер системи ISO 646. Імена типів послідовностей присвоюються так, щоб декодери могли визначити деякі властивості послідовності, навіть якщо вона не розпізнаний. Дані правила спричиняють безпечний гнучкий спосіб розширення формату PNG, дозволяючи декодерам PNG вирішувати що робити коли вони стикаються з невідомим типом послідовності. (Типи послідовностей являються стандартизованими у цьому Міжнародному Стандарті і визначені у параграфі 11: Визначення послідовностей, і спосіб додавання не стандартних послідовностей визначений у параграфі 14: Редактори і розширення). Зазвичай, правила назв мають застосовуються коли декодер не розпізнає тип послідовності. Чотири біти типу послідовності, біти властивостей, біт 5 (значення 32) кожного байту, використовуються для передачі властивостей послідовності. Даний вибір означає, що людина може читати присвоєні властивості у відповідності до регістру літери типу послідовності для верхнього (біт 5 має значення 0) і нижнього (біт 5 встановлений у 1). Однак, декодери повинні тестувати властивості невідомого типу послідовності за допомогою тестування даних бітів; тестування того чи символ являється у верхньому або нижньому регістрах є неефективним, і навіть некоректним, якщо використовується специфічні для локалі параметри. Біти властивостей успадкованою частиною типу послідовності, і являються фіксованими для будь-якого типу послідовності. Тобто, CHNK s cHNk будуть різними типами послідовностей, а не однаковими послідовностями з різними властивостями. Семантика бітів властивостей визначена у таблиці 5.2. Таблиця 5.2. Семантика бітів властивостей.
Біт підпорядкованості: перший байт 0 (верхній регістр)=критичний, 1 (нижній регістр)=підпорядкований Критичні послідовності являються необхідними для успішного відображення вмісту потоку даних, наприклад, заголовкова послідовність зображення (IHDR). Декодер намагається витягнути зображення, при отриманні невідомої послідовності з бітом підпорядкованості встановленим у 0, і повинен відобразити користувачу, що зображення містить інформацію, яку він не може безпечно інтерпретувати. Підпорядковані послідовності не являються необхідними для коректного відображення вмісту послідовності потоку даних, наприклад, послідовність мітки часу (tIME). Декодер, який зустрів невідоми тип послідовності у якій біт підпорядкованості встановлений у 1 може безпечно ігнорувати послідовність і продовжити відображати зображення.
Біт приватності: другий байт 0 (Верхній регістр)= публічний, 1 (нижній регістр)=приватний. Публічна послідовність являється такою, що визначена даним Міжнародним Стандартом або зареєстрована у списку публічних типів послідовностей PNG спеціального призначення. Імена приватних послідовностей мають другу літеру у нижньому регістрі, поки публічні послідовності завжди будуть містити другу букву у верхньому регістрі. Декодери не потребують тестувати біт параметру приватної послідовності, оскільки він не має функціонального значення; це просто адміністративне правило для запобігання конфліктності публічних і приватних імен послідовностей. Перегляньте параграф 14: Редактори і розширення 12.10.2: Використання приватних послідовностей.
Зарезервований біт: третій байт 0 (верхній регістр) у даній версії PNG. Якщо зарезервований біт встановлено у значення 1, потік даних не відповідає даній версії формату PNG. Значення регістру у випадку третьої літери імені послідовності являється зарезервованою для майбутнього використання. У даному Міжнародному Стандарті, усі послідовності імен повинні мати треті літери у верхньому регістрі.
Біт безпечності копіювання: четвертий байт 0 (верхній регістр)=небезпечний для копіювання, 1 (нижній регістр)=безпечний для копіювання. Даний біт властивості не міститься в області інтересів чистих декодерів, але він необхідний редакторам PNG. Даний біт визначає правильну обробку нерозпізнаних послідовностей у потоку даних, які були модифікованими. Правила для редакторів PNG обговорюються детальніше у 14.2: Поведінка редакторів PNG.
Приклад гіпотетичної послідовності типу "cHNk" має відповідні біти властивостей:
cHNk  <-- 32 бітний тип послідовності представлений у тексті
||||
|||+- Біт безпечності копіювання є 1 (літера нижнього регістру; біт 5 є 1)
||+-- Зарезервований біт є 0         (літера верхнього регістру; біт 5 є 0)
|+--- Біт приватності є 0            (літера верхнього регістру; біт 5 є 0)
+---- Біт підпорядкованості є 1      (літера нижнього регістру; біт 5 є 1)
Тобто, дане ім'я типу представляє підпорядковану публічну безпечну для копіювання послідовність.

5.5 Алгоритм CRC - Циклічний Код Надмірності

Поля CRC обчислюються використовуючи стандартизовані методи CRC з перед- і після-умовами, як визначено у ISO 3309 [ISO-3309] i ITU-T V.42 [ITU-T-V42]. Поліном CRC виглядає наступним чином: x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 У PNG, усі 32 біти CRC ініціалізуються у 1, і тоді дані з кожного байту обробляються з найменш значущого біту (1) до найбільш значущого біту (128). Після того, як обробляться усі байти даних, значення CRC інвертується (береться порозрядне доповнення). Значення передається (збереженим у потоку даних) найбільш значущим бітом першим. Для розділення на байти і впорядкування, найменш значущий біт 32-х бітної CRC суми визначається коефіцієнтом терміну x31. Фактичні обчислення CRC часто виконують у вигляді наперед обрахованих таблиць для пришвидшення обчислення. Перегляньте Додаток Г: Приклад Реалізації Алгоритму CRC.

5.6 Порядок послідовностей

Обмеження на позиціювання індивідуальних послідовностей розміщені у таблиці 5.3 і у вигляді діаграми 5.2 і діаграми 5.3. Ці маленькі діаграми представляють обмеження на позиціювання накладеними даним Міжнародним Стандартом. Лінії у діаграмах визначають часткові відносини позиціювання. Послідовності, які розміщені вище повинні розміщуватись перед послідовностями, які розміщені нижче. Послідовності, які розміщені горизонтально і з'являються між іншими двома типами послідовностей (вище і нижче ніж горизонтально розміщені послідовності) можуть з'являтися у будь-якому порядку між двома вищими і нижчими послідовностями, до яких вони приєднані. Верхній індекс асоційованих з типом послідовності, визначений у Таблиці 5.4. Він показує чи послідовність являється головною, необов'язковою або може з'являтися більше ніж один раз. Вертикальна лінія між двома типами послідовностями показує альтернативу. Таблиця 5.3 - Правила розміщення послідовностей.
Критичні послідовності (повинні розміщуватись у даному порядку, окрім PLTE являється не обов'язковою)
Ім'я послідовності Множина примірників Обмеження розміщення
IHDR Ні Повинна розміщуватись першою
PLTE Ні Перед IDAT
IDAT Так Множинні примірники послідовності IDAT повинні розміщуватись послідовно
IEND Ні Повинна бути останньою
Підпорядковані послідовності (не повинні з'являтися у даному порядку)
Ім'я послідовності Множина примірників Обмеження розміщення
cHRM Ні Перед PLTE i IDAT
gAMA Ні Перед PLTE i IDAT
iCCP Ні Перед PLTE i IDAT, Якщо присутня послідовність iCCP, послідовність sRGB не повинна бути присутньою
sBIT Ні Перед PLTE i IDAT
sRGB Ні Перед PLTE i IDAT. Якщо присутня послідовність sRGB, послідовність iCCP не повинна бути присутньою
bKGD Ні Після PLTE; перед IDAT
hIST Ні Після PLTE; перед IDAT
tRNS Ні Після PLTE; перед IDAT
pHYs Ні Перед IDAT
sPLT Так Перед IDAT
tIME Ні неважливо
iTXt Так неважливо
tEXt Так неважливо
zTXt Так неважливо
Таблиця 5.4 - Значення символів, використаних у діаграмах
Символ Значення
+ Один або більше
1 Тільки один
? Нуль або один
* Нуль або більше
| Альтернатива
[caption id="attachment_1653" align="aligncenter" width="1070"]Діаграма 5.2 - Дерево розміщення послідовностей для PNG зображення з послідовністю PLTE Діаграма 5.2 - Дерево розміщення послідовностей для PNG зображення з послідовністю PLTE[/caption] [caption id="attachment_1654" align="aligncenter" width="1169"]Діаграма 5.3 - Дерево розміщення послідовностей PNG без послідовності PLTE у потоці Діаграма 5.3 - Дерево розміщення послідовностей PNG без послідовності PLTE у потоці[/caption]

6 Перетворення оригінального зображення у зображення PNG

6.1 Типи кольорів і значення

Як описано у 4.4: Зображення PNG, існує п'ять типів зображення PNG. Кожний тип, який є типом кольору, являється сумою наступних значень: 1 (використовується палітра), 2 (використовується дійсний колір) і 4 (використовується компонент прозорості). Градації сірого і зображення дійсного кольору можуть мати канал компоненту прозорості. Типи зображення PNG і відповідні типи кольору проілюстровані у Таблиці 6.1. Таблиця 6.1 - типи зображення PNG і типи кольорів.
Тип зображення PNG Тип кольору
Градації сірого 0
Дійсний колір 2
Індекс-колір 3
Градації сірого з прозорістю 4
Дійсний колір з прозорістю 6
Дозволені глибини бітів і глибини семплів для кожного типу зображення PNG розміщені у списку 11.2.2: IHDR Заголовок зображення. Семпли градацій сірого представляють яскравість, якщо присутня мітка кривої передачі (за допомогою gAMA, sRGB або iCCP) або значення залежні відносно апаратного забезпечення в іншому випадку. Семпли RGB представляють калібровану інформацію кольору, якщо позначений простір кольору (за допомогою gAMA i cHRM, або sRGB, або iCCP) або, в іншому випадку, не калібрована залежна від апаратного забезпечення. Значення семплів не обов'язково пропорційні до інтенсивності світла; послідовність gAMA вказує на взаємозв'язок між значення семплів і інтенсивністю виведення дисплею. Оглядачам пропонується компенсувати відповідно. Перегляньте 4.2 Простори кольору, 13.13: Обробка гамми декодером і Додаток В: Гамма і кольоровість.

6.2 Відображення компоненту прозорості

У потоку даних PNG прозорість може бути представленою у один з чотирьох способів, в залежності від типу зображення PNG (перегляньте 4.3.2: Розділення компоненту прозорості і 4.3.5: Ущільнення компоненту прозорості). а. Дійсний колір з компонентом прозорості, градації сірого з компонентом прозорості: канал компоненту прозорості являється частиною масиву зображення. б. Дійсний колір, градації сірого: послідовність tRNS містить одне значення пікселя, яку відрізняє повністю прозорі пікселі від непрозорих. в. Колір-індексні: послідовність tRNS містить таблицю компонента прозорості, яка асоціюється з семплами прозорості і входженнями палітри. г. Дійсний колір, градації сірого, індекс-колірні: немає послідовності tRNS і усі пікселі являються непрозорими. Канал компоненту прозорості включений у масив зображення має 8-бітний або 16-бітний семпл, такий самий розмір, як у інших семплів. Семпл компоненту прозорості для кожного пікселі зберігається одразу ж після значення градації сірого або RGB пікселя. Значення прозорості нуль представляє повну прозорість, і значення 2глибинасемплу-1 не прозорість. Проміжні значення позначають часткову прозорість пікселів, які можуть бути скомпонованими з зображенням фону для створення похідного зображення. Значення кольорів у пікселі не множаться на значення компоненту прозорості, який прив'язаний до пікселя. Дане правило інколи називається "не асоційованим" або "не попередньо перемноженим" компонентом прозорості. Іншою розповсюдженою технікою збереження значень семплів являється перемноження на компонент прозорості; як ефект, таке зображення являється скомпонованим з чорним заднім фоном. PNG не використовує перемножений компонент прозорості. Як наслідок редактор зображення може взяти зображення PNG і легко змінити його прозорість. Перегляньте 12.4: Створення каналу компоненту прозорості, і 13.16: Обробка каналу компоненту прозорості.

7 Кодування зображення PNG у якості потоку даних PNG

7.1 Цілі числа і порядок байтів

Усі цілі числа, які вимагають більше ніж один байт повинні зберігатись у мережевому порядку байтів (як проілюстровано на діаграмі 7.1): найбільш значущий байт розміщується першим, після нього йдуть менш значущі байти у порядку зменшення значущості (MSB LSB для двобайтових цілих, MSB B2 B1 LSB для чотири-байтових цілих чисел). Найвищий біт (значення 128) байту пронумерований сьомим бітом; найнижчий біт (значення 1) пронумерований нульовим бітом. Значення являються беззнаковими, якщо не вказано інше. Значення безпосередньо вказані у якості знакових представляються у двохомлектному записі. Чотирибайтні беззнакові цілі обмежені у проміжок від 0 до 231-1, щоб надати можливість мовам, які мають складнощі з беззнаковими чотирибайтовими цілими значеннями, працювати з даним форматом. Подібно чотирибайтові знакові цілі значення PNG обмежені у проміжку від -(231-1) до 231-1, щоб надати можливість мовам, які мають складнощі з значенням -231, обробляти даний формат. [caption id="attachment_1660" align="aligncenter" width="1137"]Діаграма 7.1 - Цілі числа представлені у PNG Діаграма 7.1 - Цілі числа представлені у PNG[/caption]

7.2 Сканрядки

Зображення PNG (або прогресивно отримані зображення, перегляньте параграф 8: Перекриття і прогресивне отримання) являється прямокутним масивом пікселів, з пікселями, які розміщені зліва на право у кожному сканрядку і сканрядки розміщені зверху до низу. Розмір кожного пікселя визначається кількістю бітів на кожен піксель. Пікселі з скан-рядками завжди упаковуються у послідовність байтів без змарнованих бітів між пікселями. Сканрядки завжди вміщуються у межах байтів. Дозволені глибини пікселів і типи кольорів обмежені, отож в усіх випадках упаковування являється простим і ефективним. У зображеннях PNG з типом кольору 0 (градації сірого) кожен піксель у одному семплі, який може мати точність меншу ніж байт (1,2 або 4 біти). Дані семпли упаковуються у байти з найлівішим семплом у найважливіших бітах (MSB) байту, за яким йдуть інші семпли сканрядку. У зображенні PNG з типом кольору 3 (індекс-колірні) кожн піксель являється одним індексом палітри. Дані індекси упаковуються у байти у такий спосіб, як і семпли типу кольору 0. Коли декілька пікселів присутні у одному байті, деякі малозначущі біти останнього байту сканрядку можуть остатись невикористаними. Вміст даних не використаних бітів не визначений даним стандартом. PNG зображення, які не являються колір-індексними зображеннями можуть мати значення семплів з глибиною 16 бітів. Дані значення семплів розміщуються у мережевому порядку байтів (MSB спочатку, LSB наступний). PNG дозволяє множинні семпли пікселів тільки з 8 і 16 бітними семплами, отож множинні семпли одного пікселя не упаковуються у один байт.

7.3 Фільтрування

PNG дозволяє фільтрувати дані сканрядків перед тим, як вони будуть стискатися. Фільтрування може покращити ступінь стискання даних. Крок фільтрування видає послідовність байтів однакового розміру, як у вхідній послідовності даних, але у іншому представленні, оброблених за допомогою байту типу фільтру. Фільтрування не зменшує розмір фактичних даних сканрядка. Усі фільтри PNG являються строго безвтратними. Різні типи фільтрів можуть бути використаними для різних сканрядків, і алгоритм фільтрування вказується для кожного сканрядку за допомогою байту типу фільтра. Байт типу фільтру не вважається частиною даних зображення, але він включається у потік даних, який надсилається на крок стиснення. Кодер з розширеними можливостями може змінювати фільтри від одного сканрядка до іншого. Метод для обирання типу фільтру залишається за кодером. Перегляньте параграф 9: Фільтрування.

8 Перекривання і прогресивне отримання

8.1 Вступ

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

8.2 Методи перекривання

У даному Міжнародному Стандарті визначаються два методи перекривання (або доповнення), метод 0 і метод 1. Інші значення методу перекривання являються зарезервованими для стандартизації у майбутньому (перегляньте 4.9: Розширення і реєстрація). З методом перекривання 0, нульовим методом, пікселі отримуються послідовно зліва на право і сканрядки послідовно зверху у низ. Зображення PNG з перекриттям являється одним зменшеним зображенням. Метод перекриття 1, також відомий як Adam7, визначає сім окремих стадій над зображенням. Кожна стадія (або прохід) передає підмножину пікселів у оригінальному зображенні. Стадія у якій кожен піксель являється переданим (пронумерована від 1 до 7) визначається за допомогою заміни наступного шаблону розміром 8х8 над усім зображенням, розпочинаючи з верхнього лівого кута:
1 6 4 6 2 6 4 6
7 7 7 7 7 7 7 7
5 6 5 6 5 6 5 6
7 7 7 7 7 7 7 7
3 6 4 6 3 6 4 6
7 7 7 7 7 7 7 7
5 6 5 6 5 6 5 6
7 7 7 7 7 7 7 7
Діаграма 4.8 показує сім стадій 1 методу перекривання. З кожними проходом (стадією), обрані пікселі передаються зліва на право у сканрядках, і обрані сканрядки послідовно зверху в низ. Наприклад, прохід 2 містить пікселі 4, 12, 20 і т.д. сканрядку 0, 8, 16 і т.д. (де сканрядок 0, піксель 0 являється верхнім лівим кутом). Останній прохід (або стадія) містить усі сканрядки 1, 3, 5 і т.д. Порядок передачі визначений так, щоб усі сканрядки передаються у проході, будуть мати однкову кількість пікселів; це необхідно для правильного застосування деяких фільтрів. Зображення PNG з перекриваннями складається з послідовності сімох зменшений зображень. Наприклад, якщо зображення PNG має розмір 16 на 16 пікселів, тоді третій прохід буде являти собою зображення з двох сканрядків, кожен з яких містить чотири пікселі (перегляньте Діаграма 4.8). Сканрядки, які повністю не заповнюють ціле число байтів доповнюються, як показано у 7.2: Сканрядки. Зверніть увагу, що якщо оригінальне зображення містить менше ніж 5 колонок або менше ніж п'ять рядків, деякі проходи будуть пустими.

9 Фільтрування

9.1 Методи фільтрування і типи фільтрування

Фільтрування використовується, щоб досягнути краще стиснення зображення PNG. PNG дозволяє декілька методів фільтрування. Усі стиснені зображення у зображеннях, що перекриваються, повинні використовувати один метод фільтрації. Тільки метод фільтрації 0 визначений у цьому Міжнародному Стандарті. Інші методи фільтрації зарезервовані для майбутньої стандартизації (перегляньте 4.9 Розширення і реєстрація). Метод фільтрації 0 забезпечує набір п'яти типів фільтрів, і індивідуальні скан-рядки у кожному зменшеному зображенні можуть використовувати ці різні типи фільтрів. PNG не вимагає додаткові обмеження на те, які типи фільтрів можуть бути застосованими до зображень PNG, що перекриваються. Однак, типи фільтрів не являються однаково ефективними до усіх типів даних. Перегляньте 12.8: Секція фільтрування.

9.2 Типи фільтрів для методу фільтрування 0

Фільтри застосовуються до байтів, не до пікселів, не зважаючи на глибини бітів або типу кольору зображення. Фільтри оперують на послідовностях байтів, які сформовані сканрядками і представлені, як описано у секції 7.2: Сканрядки. Якщо зображення включає канал компоненту прозорості, його дані фільтруються тим шляхом, що і дані зображення. Фільтри можуть використовувати оригінальні значення наступних байтів для генерації нових значень байтів:
x байт, який фільтрується
a байт, який відповідає до x у пікселі одразу ж перед пікселем, який містить x (або байт, який стоїть перед x, коли глибина бітів являється менше ніж 8);
b байт, який відповідає x у попередньому сканрядку;
с байт, який відповідає до b у пікселі, який стоїть одразу перед пікселем, який містить b (або байт, який стоїть перед b, коли глибина бітів менша ніж 8).
Діаграма 9.1 демонструє відносні позиції байтів x, a, b i c. Фільтри PNG методу 0 визначають п'ять базових типів, як проілюстровано у Таблиці 9.1. Orig(y) відображає оригінальне (нефільтроване) значення байту y. Filt(y) відображає значення після застосування фільтру. Recon(y) відображає значення після застосування відповідної функції реконструкції. Функція фільтрування для типу Паета (Paeth) PaethPredictor визначається нижче. Метод фільтрації 0 визначає саме цей набір з п'яти типів фільтрів і він не буде розширюватися. Це дозволяє декодерам не розархівовувати дані для визначення факту присутності фільтру, який вони не підтримують: достатньо перевірити тип фільтру у послідовності IHDR. Таблиця 9.1 - Типи фільтрів
Тип Назва Функція фільтрування Функція реконструкції
0 Немає Filt(x)=Orig(x) Recon(x)=Filt(x)
1 Sub Filt(x)=Orig(x) - Orig(a) Recon(x)=Filt(x) + Recon(a)
2 Up Filt(x)=Orig(x) - Orig(b) Recon(x)=Filt(x) - Recon(b)
3 Averege Filt(x)=Orig(x) - floor((Orig(a) + Orig(b) / 2) Recon(x)=Filt(x) + floor((Recon(a) + Recon(b)) / 2)
4 Paeth Filt(x)=Orig(x) - PaethPredictor(Orig(a), Orig(b), Orig(c)) Recon(x)=Filt(x) + PaethPredictor(Recon(a), Recon(b), Recon(c))
Для усіх фільтрів, байти "зліва від" першого пікселя скан-рядка повинні трактуватися у якості нуля. Для фільтрів, які відносяться до попереднього сканрядка, увесь сканрядок і байти "зліва від" першого пікселя у попередньому рядку повинні трактуватися у якості нулів для першого сканрядку зменшеного зображення. Для відновлення ефекту фільтру необхідні розкодовані значення попереднього пікселя одного сканрядку, і піксель, що стоїть зверху поточного пікселя на попередньому сканрядку, і піксель одразу зліва верхнього пікселя. Використовується цілочисельна остача з 256, отож ввід і вивід вміщуюються у байти. Фільтри застосовуються до кожного байту незалежно від глибини бітів. Послідовність значень Filt передається у якості фільтрованого сканрядка.

9.3 Тип фільтру 3: Середня

Сума Orig(a) + Orig(b) повинна бути виконаною без переповнення (використовуючи хоча б дев'ятибітну арифметику). Функція floor() означає, що результат ділення повинен бути округлений до наступного нижчого цілого у разі дробовості; іншими словами, це цілочислове ділення або операція зсуву вправо.

9.4 Тип фільтру 4: Пает (Paeth)

Функція фільтрування Паета обчислює просту лінійну функцію трьох сусідніх пікселів (лівого, верхнього і верхнього лівого), після чого обирає сусідній піксель найближчий до обчисленого значення. Алгоритм, який використовується у даному Міжнародному Стандарті являється адаптацією техніки Алана В. Паета (Alan W. Paeth) [PAETH]. Функція PaethPredictor визначається у коді наведеному нижче. Логіка функції і позиції байтів a, b, c s x показані на діаграмі 9.1. Pr являється передбаченням для байту x.
p = a + b - c
pa = abs(p - a)
pb = abs(p - b)
pc = abs(p - c)
if pa <= pb and pa <= pc then Pr = a
else if pb <= pc then Pr = b
else Pr = c
return Pr
[caption id="attachment_1668" align="aligncenter" width="1106"]Діаграма 9.1: Функція PaethPredictor Діаграма 9.1: Функція PaethPredictor[/caption] Обчислення у функції PaethPredictor повинні виконуватися точно, без переповнення. Порядок у якому виконуються порівняння являється критичним і не повинен змінювавтись. Функція намагається встановити у якому з трьох напрямках (вертикальний, горизонтальний або діагональний) градієнт зображення являється найменшим. Однакові функції PaethPredictor використовуються у кодері і декодері.

10 Стиснення

10.1 Метод компресії 0

Єдиний метод компресії PNG - 0, визначений у цьому Міжнародному Стандарті. Інші значення методу компресії зарезервовані для майбутньої стандартизації (перегляньте 4.9: Розширення і реєстрація). Метод компресі PNG 0 являється компресією deflate/inflate з плаваючим вікном (яке являється верхньою межею відстаней, що присутня у потоці deflate) з максимум 32768 байтів. Компресія Deflate являється похідною від LZ77 [ZL]. Потоки стиснених даних deflate у PNG зберігаються у форматі "zlib", який має наступну структуру:
код методу/прапорців компресії zlib 1 байт
Додаткові біти прапорців/перевірки 1 байт
Стиснені блоки даних N байтів
Значення перевірки 4 байти
Деталі даного формату надані у специфікацї [RFC-1950] Для методу компресії типу 0, код методів/прапорців компресії zlib повинні вказувати код методу 8 (компресія deflate) і розмір вікна LZ77 не більше ніж 32768 байтів. Номер методу компресії zlib являється не таким, як номер компресії у послідовності IHDR (перегляньте 11.2.2 IHDR Заголовок зображення). Додаткові прапорці не повинні вказувати наперед визначений словник. Якщо дані, які повинні бути стисненими містять 16384 байти або менше, кодер PNG може встановити розмір вікна округлюючи його до степені двійки (мінімум 256). Це зменшує витрати пам'яті для кодера і декодера, без суттєвого впливу на ступінь стиснення. Стиснені дані у потоці даних zlib зберігаються у якості серії блоків, кожен з яких може представити звичайні (не стиснені) дані, стиснені дані за допомогою LZ77 кодуються за допомогою фіксованих кодів Хоффмана, або за допомогою обраних кодером кодів Хоффмана. Біт маркера у фінальному блоці показує, що це є останній блок, дозволяючи декодеру розпізнавати кінець стисненого потоку даних. Більше деталей алгоритму компресії і кодування надані у специфікації deflate [RFC-1951]. Значення перевірки зберігається у кінці потоку даних zlib обчислюється над нестисненими даними, представленими у потоці даних. Алгоритм використовується для обчислення цього не є таким як обчислення CRC для поля CRC послідовності PNG. Контрольне значення zlib корисне в основному у якості додаткової перевірки, яку алгоритми deflate i inflate реалізовують коректно, перевіряючи індивідуальні поля CRC послідовностей забезпечує впевненість, що потік даних PNG був переданий без пошкоджень.

10.2 Компресія послідовності фільтрованих сканрядків

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

10.3 Інші використання компресії

PNG також використовує метод компресії 0 у iTXt, iCCP i zTXt послідовностях. На відміну від даних зображення, такі потоки не розділяються між послідовностями, кожен такий потік містить незалежні потоки даних zlib (перегляньте 10.1 Метод компресії 0).

11 Специфікації послідовностей

11.1 Вступ

Потік даних PNG складається з PNG сигнатури (перегляньте 5.2 сигнатура PNG), за якою йдуть послідовності. Кожна послідовність має тип послідовності, яка визначає її функцію. Даний пункт визначає типи послідовностей PNG стандартизовані цим Міжнародним Стандартом. Структура потік даних PNG визначена у пункті 5: Структура потоку даних. Вона також визначає порядок у який послідовності можуть розміщуватись. Для детальної специфікації кодерів перегляньте 12.11: Створення послідовностей. Для детальної специфікації декодерів перегляньте 13.5: Створення послідовностей.

11.2 Критичні послідовності

11.2.1 Загальна

Загальні послідовності являються такими послідовностями, які абсолютно вимагаються для успішного декодування зображення PNG з потоку даних PNG. Послідовності розширення можуть бути визначеними у якості критичних послідовностей (перегляньте пункт 14: Редактори і розширення), однак ця практика не рекомендується. Валідний потік даних PNG повинен починатися з сигнатури PNG, за якою слідує послідовність IHDR, після якого розміщуються один або більше послідовностей IDAT, і повинен закінчуватись послідовністю IEND. Тільки одна послідовність IHDR і IEND можуть бути присутніми в одному потоку даних PNG.

11.2.2 Заголовок зображення IHDR

Чотирибайтний тип послідовності містить наступні десяткові значення:
73 72 68 82
Послідовність IHDR повинна бути першою послідовністю у потоці даних PNG. Вона містить:
Ширина 4 байти
Висота 4 байти
Глибина бітів 1 байт
Тип кольору 1 байт
Метод компресії 1 байт
Метод фільтрування 1 байт
Метод перекривання 1 байт
Ширина і висота надають розміри зображення у пікселях. Вони являються чотирибайтовим беззнаковим цілим PNG. Нуль являється інвалідним значенням. Глибина бітів являється однобайтовим цілим, яке надає кількість бітів на один семпл або індекс палітри (а не на піксель). Доступні значення являються 1, 2, 4, 8 і 16, хоча не усі значення дозволені для усіх типів кольорів. Перегляньте 6.1: Типи кольорів і значення. Типи кольорів являється однобайтовим цілим числом, яке визначає тип зображення PNG. Доступними значеннями являються 0, 2, 3, 4 i 6. Обмеження глибини бітів для кожного типу кольору накладається для спрощення реалізації і для заборони комбінацій, які погано стискаються. Дозволені комбінації визначені у Таблиці 11.1. Таблиця 11.1 - Дозволені комбінації типів кольорів і глибин бітів.
Тип зображення PNG Тип кольору Дозволені глибини бітів Реалізація
Градації сірого 0 1, 2, 4, 8, 16 Кожен піксель у являється семплом градації сірого.
Дійсний колір 2 8, 16 Кожен піксель являється трійкою значень R,G,B.
Колір-індексний 3 1, 2, 4, 8 Кожен піксель являється індексом палітри; повинна бути присутня послідовність PLTE.
Градації сірого з прозорістю 4 8, 16 Кожен піксель являється семплом градації сірого за яким йде семпл прозорості.
Дійсний колір з прозорістю 6 8, 16 Кожен піксель являється трійкою значень R,G,B за якими слідує семпл прозорості.
Глибина семплів являється такою ж як глибина бітів, однак у випадку колір-індексного зображення PNG (тип кольору 3), у якому глибина семплів завжди повинна бути 8 бітів (перегляньте 4.4: зображення PNG). Метод компресії являється однобайтовим цілим числом, яке показує метод, що використовується для стиснення даних. Тільки метод компресії 0 (deflate/inflate компресія з ковзаючим вікном з найбільшим розміром у 32768 байтів) визначається у цьому Міжнародному Стандарті. Усі сумісні зображення PNG повинні бути стисненими за допомогою цієї схеми. Метод фільтрації являється однобайтовим цілим, який показує метод підготування, який застосовується до даних зображення перед компресією. Тільки метод фільтрації 0 (адаптивне фільтрування з п'ятьма базовими типами фільтрації) визначені у цьому Міжнародному Стандарті. Перегляньте пункт 9: Фільтрування для деталей. Метод перекривання являється однобайтовим цілим, яке показує порядок передачі даних зображення. Два значення визначені у даному Міжнародному Стандарті: 0 (без перекривання) або 1 (перекривання Adam7). Перегляньте пункт 8: Перекривання і прогресивне отримання для більшої детальності.

11.2.3 Послідовність палітри PLTE

Чотирибайтове поле типу послідовності містить наступні десяткові значення
80 76 84 69
Послідовність PLTE містить від 1 до 256 входжень палітри, кожен являється трибайтовою серією у формі
Червоний 1 байт
Зелений 1 байт
Синій 1 байт
Кількість входжень визначається за допомогою довжини послідовності. Якщо довжина послідовності не ділиться на 3 це являється помилкою. Дана послідовність повинна з'являтися з типом кольору 3, і може з'являтися для типів кольору 2 і 6; вона не повинна з'являтися для типів кольору 0 і 4. Не повинно бути більше одної послідовності PLTE у зображенні. Для типу кольору 3 (колір-індексні), вимагається послідовність PLTE. До першого запису послідовності PLTE звертаються за індексом пікселя 0, до другого за значенням пікселя 1 і т.д. Кількість входжень палітри повинне не перевищувати проміжок, який може бути представлений за допомогою глибини бітів (наприклад, 24=16 для глибини бітів 4). Дозволено мати менше входжень палітри, ніж дозволяє глибина бітів. У даному випадку, будь-який вихід значення пікселя-індекса буде вважатися помилкою. Для типу кольору 2 і 6 (дійсний колір і дійсний колір з прозорістю), послідовність PLTE являється не обов'язковою. Якщо присутня, вона забезпечує пропонований набір кольорів (від 1 до 256) до якого зображення з дійсним кольором може бути квантованим, якщо воно не може бути безпосередньо відображеним. Однак, рекомендується щоб для даної цілі використовувалась послідовність sPLT, ніж послідовність PLTE. Якщо жодна з послідовностей PLTE i sPLT не присутня і зображення не може бути безпосередньо відображеним, квантування повинно виконуватися за допомогою системи відображення. Однак, найкраще для секції кольорів бути згенерованою одноразово кодером PNG. (Перегляньте 12.6 Пропоновані палітри).

11.2.4 Дані зображення IDAT

Чотирибайтове поле типу послідовності містить наступні десяткові значення:
73 68 65 84
Послідовність IDAT містить безпосередні дані зображення, які являються вивідним потоком алгоритму стиснення. Перегляньте пункт 9: Фільтрування і пункт 10: Стиснення для деталей. Дозволено мати множинні послідовності IDAT у зображенні; в такому випадку вони повинні з'являтися послідовно без інших послідовностей між ними. Стиснений потік даних являється конкатенацією вмісту полів даних усі послідовностей IDAT.

11.2.5 Завершувач зображення IEND

Чотирибайтове поле послідовності містить наступні десяткові значення:
73 69 78 68
Послідовність IEND помічає кінець послідовності PNG. Дані даної послідовності являються пустими.

11.3 Підпорядковані послідовності

11.3.1 Загальне

Список підпорядкованих послідовностей, визначених у цьому Міжнародному Стандарті, міститься у 4.7.2: Типи послідовностей. Це не є порядок у якому вони з'являються у потоці даних PNG. Підпорядковані послідовності можуть ігноруватися декодером. Для кожної підпорядкованої послідовності, дії описані з припущенням, що декодер не ігнорує дану послідовність.

11.3.2 Інформація прозорості

11.3.2.1 tRNS Прозорість
Чотирибайтове поле типу послідовності містить наступні десяткові значення
116 82 78 83
Послідовність tRNS визначає значення компоненту прозорості, які асоціюються з входженнями палітри (для колір-індексних зображень) або один колір прозорості (для зображень з градаціями сірого або дійсним кольором). Послідовність tRNS містить:
Тип кольору 0
Значення семплів сірого 2 байти
Тип кольору 2
Значення семплів червоного 2 байти
Значення семплів синього 2 байти
Значення семплів зеленого 2 байти
Тип кольору 3
Значення прозорості для палітри за індексом 0 1 байт
Значення прозорості для палітри за індексом 1 1 байт
і т.д. 1 байт
Для типу кольору 3 (індекс-колірні), послідовність tRNS містить серії однобайтових значень прозорості, які відповідають позиціям послідовності PLTE. Кожна позиція означає, що пікселі відповідного індексу палітри повинні трактуватися такими, які мають асоційоване значення прозорості. Значення компоненту прозорості повинні інтерпретуватися у якості восьмибітного каналу прозорості: 0 являється повністю прозорим, 255 являється не прозорим, не зважаючи на глибину бітів зображення. Послідовність tRNS не повинна містити більше значень компоненту прозорості ніж присутніх входжень палітри, але послідовність tRNS може містити меншу кількість значень, ніж входжень палітри. У даному випадку, значення компоненту прозорості для усіх останніх входжень палітри вважається 255. У загальному випадку у якому тільки індекс палітри 0 повинен бути прозорим, потребується тільки однобайтова послідовність tRNS, і коли усі індекси палітри являються не прозорими, послідовність tRNS може бути опущеною. Для типів кольору 0 або 2, два байти на семпл використовуються не зважаючи на глибину бітів зображення (перегляньте 7.1: Цілі числа і порядок байтів). Пікселі вказаного значення семплу градацій сірого або значення семплу RGB трактуються як прозорі (еквівалентними до значення 0); усі інші пікселі повинні трактуватися у якості не прозорих (значення компоненту прозорості 2глибинабітів-1). Якщо глибина бітів зображення являється меншою ніж 16, останній значущий біт використовується і інші встановлюються у 0. Послідовність tRNS не повинна бути присутньою при використанні типів кольору 4 і 6, оскільки повний канал прозорості вже присутній у цих випадках. Зверніть увагу, що для 16-бітних градацій сірого і даних дійсного кольору, тільки пікселі, які співпадають з усіма 16-бітними значеннями послідовності tRNS являються прозорими. Декодери повинні відкладати масштабування будь-якої глибини семпла поки пікселі не будуть протестованими на прозорість.

11.3.3 Інформація просторів кольору

11.3.3.1 cHRM Головна кольоровість і білі точки
Чотирибайтне поле типу послідовності містить наступні десяткові значення:
99 72 82 77
Послідовність cHRM може бути використаною для вказування кольоровості 1931 CIE x,y червоного, зеленого і синього головних кольорів, які використовуються у зображенні, і білу точку. Перегляньте Додаток В: Гамма і кольоровість для детальнішої інформації. Послідовності iCCP i sRGB забезпечують більш витончену підтримку управління кольором. Послідовність cHRM містить:
Біла точка x 4 байти
Біла точка y 4 байти
Червоне x 4 байти
Червоне y 4 байти
Червоне y 4 байти
Зелена x 4 байти
Зелена y 4 байти
Синя x 4 байти
Синя у 4 байти
Кожне значення кодується у якості чотирибайтового беззнакового цілого PNG, яке представляє значення x або помножене на 100000. Приклад значення 0.3127 буде зберігатися у якості цілого 31270. Послідовність cHRM дозволена в усіх потоках PNG, хоча воно має мале значення для зображень з градаціями сірого. Послідовність sRGB або iCCP, коли присутні і розпізнаються, переписують значення послідовність cHRM.
11.3.3.2 Гамма зображення  gAMA
Чотирибайтне поле типу послідовності містить наступні десяткові значення:
103 65 77 65
Послідовність gAMA визначає взаємозв'язок між семплами зображення і бажаною інтенсивністю відображення. Гамма визначена у 3.1.20: Гамма. Фактично, вказування бажаної інтенсивності відображення недостатньо. Також потрібно вказувати умови оглядання за якими повинен виконуватися вивід. Для gAMA ці виноски умов оглядання специфікації RGB [IEC 61966-2-1], які засновані на ISO 3664 [ISO-3664]. Налаштування для різних умов оглядання зазвичай обробляється за допомогою Системи Управління Кольором. Якщо налаштування не виконується, зазвичай, помилка не суттєва. Зображення, які розроблені для високої точності кольору можуть використовувати послідовність sRGB або iCCP. Послідовність gAMA містить:
Гамма зображення 4 байти
Значення кодується у якості чотирибайтового беззнакового цілого PNG, яке представляє значення гамми помноженим на 100000. Наприклад, значення гами 1/2.2 буде зберігатися у якості цілого числа 45455. Перегляньте 12.2: Оброблення гамми кодером і 13.13 Обробка гамми декодером для деталей. Послідовність sRGB або iCPP, коли присутні і розпізнані, перезаписують значення послідовності gAMA.
11.3.3.3 Вбудований профіль ICC послідовність iCCP
Чотирибайтове поле типу послідовності містить наступні десяткові дані:
105 67 67 80
Послідовність iCCP містить:
Ім'я профілю 1-79 байті (послідовність символів)
Нульовий роздільник 1 байт (нульовий символ)
Метод компресії 1 байт
Стиснений профіль n байтів
Ім'я профілю може являтися будь-якою зрозумілою назвою для звернення до профілю. Вона чутлива до регістру. Імена профілі повинні містити тільки друковані (видимі) символи Latin-1 і пробіли (дозволяються тільки десяткові коди символів 32-126 і 161-255). Не дозволяються пробіли з переду, ззаду, і проміжні пробіли рядка. Єдиний метод компресії, визначений у даному Міжнародному Стандарті, являється методом 0 (потік даних zlib з компресією deflate, перегляньте 10.3: Використання іншої компресії). За входженням методу компресії слідує стиснений профіль, який являється завершенням послідовності. Декомпресія цього потоку даних надає вбудований профіль ICC. Якщо присутня послідовність iCCP, семпли зображенні відповідають простору кольору представленому за допомогою профілю ICC, за визначенням Міжнародного Консорціюму Кольору [ICC]. Простір кольору профілю ICC повинен бути простором кольору RGB для кольорових зображення (типи кольору PNG 2, 3 і 6), або простір градації сірого для сірих зображень (тип кольору PNG 0 i 4). Рекомендується, щоб кодер PNG, який створює послідовність iCCP, вміщував також послідовності gAMA i cHRM, які подібні до профілю ICC, що забезпечує сумісність з програмами, які не використовують послідовність iCCP. Коли присутня послідовність iCCP, декодери PNG, які розпізнають її і спроможні на управління кольором [ICC] повинен ігнорувати послідовності gAMA i cHRM і натомість використовувати послідовність iCCP для її інтерпретування у відповідності до [ICC-1] i [ICC-1A]. Декодери PNG, які використовують середовище, що не спроможне на повне управління кольором повинні використовувати послідовності gAMA i cHRM у разі їх присутності. Потік даних повинен містити хоча б один вбудований профіль, який вказаний за допомогою послідовності iCCP, або через послідовність sRGB.
11.3.3.4 Значущі біти sBIT
Чотирибайтове поле типу послідовності містить наступні десяткові значення:
115 66 73 84
Для спрощення декодерів, PNG вказує, що можуть бути використаними тільки певні глибини семплів, і також що значення семплів можуть бути масштабованими до повного проміжку можливих значень при глибині семплів. Послідовність sBIT визначає оригінальну кількість значущих бітів (яка може бути меншою, або такою ж, як глибина семлів). Це дозволяє декодерам PNG безвтратно відновлювати оригінальні дані, навіть якщо дані мають глибину, яка PNG безпосередньо не підтримує. Послідовність sBIT містить:
Тип кольору 0
Значущі біти сірого 1 байт
Тип кольору 2 і 3
Значущі біти червоного 1 байт
Значущі біти зеленого 1 байт
Значущі біти синього 1 байт
Тип кольору 4
Значущі біти сірого 1 байт
Значущі біти прозорості 1 байт
Тип кольору 6
Значущі біти червоного 1 байт
Значущі біти зеленого 1 байт
Значущі біти синього 1 байт
Значущі біти прозорості 1 байт
Кожна глибина, яка вказана у послідовності sBIT повинна бути більшою ніж нуль і меншою або еквівалентною глибині семплів (яка має значення 8 для індекс-колірних зобржень, і глибині бітів наданій у послідовності IHDR для інших типів кольору). Зверніть увагу, що sBIT не забезпечує глибину семплів для каналу прозорості, яка застосовується за допомогою послідовності tRNS; у цьому випадку, усі біти семплів каналу прозорості повинні трактуватися у якості значущих. Якщо послідовність sBIT не присутня, тоді усі біти семплів усіх каналів повинні трактуватися у якості значущих.
11.3.3.5 sRGB Стандартний простір кольорів RGB
Чотирибайтове поле типу послідовності містить наступні десяткові значення:
115 82 71 66
Якщо послідовність sRGB наявна, семпли зображення відповідають простору кольору sRGB [IEC 61966-2-1] і повинні бути відображеними використовуючи вказаний намір рендерингу, який визначений у Міжнародному Консорцію Кольору [ICC-1] і [ICC-1A]. Послідовність sRGB містить:
Намір рендерингу 1 байт
Наступні значення визначаються для наміру рендерингу:
0 перцептивний для зображень, які надають перевагу хорошій адаптації до гамми пристрою, за рахунок точності колористики, на подобі фотографій
1 Відносно колориметричні для зображень, які вимагають співпадання відображеного кольору (відносно до білої точки пристрою виводу), на подобі логотипів
2 Насичення для зображень, які надають перевагу збереженню насичення за рахунок відтінку і яскравості, на подобі діаграм
3 Абсолютно колориметричні Для зображень, які вимагають збереження абсолютної колорометрики, на подобі переглядачів зображень, які призначені для інших пристроїв виведення (proofs).
Рекомендується, що кодери PNG, які записують послідовність sRGB також записували послідовність gAMA (і необов'язково послідовність cHRM) для сумісності з декодерами, які не використовують послідовність sRGB. Тільки наступні значення повинні бути використаними.
gAMA
Гамма 45455
cHRM
Біла точка x 31270
Біла точка y 32900
Червоне x 64000
Червоне y 33000
Зелене x 30000
Зелене y 60000
Синє x 15000
Синє y 6000
Коли послідовність sRGB наявна, рекомендується, що декодери, які розпізнають її і спроможні на управління кольором [ICC] ігнорують послідовності gAMA i cHRM, і використовують значення надані вище так, ніби вони були вказаними у послідовностях gAMA i cHRM. Рекомендується, що послідовності sRGB i iCCP не з'являлися одночасно у потоці даних PNG.

11.3.4 Текстова інформація

11.3.4.1 Вступ
PNG забезпечує послідовності tEXt, iTXt i zTXt для збереження текстових рядків, асоційованих з зображенням, на подобі опис зображення або нотатка прав власності. Ключові слова використовуються для показування, що кожен текстовий рядок представляє. Будь-яка кількість таких текстових послідовностей можуть з'являтися у зображенні, і більше ніж одна може з'являтися з одним ключовим словом.
11.3.4.2 Ключові слова і текстові рядки.
Визначені наступні ключові слова і повинні використовуватися відповідно.
Title (Заголовок) Короткий (один рядок) заголовок для зображення
Author (Автор) Ім'я творця зображення
Description (Опис) Опис зображення (можливо довгий)
Copyright (Право копіювання) Нотатка прав копіювання
Creation Time (Час створення) Час створення оригінального зображення
Software (Програмне забезпечення) Програмне забезпечення, яке використовувалось для створення зображення
Disclaimer (Відмова) Законна відмова
Warning (Застереження) Застереження про вміст зображення
Source (Джерело) Пристрій, який використовувався для створення зображення
Comment (Коментар) Різні коментарі
Інші ключові слова можуть бути визначеними для інших цілей. Ключові слова для загального зацікавлення можуть бути зареєстрованими у Органі Реєстрації PNG (перегляньте 4.9: Розширення і реєстрація). Також дозволено використовувати приватні незареєстровані ключові слова. (Призначення приватного ключового слова повинно бути зрозумілим з його назви, щоб мінімізувати шанс, що однакове ключове слово буде використовуватися для несумісних цілей різними людьми). Ключові слова повинні містити тільки видимі символи Latin-1 [ISO-8859-1] і пробіли; тобто дозволені тільки десяткові коди символів 32-126 і 161-255. Для зменшення шансів неправильного читання людиною ключового слова, початкові пробіли рядка, пробіли за рядком і проміжні множинні послідовності пробілів не допустимі у ключових словах, а також заборонене використання не розбиваючого пробілу (код 160), оскільки його візуально не можна відрізнити від звичайного пробілу. Ключові слова повинні бути вказаними точно так, як вони зареєстровані, отож декодери можуть використовувати прості літеральні порівняння під час пошуку певного ключового слова. Зокрема, вважається, що ключові слова являються чутливими до регістру. Ключові слова обмежені у довжині від 1 до 79 байтів. Для ключового слова Часу Створення пропонується формат дати визначений у секції 5.2.14 документу RFC 1123, але не обов'язковий [RFC-1123]. У послідовностях tEXt s zTXt, текстовий рядок асоційований з ключовим словом обмежений у використанні тільки набору символів кодування Latin-1 у добавок до символу переведення рядка. Текстовий рядок у послідовності zTXt являється стисненим у потоки даних zlib, використовуючи компресію deflate (перегляньте 10.3: Використання інших компресій). Послідовність iTXt може використовуватися для передачі символів відмінного кодування ніж множина Latin-1. Вона використовує кодування UTF-8 для UCS [ISO/IEC 10646-1]. Існує опція для стиснення текстових рядків у послідовності iTXt.
11.3.4.3 Текcтові дані tEXt
Чотирибайтове поле типу послідовності містить наступні десяткові значення:
116 69 88 116
Кожна послідовність tEXt містить ключове слово і текстовий рядок у форматі:
Ключове слово 1-79 байтів (рядок символів)
Нульовий розділювач 1 байт (символ з значенням нуля)
Текстовий рядок 0 або більше байт (рядок символів)
Ключові слова і текстові рядки розділені за допомогою нульового байту (символ null, з значенням нуля). Ключове слово і текстовий рядок не можуть містити в собі нульовий символ. Текстовий рядок не повинен закінчуватись нульовим символом (довжина послідовності визначає кінець). Текстовий рядок може мати будь-яку довжину від нуля байтів аж до максимального дозволеного розміру послідовності мінус довжину ключового слова і символу роздільника (нульового символу). Ключове слово відображає тип інформації, яка містить у рядку символів як описано у 11.3.4.2: Ключові слова і текстові рядки. Текст інтерпретується у відповідності до системи кодування символів Latin-1 [ISO-8859-1]. Текстовий рядок може містити будь-який символ Latin-1. Символи нового рядка у текстових рядках повинні відображатися єдиним символом переведення рядка (десятковий код 10). Символи інші ніж визначені у Latin-1 в добавок символу переведення рядка не мають визначеного значення у послідовностях tEXt. Символи, які містяться за репертуаром системи ISO/IEC 8859-1 повинні бути закодованими, використовуючи послідовність iTXt.
11.3.4.4 Стиснені текстові дані zTXt
Чотирибайтове поле типу послідовності містить наступні десяткові значення:
122 84 88 116
Послідовності zTXt i tEXt семантично являються еквівалентними, але послідовність zTXt рекомендується для скорочення великих блоків тексту. Послідовність zTXt містить:
Ключове слово 1-79 байтів (рядок символів)
Нульовий розділювач 1 байт (символ з значенням нуля)
Метод компресії 1 байт
Потік стиснених даних N байтів
Ключове слово і нульовий символ являються такими самими як у послідовності tEXt (перегляньте 11.3.4.3: Текстові дані tEXt). Ключове слово не стискається. Поле методу компресії позначає використовуваний метод компресії. Єдине значення для цього поля, яке визначається даним Міжнародним Стандартом являється 0 (компресія deflate/inflate). Інші значення зарезервовані для майбутньої стандартизації (перегляньте 4.9 Розширення і реєстрація). Після методу компресії слідує стиснений потік даних, який і завершує послідовність. Для методу компресії 0, даний потік даних являється потоком даних zlib з методом компресії deflate (перегляньте 10.3: Використання інших методів компресії). Розпаковування даного потоку даних надає текст у системі Latin-1, який ідентичний до тексту, який повинен зберігатися у еквівалентній послідовності tEXt.
11.3.4.5 iTXt Міжнародні текстові дані
Чотирибайтове поле типу послідовності містить наступні десяткові значення:
105 86 88 116
Послідовність iTXt містить:
Ключове слово 1-79 байтів (рядок символів)
Нуль-роздільник 1 байт (нульовий символ)
Прапорець компресії 1 байт
Метод компресії 1 байт
Тег мови 0 або більше байтів
Нуль-роздільник 1 байт (нульовий символ)
Ключове слово перекладу 0 або більше байтів
Нульовий роздільник 1 байт (нульовий символ)
Текст 0 або більше байтів
Ключові слова описані у 11.3.4.2: Ключові слова і текстові рядки. Прапорець компресії 0 призначений для не стисненого тексту, значення 1 призначене для стисненого тексту. Стисненим може бути тільки поле тексту. Поле методу компресії визначає використовуваний метод компресії. Єдиний метод компресії, який визначений у даному Міжнародному Стандарті являється 0 (потік даних zlib з компресією deflate, перегляньте 10.3: Використання інших методів компресії). Для не стисненого тексту, кодери повинні встановлювати поле методу компресії у значення 0, і декодери повинні ігнорувати його. Тег мови визначений у документах [RFC-3066], які описуть людську мову, яка використовується для ключового слова перекладу у тексті. На відміну від ключового слова, поле тегу мови являється не чутливим до регістру. Воно являє собою рядок символів ISO 646.IRV:1991 [ISO 646], який складається з розділених тире словами з 1-8 символів довжини кожне (наприклад cn, en-uk, no-bok, x-klingon, x-KllnGoN). Якщо перше слово являється в довжину двох або трьох символів, воно представляє собою код мови ISO [ISO-639]. Якщо тег мови являється пустим, мова не вказана. Поля ключового слова перекладу і текст використовують систему збереження UTF-8 з набором символів UCS [ISO/IEC 10646-1], і не повинні містити нульовий байт (нульовий символ). Текст, не відміну від інших текстовий даних у цій послідовності, не закінчується нуль-символом; його довжина визначається з поля довжини послідовності. Символи переведення рядка не повинні з'являтися у ключовому слові перекладу. У тексті, символи переведення рядка повинні представляти собою один символ переведення рядка (десятковий код 10). Інші контролюючі символи (1-9, 11-31, 127-159) не рекомендуються до застосування у двох полях тексту і ключового слова перекладу. У UTF-8 існує різниця між символами 128-159 (які являються не рекомендованими) і байтами 128-159 (які часто являються необхідними). Перекладені ключові слова, якщо не пусті, повинні містити переклади ключових слів у мову, яку даний тег мови відображає, і програми, що відображають ключові слова повинні додатково відображати перекладене ключове слово.

11.3.5 Різнорідна інформація

11.3.5.1 Колір фону bKGD
Чотирибайтове поле типу послідовності може містити наступні десяткові значення:
98 75 71 68
Послідовність bKGD вказує колір заднього фону за умовчанням для презентації зображення. Якщо існує будь-яке інше бажане значення, або визначено користувачем, або частина більшої сторінки (у випадку браузера), послідовність bKGD повинна бути проігнорована. Послідовність bKGD містить:
Тип кольору 0 і 4
Градація сірого 2 байти
Тип кольору 2 і 6
Червоний 2 байти
Зелений 2 байти
Синій 2 байти
Тип кольору 3
Індекс палітри 1 байт
Для типу кольору 3 (індекс-колірних), значення являється індексом палітри кольору, який буде використовуватися у якості заднього фону. Для типів кольору 0 та 4 (градації сірого, градації сірого з прозорістю), значення являється рівнем сірого, який буде використовуватися у якості заднього фону у проміжку від 0 до (2глибинабітів)-1. Для типу кольору 2 і 6 (дійсний колір, дійсний колір з прозорістю), значення являються кольором, що буде використовуватися у якості кольору, наданий у якості RGB семплу у проміжку від 0 до (2глибинабітів)-1. У кожному випадку, використовуються два байти на семпл не зважаючи на глибину бітів зображення. Якщо глибина бітів зображення являється меншою ніж 16, останні значущі біти використовуються і інші являються 0.
11.3.5.2 Гістограма зображення hIST
Чотирибайтове поле типу послідовності містить наступні десяткові значення:
104 73 83 84
Послідовність hIST містить серії двобайтових (16-бітних) беззнакових цілих:
Частота 2 байти (беззнакове ціле)
і т.д.
Послідовність hIST надає приблизну частоту використання кожного кольору у палітрі. Послідовність гістограми може бути присутньою, якщо присутня послідовність PLTE. Якщо переглядачі не спроможні забезпечувати усі кольори зі списку палітри, гістограма може допомогти вирішити, як обрати підмножину кольорів для відображення. Повинно бути тільки одне входження для кожного входження послідовності PLTE. Кожний запис являється пропорційний частині пікселів у зображенні, які мають даний індекс палітри; даний коефіцієнт масштабування обирається кодером. Записи гістограми являються приблизними, за виключенням того, що нуль записів вказує, що відповідні входження палітри взагалі не використовуються у зображенні. Записи гістограми можуть бути не нульовими, якщо існують пікселі даного кольору. Зверніть увагу. Коли палітра являється пропонованим квантуванням дійсного кольору, гістограма являється приблизною, оскільки декодер може перетворювати пікселі у входження палітри по-іншому ніж це робить кодер. У даній ситуації, за нормальних обставин, відсутність записів не повинна з'являтися, тому-що може бути використаним будь-яке значення.
11.3.5.3 Фізичні розміри пікселя pHYs
Чотирибайтове поле типу послідовності містить наступні десяткові значення:
112 72 89 115
Послідовність pHYs вказує призначений розмір пікселів або співвідношення сторін для відображення зображення. Воно містить:
Пікселів на одиницю, ось X 4 байти (беззнакове ціле PNG)
Пікселів на одиницю, ось Y 4 байти (беззнакове ціле PNG)
Одиниці вимірювання 1 байт
Наступні значення визначені для поля одиниць:
0 не відома одиниця
1 одиниця являється метром
У випадку, коли поле одиниці містить значення 0, послідовність pHYs визначає тільки співвідношення сторін пікселів; фактичні розміри пікселів залишаються не визначеними. Якщо послідовність pHYs не присутня, пікселі вважаються квадратними. і фізичний розмір кожного пікселя не визначений.
11.3.5.4 Пропонована палітра sPLT
Чотирибайтове поле типу послідовності містить наступні десяткові значення:
115 80 76 84
Послідовність sPLT містить:
Ім'я палітри 1-79 байтів (рядок символів)
Нульовий роздільник 1 байт (нульовий символ)
Глибина бітів 1 байт
Червоний 1 або 2 байти
Зелений 1 або 2 байти
Синій 1 або 2 байти
Компонент прозорості 1 або 2 байти
Частота 2 байти
і т.д.
Кожний запис палітри складається з 6 або 10 байтів, які містять п'ять беззнакових цілих (червоний, зелений, синій, прозорість і частота). Може бути будь-яка кількість записів. Декодер PNG визначає кількість входжень з довжини послідовності, мінус довжину даних, які містяться до байту глибини семплів. Дана довжина даних повинна бути кратною 6 (можливість поділити на 6), якщо глибина семплів sPLT являється 8, або кратною 10, якщо глибина семплів sPLT є 16. Записи повинні з'являтися у спадаючому порядку по частоті. Немає вимоги, що усі входження будуть використаними у зображенні, ні що вони усі будуть різними. Ім'я палітри може бути будь-яким зрозумілим ім'ям, для звернення до неї (наприклад, "256 colour including Macintosh default", "256 colour including Windows-3.1 default", "Optimal 512"). Ім'я палітри може допомогти обрати відповідну пропоновану палітру у випадку множинних палітр у потоці даних PNG. Назва палітри є чутливою до регістру, і являється суб'єктом обмежень, які застосовуються до параметру ключового слова для послідовності tEXt. Імена палітр повинні містити тільки видимі символи системи Latin-1 і пробіли (дозволені тільки десяткові коди символів 32-126 і 161-255). Пробіли перед ім'ям, після нього і послідовності пробілів не дозволені. Глибина семплів sPLT повинна бути 8 або 16. Семпли червоного, зеленого, синього і компоненту прозорості являються одним або двома байтами кожен, в залежності від глибини семплів sPLT, не зважаючи на глибину бітів. Семпли кольору не перемножені на значення прозорості, і не являються компонованими з заднім фоном. Значення 0 компонента прозорості означає повну прозорість. Значення 255 компоненту прозорості (коли глибина семплів є 8) або 65535 (коли глибина семплів являється 16) означає непрозорість. Послідовність sPLT може з'являтися для будь-якого типу кольору PNG. Записи у sPLT використовують однакові значення гамми і кольоровості як і зображення PNG, але можуть випадати з проміжку значень які використовують у просторі кольору зображення PNG; наприклад, у зображенні PNG з градаціями сірого, кожний запис sPLT може зазвичай мати однакові червоні, зелені і сині значення, але це не вимагається. Подібно, записи sPLT можуть мати не прозоре значення компоненту прозорості навіть коли зображення PNG не використовує прозорість. Кожне значення частоти являється пропорційною до кількості частини пікселів у зображення для якого даний запис палітри являється найближчим у просторі RGBA, перед тим, як зображення є компонованим з будь-яким заднім фоном. Точний коефіцієнт масштабування обирається декодером PNG; рекомендується, що результуючий проміжок індивідуальних значень відчутно заповнює проміжок від 0 до 65535. Кодер PNG може штучно збільшувати частоти для кольорів, які вважаються "важливими", наприклад кольори можуть бути використаними у логотипах, або лицеві властивості портрету. Нуль являється валідною частотою, яка означає, що колір являється найменш "важливим", або що він рідко, якщо взагалі, використовується. Коли усі частоти являються нульовими, вони не означають нічого, тобто, ми не можемо судити про фактичні частоти з якими кольори з'являються у зображенні PNG. Дозволяється множина присутніх послідовностей sPLT, але кожна повинна мати інше ім'я палітри.

11.3.6 Інформація про час

11.3.6.1 Останній час модифікації зображення tIME
Чотирибайтове поле типу послідовності містить наступні десяткові значення:
116 73 77 69
Послідовність tIME надає час останньої модифікації зображення (але не час створення зображення). Воно містить:
Рік 2 байти (повністю; наприклад, 1995, а не 95)
Місяць 1 байт (1-12)
День 1 байт (1-31)
Година 1 байт (0-23)
Хвилина 1 байт (0-59)
Секунда 1 байт (0-60)
Повинен вказуватись Універсальний Час (UTC), а не локальний. Послідовність tIME призначена для використання у якості автоматично записаного часу, яка оновлюється кожного разу коли дані зображення змінюються.

12 Кодери PNG

12.1 Вступ

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

12.2 Обробка гамми кодером

Перегляньте Додаток В: Гамма і кольоровість для зрозумілого вступу у проблеми з гаммою. Кодери PNG спроможні на повне управління кольором [ICC] будуть виконувати більш складні обчислення, ніж описані тут і можуть обрати використання послідовності iCCP. Відомо, що семпли зображення відповідають до специфікації sRGB [IEC 61966-2-1], кодерам рекомендується записувати послідовність sRGB без виконання додаткової обробки гамми. У двох випадках рекомендується, що відповідна послідовність gAMA генерується для використання декодерами PNG, які не розпізнають послідовність iCCP або послідовність sRGB. Кодер PNG повинен визначати: а. яке значення записувати у послідовність gAMA; б. як перетворювати семпли наданого зображення у значення, які будуть записуватись у потік даних PNG. Значення, яке записується у послідовність gAMA являється таким, що спричиняє бажану поведінку PNG декодера. Перегляньте 13.13: Обробка гамми декодером. Перетворення, яке застосовується залежить від природи семплів зображення і їхньої точності. Якщо семпли представляють легку інтенсивність у дійсному числі або високій точності у цілочисельній формі (можливо від створювача комп'ютерної графіки), кодер може виконувати "кодування гамми" (застосування степеневої функції з експонентою меншою 1) перед квантування даних до цілих значень для включення у потік даних PNG. Це спричиняє зменшення артефактів в даній глибині семплів, або дозволяє використовувати менші семпли при однаковій візуальній якості. Рівень інтенсивності виражений у якості дійсного значення у проміжку від 0 до 1 може бути перетвореним у семпл потоку даних зображення за допомогою: integer_sample = floor((2sampledepth-1) * intensityencoding_exponent + 0.5) Якщо інтенсивність у рівнянні являється бажаною вихідною інтенсивністю, експонента кодування являється значенням гамми, яке буде використовуватися у послідовності gAMA. Якщо доступна інтенсивність для кодера PNG являється оригінальною інтенсивністю сцени, може виникнути потреба у інших перетвореннях. Інколи існує вимога вищого контрасту для відображеного зображення, ніж у оригінальній сцені. Це відповідає функції передачі кінець-до-кінця (end-to-end) від оригінальної сцени до виходу дисплею з експонентою більшою за 1. У цьому випадку: gamma = encoding_exponent/end_to_end_exponent Якщо не відомо чи умови за яких було зроблено або обчислене оригінальне зображення, можна припускати, що інтенсивність відображення являється пропорціональною до інтенсивності оригінальної сцени, тобто, експонента функції кінець-до-кінця (end-to-end) являється 1: gamma = encoding_exponent Якщо зображення було записано у потік даних, кодер може вільно обирати експоненту кодування. Обираючи значення гамми у послідовності gAMA 1/2.2, часто являється розумним вибором, через те, що це мінімізує роботу декодера PNG при відображенні на звичайний монітор. Деякі створювачі зображень можуть одночасно записувати зображення у потік даних PNG і відображати його на екран. Відображені пікселі повинні бути корегованими відносно гамми для системи відображення і умов переглядання, отож користувач буде оглядати правильне представлення сцени. Якщо створювач зображення бажає записувати відображені значення семплів у потік даних PNG, запобігаючи відокремлення кроку обчислення гамми для потоку даних, він повинен приблизити функцію передачі системи відображення за допомогою степеневої функції, і записувати відповідну експоненту у послідовність gAMA. Це дозволить декодеру PNG відтворити те, що було відображено на екрані за допомогою створювача зображення під час рендерингу. Однак, еквівалентно розумно для створювача зображення обчислювати відображені пікселі у відповідності до пристрою відображення, і виконувати окреме кодування гамми для збережених даних і передавання, що призводить до створення значення у послідовності gAMA більш відповідним для майбутнього використання у зображенні. Створювачі зображень комп'ютерної графіки часто не виконують кодування гамми, натомість роблять значення семплів прямо пропорційним до інтенсивносці сцени. Якщо кодер PNG отримує значення семплів, які вже квантовані у цілі значення, немає ніякого сенсу у виконанні кодування гамми для нього; оскільки це ще більше призведе до втрати інформації. Кодер повинен просто записувати семпли у потік даних PNG. Це не означає, що послідовність gAMA повинна містити значення 1.0, тому що бажана функція передачі кінець-до-кінця (end-to-end) з інтенсивності сцени до інтенсивності виводу у дисплей не обов'язково являється лінійною. Однак, бажане значення гамми, мабуть, близьке до значення 1.0. Це може залежати від того чи сцена була створена у якості сцени з денним світлом або сцени у приміщенні, або що. Коли значення семплів йдуть прямо з якогось пристрою, коректне значення gAMA, в принципі, може отримуватися з функції передачі пристрою і умов освітлення сцени. У випадку відео оцифровувачів ("frame grabbers" - захоплювачів кадрів), семпли, можливо, містяться у просторі sRGB, через те, що специфікація sRGB була призначена для сумісності з сучасними відео стандартами. Сканери зображення являються менш передбачуваними. Їхні семпли виводу можуть бути пропорційними до інтенсивності світла введення оскільки сенсори CCD самі по собі являються лінійними, або пристрій сканера може застосовувати степеневу функцію, яка розроблена для компенсації у наступних відображеннях (експонента рівна приблизно 0,57), або сканер може корегувати семпли для відображення на моніторі. Може виникнути необхідність звернутися до інструкції сканера або сканування відкаліброваної цілі, щоб визначити характеристики конкретного сканера. Необхідно пам'ятати, що гамма відноситься до семплів для бажаного виводу на дисплей, а не до введення сканера. Перетворювачі формату потоку в загальному не повинні перетворювати надані зображення у інше значення гамми. Дані повинні бути збереженими у потоці даних PNG без перетворення, і значення гамми, за наявної можливості, повинно бути виведеною з інформації джерельного потоку даних. Змінна значення гамми під час перетворення потоків даних спричиняє повторне квантування набору рівнів інтенсивності, які присутні, що вводить помилку округлення з маленькою вигодою. Майже завжди краще просто скопіювати значення семплів не перетвореними з джерела до кінцевого файлу. Якщо джерельний потік даних описує характеристики гамми зображення, рекомендується, що перетворювач потоку даних запише послідовність gAMA. Деякі формати потоків даних вказують експоненту відображення (експонента функції, яка скоріш перетворює семпли зображення до виводу на дисплей, ніж на інший вивід). Якщо гамма джерельного файлу являються більшими за 1.0, це скоріш за все експонента дисплею, і зворотнє даному значення повинно використовуватися у значенні гамми PNG. Якщо джерельний формат записує відносини між семплами зображення і значення інше ніж вивід дисплею, буде набагато важче отримати значення гамми PNG. Якщо кодер PNG або перетворювач потоку даних знає, що зображення було відображено задовільно, використовуючи системи, функції передачі яких можуть бути приближеними за допомогою степеневої функції з експонентою display_exponent, зображення може бути означене як таке, яке має значення: gamma = 1/display_exponent Краще записувати послідовність gAMA з значенням, яке приблизно коректне, ніж її опустити і змусити декодерів PNG вгадувати приблизне значення гамми. Якщо кодер PNG не в спромозі визначити значення гамми, краще опустити послідовність gAMA. Якщо необхідно самостійно визначати дане значення, це повинно бути залишеним декодеру PNG. Гамма не застосовується до семплів компоненту прозорості; компонент прозорості завжди представляється лінійно. Перегляньте також 13.13: Обробка гамми декодером.

12.3 Обробка кольору кодером.

Перегляньте Додаток В: Гамма і кольоровість для отримання виносків по питанням з кольором. PNG кодери спроможні на повне управління кольором [ICC] будуть виконувати більш складні обрахунки, по відношенню до описаних тут механізмів, і вони можуть обирати використання послідовності iCCP. Якщо відомо, що семпли зображення відповідають специфікації sRGB [IEC 61966-2-1]. Декодерам PNG рекомендується використовувати послідовність sRGB. Якщо можливо для кодера визначити кольоровість джерельного відображення, або виконувати точне вгадування засноване на оригінальному зображенні, або якщо апаратне забезпечення надає його, рекомендується, щоб кодери створювали послідовність cHRM. Якщо так, послідовність gAMA також повинна бути створеною; декодери можуть виконати деякі додаткові обчислення з послідовності cHRM, якщо послідовність gAMA відсутня. Існує множина рекомендацій і стандартів для головних ознак і білих точок, деякі з яких зв'язані з певними технологіями, наприклад, CCIR 709 стандарт [ITU-R-BT709] і стандарт SMPTE-C [SMPTE-170M]. Існує три випадки, які повинні бути розглянутими: а. Кодер являється частиною системи генерації; б. Джерельне зображення захоплюється камерою або сканером; в. Потік даних PNG був згенерованим за допомогою перетворення з одного формату у інший. У випадку рукотворної або цифрової обробки зображень, необхідно визначити, який монітор використовувався під час створення. Велика кількість редакторів зображення дозволяють вказувати тип монітора, який використовувався. Часто це спричинене внутрішньою роботою у деякому просторі, незалежному від пристроїв. Такі програми мають достатньо інформації для створення валідних послідовностей cHRM і gAMA, і рекомендується, щоб вони це виконували автоматично. Якщо кодер скомпільований у якості частини генератора комп'ютерних зображень, які виконують повноспектральний рендеринг, значення монітора, які використовувалися для перетворення з внутрішнього апаратно незалежного простору кольорів у RGB, повинні записувати у послідовність cHRM. Будь-які кольори, які являються ззовні гамми обраного пристрою RGB повинні бути перетвореними до проміжку гамми; PNG не зберігає кольори які виходять за межі гамми. Якщо створювач комп'ютерних зображень виконує прямі обрахунки у апаратно залежному просторі RGB, послідовність cHRM не повинна створюватись, окрім випадку, коли опис сцени і параметри рендерингу були налаштованими для певного монітору. У даному випадку, дані для даного монітору повинні використовуватись у конструюванні послідовності cHRM. Декілька форматів зображень зберігають інформацію про калібрування, яка може бути використаною для заповнення послідовності cHRM. Наприклад, файли TIFF 6.0 [TIFF-6.0] не обов'язково може зберігати інформацію про калібрування, яка, якщо присутня, може використовуватися для конструювання послідовності cHRM. Відео створене за допомогою попереднього відео-устаткування використовує параметри CCIR 709 i білу точку D64 [ITU-R-BT709], які надані у Таблиці 12.1. Таблиця 12.1 - CCIR 709 параметри і біла точка D65
R G B Біла
x 0.640 0.300 0.150 0.3127
y 0.330 0.600 0.060 0.3290
Старіший, але ще до цих пір популярний відео-стандарт SMPTE-C [SMPTE-170M] наданий у таблиці 12.2. Таблиця 12.2 - Стандарт відео SMPTE-C
R G B Біла
x 0.630 0.310 0.155 0.3127
y 0.340 0.595 0.070 0.3290
Не рекомендується, що перетворювачі формату потоку даних намагаються перетворити надані зображення у інший простір кольору RGB. Дані повинні бути збереженими у потоці даних PNG без перетворення і джерельні параметри кольоровості повинні бути записаними так, ніби вони відомі. Перетворення простору кольорів під час перетворення потоку даних являється поганою ідеєю через помилки гамми і помилки округлення. Щодо перетворень гамми, кращою ідеєю являється збереження даних безвтратно і виконувати тільки одне перетворення коли зображення вже відображається. Перегляньте також 13.14: Обробка кольору декодером.

12.4 Створення каналу прозорості

Канал прозорості може вважатися у якості маски, яка тимчасово прикриває прозорі частини зображення, або у якості механізму створення не прямокутного зображення. У першому випадку, значення кольору повністю прозорих пікселів повинні бути збереженими для майбутнього використання. У другому випадку, прозорі пікселі не несуть жодної корисної інформації і просто присутні там для заповнення прямокутної області зображення, яку вимагає PNG. У даному випадку, повністю прозорим пікселям повинно бути присвоєне один колір з оглядом на найкращу компресію. Автори зображень повинні пам'ятати про можливість, що декодер може повністю не підтримувати контроль над прозорістю у повній мірі (перегляньте 13.16: Обробка каналу прозорості). Отже кольори присвоєні для повністю прозорих пікселів повинні, за можливості, добре компонуватися з цілим зображенням. Для програм, що не вимагають повний канал прозорості, або не можуть надавати ціну ефективності компресії, доступна послідовність прозорості tRNS. Якщо зображення має відомий колір заднього фону, даний колір повинен бути записаний у послідовність bKGD. Навіть декодери, які ігнорують прозорість можуть використовувати колір bKGD для заповнення не використаної площі екрану. Якщо оригінальне зображення має перемножені (також називається "асоційовані") дані прозорості, вони можуть бути перетвореними у формат PNG для розділених даних, за допомогою розділення кожного значення семплу на відповідне значення прозорості, після чого помножити на максимальне значення глибини бітів зображення, і округлене до найближчого цілого числа. У валідних перемножених даних, значення семплів ніколи не перевищують їхні відповідні значення прозорості, отож результат ділення повинен завжди міститись у проміжку від 0 до 1. Якщо значення прозорості являється 0, виведення повинно бути чорним (нулі).

12.5 Масштабування глибини семплів

Під час кодування ввідних семплів, які мають глибину семплів, яка не може прямо представлятися у PNG, декодер повинен виконати масштабування семплів щоб отримати глибину семплів, яка дозволяється форматом PNG. Найбільш точний метод масштабування являється наступне лінійне рівняння: output = floor((input * MAXOUTSAMPLE / MAXINSAMPLE) + 0.5) де вхідні семпли містяться у проміжку від 0 до MAXINSAMPLE і вивід міститься у проміжку від 0 до MAXOUTSAMPLE (який являється 2sampledepth-1). Близьким приближенням методу лінійного масштабування досягається за допомогою "дублюванням лівих бітів", що являє собою зміщення валідних бітів на початк у найбільш значущому біті і дублювання найбільш значущих бітів у незайнятих бітах. Даний метод часто являється швидшим для обчислення ніж лінійне масштабування. Приклад. Припустимо, що 5-бітні семпли масштабуються до 8 бітів. Якщо значення джерельних семплів являється 27 (у проміжку 0-31), тоді оригінальні біти будуть виглядати:
4 3 2 1 0
---------
1 1 0 1 1
Повторення лівих бітів дає значення 222:
7 6 5 4 3  2 1 0
----------------
1 1 0 1 1  1 1 0
|=======|  |===|
    |      Найлівіші біти повторені для заповнення не заповнених
    |
Оригінальні біти
що співпадає з значенням, обчисленим за допомогою лінійної функції. Дублювання лівих бітів зазвичай дає однакове значення з лінійним масштабуванням, і ніколи не помиляється більше ніж на 1. Відчутно менш точне приближення надається за допомогою лівого зміщення вхідного значення і заповнення незначущих бітів нулями. Дана схема не може відтворити білий точно, оскільки він не генерує максимальне значення з всіма бітами встановленими у 1; у результаті зображення стає трішки темнішим. Даний метод не рекомендується в загальному випадку, але він має ефект покращення компресії, особливо з глибинами бітів більшими за 8 біт. Оскільки відносна помилка впроваджується за допомогою масштабування заповненням нулями, являється малою при великих глибинах семплів, деякі кодери можуть обрати його для використання. Заповнення нулями не повинно використовуватися для даних каналу прозорості, однак, оскільки велика кількість декодерів трактують значення прозорості з усіх нулів і усіх одиниць у якості спеціальних випадків, важливо представляти обидва ці значення точно у масштабованих даних. Коли кодер записує послідовність sBIT, вимагається виконання масштабування шляхом, який високо-значущі біти збережених семплів збігаються з оригінальними даними. Тобто, послідовність sBIT вказує глибину семплів глибини S-бітів, високо-значущі біти S збережених даних повинні збігатися з оригінальними значеннями даними S-бітів. Це дозволя декодерам відновлювати оригінальні дані за допомогою зміщення вправо. Додані низько-значущі біти не використовуються. Усі вищевказані методи масштабування збігаються з даним обмеженням. Під час масштабування даних джерельного зображення, рекомендується, що мало-значущі біти заповнюються однаково для усіх семплів; тобто, однакове джерельне значення  повинно генерувати однакове значення семплу при будь-якій позиції пікселя. Це покращуж компресію, зменшуючи кількість різних значень семплів. Це не являється головною вимогою, і деякі декодери можуть обрати інший шлях. Наприклад, кодер може замість цього чередувати низькорівневі біти, покращуючи якість відображеного зображення за рахунок збільшення розміру. У деяких програмах оригінальні джерельні дані можуть мати проміжок, який не являється степендю двійки. Рівняння лінійного масштабування все одно працює у даному випадку, на відміну від методу зміщення. Рекомендується, що послідовність sBIT не записується для таких зображень, оскільки sBIT пропонує, що проміжок оригінальних даних вміщується у проміжок 0..2S-1.

12.6 Пропоновані палітри.

Пропоновані палітри можуть міститись у якості послідовностей sPLT у будь-якому потоці даних PNG, або у якості послідовності PLTE у потоках даних PNG з дійсним кольором. У будь-якому випадку, пропоновані палітри не являються головними частинами даних зображення, але можуть бути використаними для представлення зображення на пристроях, які використовують індекси кольорів. Пропоновані палітри не несуть цікавої інформації для переглядачів, які працюють на апаратному забезпеченні з дійсним кольором. Коли використовується послідовність sPLT для забезпечення пропонованої палітри, рекомендується, що кодер використовує поля частот для визначення відносної важливості записів палітри, замість того, щоб залишити їх встановленими у 0 (тобто невизначеними). Значення частот найбільш легко обчислюються у якості обрахунку "найближчого сусіда", тобто, приблизне використання кожного запису палітри RGBA якщо не застосовується розмивання. (Дані методи обрахуку часто вільнодоступні у наслідок розробки пропонованої палітри.) Через те що пропоновані палітри включають інформацію прозорості, вона повинна бути обчисленою для не складеного зображення. Навіть для індекс-колірних зображень, sPLT може використовуватися для визначення альтернативних зменшених палітр для переглядачів, які не в спромозі відобразити усі кольори, які присутні у послідовності PLTE. Якщо у зображенні типу кольору 6 присутня послідовність PLTE без послідовності bKGD, обставини, за якими створювалася палітра являються невизначеними. Старіший метод для включення пропонованих палітр у потоках даних PNG з дійсним кольором, використовує послідовність PLTE. Якщо він використовується, гістограма (частоти) повинні з'являтися у окремій послідовності hIST. Послідовність PLTE не включає інформацію прозорості. Отож для зображень з типом кольору 6 (дійсний колір з прозорістю), рекомендується, щоб була присутня послідовність bKGD і палітра з гістограмою обчислюються з відношенням до зображення, так ніби він з'явиться після компонування з вказаним кольором заднього фону. Дане визначення необхідне для запевнення, що корисні записи палітри генеруються для пікселів, які мають дробові значення прозорості. Результуюча палітра напевно буде корисною тільки для переглядачів, які представляють зображення з однаковим кольором заднього фону. Рекомендується, що редактори PNG видаляють або переобчислюють палітру, якщо вони змінюють або видаляють послідовність bKGD у зображенні з типом кольору 6. Для зображень з типом кольору 2 (дійсний колір), рекомендується, що послідовності PLTE i hIST обчислюються з оглядом тільки на дані RGB, ігноруючи будь-які специфікації прозорого кольору. Якщо потік даних використовує прозорість (має послідовність tRNS), переглядачі можуть легко адаптувати результуючі палітри для використання з їхнім обраним кольором заднього фону (перегляньте 13.17: Використання гістограми і пропонованих палітр). Для забезпечення пропонованих палітр, послідовність sPLT являється більш гнучкою ніж послідовність PLTE у даних пунктах: а. За допомогою sPLT можна вказувати множину пропонованих палітр. Декодер PNG може обрати відповідну палітру засновану на назві або кількості записів. б. У потоці даних PNG з типом кольору 6 (дійсний колір з каналом прозорості), послідовність PLTE представляє палітру скомпоновану з кольором bKGD, отож вона корисна тільки для відображення з цим кольором заднього фону. Послідовність sPLT забезпечує нескомпоновану палітру, яка корисна для відображення з кольором заднього фону, обраним декодером PNG. в. Оскільки послідовність sPLT являється підпорядкованою послідовністю, редактор PNG може додати або модифікувати пропоновані палітри без потреби відкидати невідомі послідовніості, які небезпечні для копіювання. г. Оскільки послідовність sPLT дозволяється у потоках даних PNG для типів кольору 0, 3 і 4 (градації сірого і індекс-колірні), послідовності PLTE не можеть використовуватися для забезпечення зменшених пілітр у даних випадках. ґ. У послідовності sPLT можуть бути присутніми більш ніж 256 записів. Декодер PNG, який використовує послідовність sPLT, також може вирішити записувати пропоновані палітри, представлені за допомогою PLTE і hIST, для сумісності з декодерами, які не розпізнають послідовності sPLT.

12.7 Перекривання.

Даний Міжнародний Стандарт визначає два методи перекривання, один з яких визначає зображення без перекривання. Перекривання забезпечує зручний базис з якого декодери можуть прогресивно відображати зображення, як описано у 13.8: Перекривання і прогресивне відображення.

12.8 Обрання фільтру.

Для зображень типу кольору 3 (індекс-колірні), тип фільтру 0 (жоден) зазвичай являється найбільш ефективним. Колірні зображення з 256 або менше кольорами повинні майже завжди зберігатися у форматі індекс-колірного зображення; формат дійсного кольору ймовірно буде набагато більшим. Тип фільтру 0 також рекомендується для зображення з глибиною бітів меншою за 8. Для зображень градацій сірого з невеликою глибиною бітів, у рідких випадках, кращу компресію можна отримати з розширенням зображення до 8-бітного представлення, після якого застосовується фільтрування. Для зображень з дійсним кольором і градацій сірого, будь-який з п'яти фільтрів може виявитись ефективним. Якщо кодер використовує фіксований фільтр, фільтр Паета (Paeth) найімовірніше буде найкращим. Для найкращої компресії зображень з дійсним кольором або градацій сірого, пропонується підхід з адаптивним фільтруванням, у якому фільтр обирається відповідно до кожного сканрядка. Наступна евристика виконується у якості ранніх тестів: обчислити вихідний сканрядок, використовуючи усі п'ять фільтрів, і обрати фільтр, який надає найменшу суму абсолютних вихідних значень. (Вважайте вихідні байти у якості знакових різниць для даних тестів). Даний метод зазвичай працює краще ніж обирання одного фіксованого фільтру. Однак, ймовірно, що краща евристика отримається по мірі отримання досвіду роботи з PNG. Фільтрування у відповідності до цих рекомендацій являється ефективним у комбінації з двома методами перекривання, визначених у даному Міжнародному Стандарті.

12.9 Стиснення

Кодер може розділити стиснений потік даних у послідовності IDAT, як забажає. (Дозволяється множина послідовностей IDAT, отож кодери можуть працювати з фіксованою кількістю пам'яті; зазвичай розмір послідовності буде відповідати розміру буферу кодера). Потік даних PNG, у якому кожна послідовність IDAT містить тільки один байт даних, являється валідним, однак з неймовірним марнуванням простору. (Послідовності IDAT з нульовою довжиною являються навіть ще більш марнотратними, хоча також валідними).

12.10 Обробка текстових послідовностей.

Не пусте ключове слово повинно міститися з кожною текстовою послідовністю. Загальне слово "Коментар" ("Comment") може використовуватися, якщо немає кращого опису тексту. Якщо використовується ключове слово надане користувачем, кодери повинні перевірити, чи воно відповідає правилам для ключових слів. Для послідовностей tEXt i zTXt, очікується, що текстові рядки PNG використовуватимуть набір символів Latin1. Кодери повинні запобігати збереженню символів, які не визначені у Latin-1, і також повинні забезпечувати перетворення кодів символів, якщо набір символів локальної системи не являється Latin-1. Послідовність iTXt забезпечує підтримку для міжнародних текстів, дозволяючи використання кодування символів USC у UTF-8. Кодери повинні запобігати створення рядків довших за 79 символів, для забезпечення легкого читання. Рекомендується, що текстові об'єкти менші за 1024 байти у розмірі повинні виводитись використовуючи не стиснені послідовності тексту. Рекомендується, що ключові слова базового заголовку і авторства виводились використовуючи нестиснені текстові послідовності. Вміщуючи великі текстові послідовності після даних зображення (після послідовностей IDAT) у деяких ситуаціях може пришвидшити відображення зображення, так як декодер буде декодувати дані зображення першими. Рекомендується, що малі послідовності тексту, на подобі заголовку зображення, з'являтимуться перед послідовностями IDAT.

12.11 Створення послідовностей

12.11.1 Використання приватних послідовностей

Тип послідовності класифікується у якості публічного або приватного в залежності від 5 біту другого байту (біту приватності) і класифікується у якості критичного або підпорядкованого в залежності від 5 біту першого байту (біт підпорядкованості). Перегляньте 5.4: Правила іменування послідовностей. Програми можуть використовувати приватні послідовності PNG для утримання інформації, яка не повинна розпізнаватися іншими зображеннями. Таким послідовностям повинно надаватись приватні типи послідовностей, для запевнення, що вони не зможуть конфліктувати з будь-яким майбутнім визначенням послідовності. Однак, не існує гарантії, що деякі програми не будуть використовувати такий ж тип приватної послідовності. Якщо використовується приватна послідовність, розсудливо зберігати додаткову інформацію для розпізнавання на початку даних послідовності. Підпорядковані типи послідовностей, не критичні типи послідовностей, повинні використовуватися для усіх приватних послідовностей, які зберігають інформацію, яка не являється абсолютно необхідною для відображення зображення. Створення приватних критичних послідовностей не рекомендується, оскільки потоки даних PNG, які містять такі послідовності не підлягають перенесенню.  Такі послідовності не повинні використовуватися у публічно доступному програмному забезпеченні або потоках даних. Якщо приватні критичні послідовності являються необхідними для програми, рекомендується, що вони з'являтимуться спочатку потоку даних, отож стандартні декодери не потребуватимуть зчитування усього зображення, щоб в кінці виявити, що вони не зможуть обробити потік даних. Якщо інші організації потребують розуміння нових типів послідовностей, вони повинні надсилатися до Реєстраційного Органу (перегляньте 4.9: Розширення і реєстрація). Пропоновані публічні типи послідовностей не повинні використовуватися у публічно доступному програмному забезпеченні або потоках даних поки реєстраційний орган його не утвердив. Якщо підпорядковані послідовності містять текстову інформацію, яка може бути цікавою для користувача, спеціальний тип не повинен визначатись для нього. Замість цього, потрібно використовувати послідовності tEXt і застосовувати відповідне ключове слово. У такому разі інформація буде доступною для інших користувачів. Ключове слово в tEXt повинно бути зрозумілим, оскільки його ціллю являється дати зрозуміти іншим користувачам, що вміщує послідовність. Якщо в загальному корисне, нове ключове слово повинно бути зареєстроване за допомогою Реєстраційного Органу (перегляньте 4.9: Розширення і реєстрація). Однак, дозволено використовувати ключові слова без попередньої реєстрації.

12.11.2 Приватні типи і коди методів

Дана специфікація визначає значення тільки деяких з можливих значень деяких полів. Наприклад, тільки метод компресії 0 і типи фільтрів від 0 до 4 визначаються цим Міжнародним Стандартом. Числа більші ніж 127 не повинні використовуватися при впроваджені експериментальних або приватних визначень значень для будь-яких полів. Числа менші 128 зарезервовані для можливих публічних розширень даної специфікації для майбутньої стандартизації (перегляньте 4.9: Розширення і реєстрація). Використання приватних кодів типів може спричинити нечитабельність потоку даних стандартними декодерами. Такі коди не рекомендуються, за виключенням експериментальних цілей, і повинні не з'являтися в публічно-доступних програмних забезпеченнях або потоках даних.

12.11.3 Підпорядковані послідовності

Усі підпорядковані послідовності являються не обов'язковими, декодери не повинні записувати їх. Однак, кодерам рекомендується записувати стандартні підпорядковані послідовності коли відповідна інформація доступна.

13. Декодери PNG і переглядачі

13.1 Вступ

Даний параграф визначає деякі вимоги і рекомендації для поведінки декодерів PNG і поведінки переглядачів. Переглядач представляє декодоване зображення PNG для користувача. Оскільки поведінки переглядача і декодера являється сильно зв'язаною, декодери і переглядачі трактуються у якості однієї сутності. Єдина абсолютна вимога до декодера PNG полягає в успішному читанні будь-якого потоку даних у відповідності до формату, описаного у попередніх розділах. Однак, найкращі результати зазвичай досягаються за допомогою слідування вказівкам наступних рекомендацій. Декодери PNG повинні підтримувати усі валідні комбінації глибини бітів, типів кольору, методів компресії, методів фільтрації і методів перекривання, які безпосередньо визначені у даному Міжнародному Стандарті. Усі підпорядковані послідовності являються необов'язковими; декодери можуть ігнорувати їх. Однак, декодерам рекомендується інтерпретувати дані послідовності коли вони валідні.

13.2 Обробка помилок

Помилки у потоці даних PNG класифікуються на два загальні класи, помилки передачі і синтаксичні помилки (перегляньте 4.8: Обробка помилок). Приклади помилок передачі являються передачі у режимі "text" або "ascii", у якому байтові коди 13 і/або 10 можуть бути доданими, видаленими, або перетвореними через потік даних; неочікувані завершення, за яких потік даних обрізається; або фізичні помилки на пристрої збереження, у якому один або більше блоків (зазвичай 512 кожен) будуть спотвореними або містити випадкові значення. Деякі приклади синтаксичних помилок являються у хибних значеннях для фільтрів рядка, хибний метод компресії, хибна довжина послідовності, відсутність послідовності PLTE перед першою послідовністю IDAT у індексному зображенні, або присутність багатьох послідовностей gAMA. Декодер PNG повинен обробляти помилки наступним чином: а. Виявляти помилки як можливо раніше, використовуючи байти сигнатури PNG і CRC кожної послідовності. Декодери повинні перевіряти усі вісім байтів сигнатури PNG на коректність. Декодер може мати додаткову впевненість у цілісності потоку даних, якщо наступні вісім байтів розпочинають послідовність IHDR з коректною довжиною. CRC повинна перевірятися перед обробкою даних послідовності. Інколи це є непрактично, наприклад коли потоковий декодер PNG обробляє велику послідовність IDAT. У цьому випадку CRC повинна перевірятися коли досягається кінець послідовності. б. За можливості, відновити дані; в іншому випадку аварійно завершити своє виконання. Помилки, які мають малий або жоден ефект на обробку зображення можуть бути проігнорованими, але помилки, які змінюють критичні дані повинні оброблятися у спосіб відповідний для програми. в. Забезпечувати зрозумілі повідомлення, які описують помилки, включаючи відновлювальні помилки. Три класи послідовностей PNG відносяться до цієї філософії. Для цілей даної класифікації, "невідомі послідовності" являються або такими, які були невідомими для авторів декодера, або такими, які автор забажав трактувати у якості невідомих, тому що обробки за замовчуванням даного типу послідовності буде достатньо для цілей програми. Інші послідовності називаються "відомими послідовностями". Даючи дане визначення, дані класи являються наступними: а. відомі послідовності, які обов'язково включають усі критичні послідовності визначені у даному Міжнародному Стандарті (IHDR, PLTE, IDAT, IEND) б. невідомі критичні послідовності (біт 5 першого байту послідовності являється 0) в. невідомі підлеглі послідовності (біт 5 першого байту послідовності встановлено в 1) Перегляньте 5.4: Правила назв послідовностей для повного опису правил іменування послідовностей. Типи послідовностей PNG позначаються "критичними" або "підлеглими" у відповідності до важливості послідовності по відношенню до отримання зображення, яке можна переглянути (такі як IHDR, PLTE i IDAT) або важливими для розуміння структури потоку даних (на подобі IEND). Це є специфічний тип важливості і не обов'язковий для кожного можливого декодера. Наприклад, програма, ціль якої являється отримання текстових анотацій (наприклад, інформація права власності) не вимагає даних зображення. Інший декодер може вважати послідовності tRNS i gAMA суттєвими для її правильного виконання. Синтаксичні помилки завжди з'являються у відомих послідовностях, оскільки синтаксичні помилки у невідомих послідовностях не можуть бути виявленими. Декодер PNG повинен визначити чи синтаксична помилка являється фатальною (невиправною) або ні, в залежності від вимог і ситуації. Наприклад, більшість декодерів можуть ігнорувати помилкову послідовність IEND; програма витягнення тексту може ігнорувати присутність послідовності IDAT; переглядач зображення не може відновлюватися з пустої послідовності PLTE у індексному зображенні, але може ігнорувати хибну послідовність PLTE у зображенні з дійсним кольором; і програма яка отримує канал прозорості може ігнорувати хибну послідовність gAMA, але може вважати присутність послідовності tRNS у якості фатальної помилки. Аномальні ситуації відмінні від синтаксичних помилок повинні трактуватися наступним чином: а. Отримання невідомої підлеглої послідовності ніколи не являється помилкою. Послідовність може бути проігнорованою. б. Отримання невідомої критичної послідовності являється фатальною умовою для будь-якого декодера, який намагається отримати зображення з потоку даних. Декодер, який ігнорує критичну послідовність не може знати чи зображення, яке він витягнув, було таким, як його закодував кодер. в. Невідповідність сигнатурі PNG, невідповідність CRC, або неочікуване закінчення потоку, вказує на спотворений потік даних, і може вважатися у якості фатальної помилки. Декодер може спробувати розрахувати дещо з потоку даних, але ступінь пошкоджень буде невідомий. Коли з'являються фатальні умови, декодер повинен одразу завершувати своє виконання, сигналізуючи користувачу помилку, і необов'язвово продовжуючи виведення будь-яких даних зображення, які вже доступні для користувача (тобто, елегантно завершити виконання). Програма у цілому не потребує завершення. Під час отримання не фатальних помилок, декодер повинен сигналізувати застереження для користувача, відновлювати помилку, і продовжувати нормальне функціонування. Декодери, які не обчислюють CRC повинні інтерпретувати видимі синтаксичні помилки у якості індикаторів спотворення (перегляньте також 13.3: Перевірка помилок). Помилки у стиснених послідовностях (IDAT, zTXt, iTXt, iCCP) можуть спричинити переповнення буферу. Розробники декомпресорів deflate повинні враховувати цю можливість.

13.3 Перевірка помилок

Філософія обробки помилок описується у 13.2: Обробка помилок. Невідомі типи послідовностей повинні бути обробленими як описано у 5.4: Правила іменування послідовностей. Усі невідомі типи послідовностей не повинні трактуватися як помилки, якщо вони не являються критичними. Тип послідовності може перевірятися на правдоподібність через перевірки усіх чотирьох байтів на присутність у проміжку кодів 65-90 і 97-122 (вказані десяткові значення); зверніть увагу, що це необхідно виконувати тільки для нерозпізнаних типів послідовностей. Якщо загальний розмір потоку даних невідомий (інформація з файлової системи, протоколу HTTP, або-що), також довжина послідовності може бути перевірена для правдоподібності. Якщо не перевіряються CRC, пропущені/додані байти даних або помилкові довжини послідовностей можуть спричинити неправильне інтерпретування наступних байтів даних на подобі заголовку послідовності. Для послідовностей з відомою довжиною, на подобі IHDR, декодери повинні трактувати неочікувану довжину послідовності у якості помилки. Майбутні розширення даної специфікації не будуть додавати нові поля до існуючих послідовностей; натомість, буде додаватися новий тип послідовності для утримання нової інформації. Неочікувані значення у полях відомих послідовностей (наприклад, неочікуваний метод компресії у послідовності IHDR) повинні перевірятися і трактуватися у якості помилок. Однак, рекомендується, що неочікувані значення полів будуть трактуватися у якості фатальних помилок тільки для критичних послідовностей. Неочікувані значення підпорядкованих послідовностей можуть оброблятися за допомогою ігнорування цілої послідовності так ніби він є послідовністю з невідомим типом. (Дана рекомендація припускає, що CRC послідовності було перевірено. Декодерам, які не перевіряють CRC, безпечніше трактувати будь-які неочікувані дані у якості пошкодженого потоку даних.) Стандартні зображення PNG повинні бути стисненими за допомогою методу компресії 0. Метод компресії послідовності IHDR постачається для можливих майбутніх стандартизацій варіантів значень. Декодери повинні перевіряти цей байт і повідомляти помилку, якщо він містить невідомі коди. Перегляньте 10: Стиснення для більших деталей.

13.4 Міркування про безпеку

Потік даних PNG складається з колекції послідовностей з безпосередньо вказаними типами. Послідовності, вміст який визначений у специфікації можуть містить будь-що, включаючи зловмисний код. Але немає відомого ризику, що даний зловмисний код може виконуватися на комп'ютері користувача у результаті декодування зображення PNG. Можливі ризики безпеки, які асоційовані з майбутніми типами послідовностей не можуть вказуватися в даний момент. Питання безпеки будуть розглядатися Органом Реєстрації під час розгляду пропонованих послідовностей для реєстрації публічних послідовностей. Не існує додаткового ризику безпеки, який був би зв'язаний з невідомим або нереалізованими типами послідовностей через те, що дані послідовності будуть проігнорованими, або, що найбільше, будуть скопійованими до іншого потоку даних PNG. Послідовності iTXt, tEXt i zTXt містять ключові слова і дані, які повинні відображатися у якості звичайного тексту. Послідовності iCCP i sPLT містять ключові слова, які призначені для відображення у якості звичайного тексту. Можливо, що, якщо декодер відображає даний текст без фільтрування контролюючих символів, особливо символ ESC (вихід, відміна), деякі системи або термінали можуть реагувати у небажаний і небезпечний спосіб. Рекомендується, що декодери фільтруватимуть контролюючи символи для запобігання даного ризику; перегляньте 13.5.3: Обробка текстових послідовностей. Кожна послідовність розпочинається з поля довжини, яка полегшує запис декодерів, які є невразливими до шахрайських послідовностей, що намагаються переповнити буфери. CRC у кінці кожної послідовності забезпечує жорсткий захист проти випадково пошкоджених даних. Байти сигнатури PNG забезпечують раннє визначення загальних помилок передачі файлів. Декодер, який не перевіряє CRC може являтися суб'єктом спотворення даних. Єдиний можливий наслідок такого пошкодження являється некоректно відображені пікселі зображення. Жахливіші обставини можуть виникнути, якщо CRC послідовності IHDR не перевіряються і поля ширини і висоти являються пошкодженими. Перегляньте 13.3 Перевірка помилок. Погано написаний декодер може являтися суб'єктом переповнення буферу, через те, що послідовності можуть виявитися екстремально великими, аж до 231-1 байтів у довжину. Але належно написані декодери оброблять великі послідовності без ускладнень.

13.5 Створення послідовностей

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

13.6 Розмірність пікселів

Можуть представлятися не квадратні пікселі (перегляньте 11.3.5.3: pHYs Фізичні розмірності пікселів), але переглядачі не повинні обов'язково враховувати їх; переглядач може представити будь-який потік даних PNG так, ніби його пікселі являються квадратними. Де співвідношення сторін дисплею відрізняються від співвідношення сторін фізичних пікселів визначених у потоці даних PNG, переглядачам рекомендується виконати масштабування зображення для правильного відображення. Коли послідовності pHYs має вказівник одиниці 0 (невідома одиниця розмірності), поведінка декодера може залежати від співвідношення двох значень пікселів на одиницю, але не повинні залежати від їхньої величини. Наприклад, послідовності pHYs містять (ppuX, ppuY, unit) = (2, 1, 0) еквівалентно до вмісту (1000, 500, 0); двоє являються однаково валідними показниками, які пікселі зображення являються в два рази більшими по відношенню до їхньої ширини. Один розумний спосіб обробляти різницю між співвідношенням сторін пікселів і дисплеєм для переглядачів зображення полягає у розширенні зображення або горизонтально, або вертикально. але не для обох одночасно. Коефіцієнти масштабування можуть бути отриманими використовуючи наступні обрахунки з дійсним результатом. image_rate = pHYs_ppuY / pHYs_ppuX display_ration = display_ppuY / display_ppuX scale_factor_X = max(1.0, image_ration/display_ratio) scale_factor_Y = max(1.0, display_ratio/image_ration) Через те що інші методи на подобі управління площею зображення також являються розумними, і через можливе ігнорування послідовності pHYs, автори не повинні припускати, що програми перегляду будуть використовувати цей метод масштабування. Так само як у випадку з корекцією співвідношенням сторін пікселів, переглядачі можуть виконувати додаткове масштабування пікселів для вертикальної і горизонтальної сторін. Наприклад, переглядач може забажати зменшене зображення, що є занадто великим, для вміщення у дисплей, або розширити зображення і надіслати його на високо-роздільний принтер, отож вони можуть віддрукуватися у такий ж розмір, у який вони показувались на дисплеї.

13.7 Обробка послідовностей

Якщо практично, декодери PNG повинні мати спосіб відображати користувачу усі послідовності iTXt, tEXt i zTXt, які розміщені у потоці даних. Навіть якщо декодер не розпізнає певне текстове ключове слово, користувач зможе зрозуміти його. Під час обробки послідовностей tEXt i zTXt декодери можуть зустрічати символи які відрізняються від дозволених. Деякі можуть бути безпечно відображеними (на подобі TAB, FF i CR, десяткові 9, 12 і 13 відповідно), але інші, особливо символ ESC (десяткове 27), можуть спричинити загрозу безпеці (через неочікувані дії можуть виконуватися апаратним забезпеченням дисплею або програмного забезпечення). Декодери не повинні намагатися прямо відображати будь-які символи не з Latin-1 (за винятком нових рядків і можливо TAB, FF, CR), які зустрічаються у послідовностях tEXt або zTXt. Замість цього, вони повинні ігноруватися або відображатися у видимій формі на подобі "\nnn". Перегляньте 13.4: Міркування безпеки. Через те що кодерам рекомендується відображати символи переходу на новий рядок (десяткове 10), рекомендується, що декодери не будуть слідувати цій рекомендації; найкраще розпізнавати усі загальні комбінації символів переходу на новий рядок (CR, LF, i CR-LF) і відображати кожен з них у якості одного нового рядка. Символ TAB може розширюватися у відповідну кількість пробілів, необхідних для досягнення відповідного відступу (множника 8). Декодери, які виконуються на системах з системою кодування символів відмінних від Latin-1, повинні виконувати перетворення символів системи Latin-1, щоб символи відображалися коректно. Деякі системи можуть не надавати усі символи визначені у Latin-1. Перетворення недоступних символів для візуального відображення на подобі "\nnn" являється хорошим запасним варіантом. Символи кодів 127-255 повинні відображатися тільки, якщо вони являються видимими символами на системі декодування. Деякі системи можуть інтерпретувати такі коди у якості контрольних символів; задля безпеки, декодери, які виконуються на таких системах не повинні безпосередньо відображати такі символи. Декодери повинні підготовлятися для відображення текстових послідовностей, які містять будь-яке число видимих символів між символами нового рядка, навіть якщо рекомендується, що кодери повинні уникати створення рядків які перевищують 79 символів.

13.8 Декомпресія

Техніка стиснення, яка використовується у даному Міжнародному Стандарті не вимагає повністю стиснений потік даних перед початком декомпресії. У свою чергу, відображення може починатися коли ще не доступний повний розархівований потік даних. Мало ймовірно, що будь-які загальні методи компресії у майбутніх ревізіях даного Міжнародного Стандарту не будуть мати дану властивість. Важливо підкреслити, що межі послідовності IDAT не мають семантичної сигнатури і можуть з'являтися у будь-якій точці стисненого потоку даних. Не існує вимоги на кореляцію між структурою даних зображення (наприклад, межі сканрядків) і межами блоку deflate або межами послідовності IDAT. Повні дані зображення представляються за допомогою одного потоку даних zlib, який зберігається у деякій кількості послідовностей IDAT; декодери, які припускають щось більше ніж це, являються не коректними. Деякі розробники кодерів можуть публікувати потоки даних у яких деякі з цих структур являються неодмінно пов'язаними, але декодери не можуть опиратись на це.

13.9 Фільтрування

Для обернення ефекту фільтрування, декодер може потребувати використання декодованих значень певного пікселя на тому ж рядку, пікселі, які розміщення над поточним пікселем попереднього рядка, і піксель зліва верхнього пікселя. Це спричиняє те, що як мінімум один сканрядок даних зображення повинен зберігатися у пам'яті постійно. Навіть, якщо деякі типи фільтрів не звертаються до попередніх сканрядків, декодер завжди потребуватиме зберігання кожного сканрядка у декодованому вигляді, оскільки наступний сканрядок може використовувати фільтр, який звертається до нього.

13.10 Перекриття і прогресивне відображення

Вимагається, щоб декодери були здатними зчитувати зображення з перекриттям. Якщо оригінальне зображення містить менше ніж п'ять колонок, або менше п'яти рядків, деякі стадії будуть пустими. Кодери і декодери повинні коректно обробляти даний випадок. Зокрема, байти типу фільтру асоціюються тільки з заповненими сканрядками; відсутність байтів типу фільтру присутні у пустих зменшених зображеннях. Під час отримання зображень через повільні канали передачі, переглядачі можуть покращити швидкість сприйняття за допомогою прогресивного відображення частин зображення. Це означає, що кожна менша частина зображення являється отриманою, і відображається приближення до завершеного зображення, яке опирається на отриманих до цих пір даних. Ще один покращуючий сприйняття ефект може отримуватися за допомогою розширення кожного отриманого пікселя для заповнення прямокутної області, яка закриває нижчі і праві позиції пікселів, які зараз передадуться до переглядача. Даний процес може бути описаний у якості наступного коду ISO C [ISO-9899]:
/*
**  змінні, оголошені і ініціалізовані десь у коді:
**      height, width
**  функції або макроси, визначені десь у коді:
**      visit(), min()
*/

int starting_row [7]  = { 0, 0, 4, 0, 2, 0, 1 } ;
int starting_col [7]  = { 0, 4, 0, 2, 0, 1, 0 } ;
int row_increment [7] = { 8, 8, 8, 4, 4, 2, 2 } ;
int col_increment [7] = { 8, 8, 4, 4, 2, 2, 1 } ;
int block_height [7]  = { 8, 8, 4, 4, 2, 2, 1 } ;
int block_width [7]   = { 8, 4, 4, 2, 2, 1, 1 } ;

int pass ;
long row, col ;
   
pass = 0 ;

while (pass < 7)
{
    row = starting_row [pass] ;

    while (row < height)
    {
        col = starting_col [pass] ;

        while (col < width)
        {
            visit (row, col,
                   min (block_height[pass], height - row),
                   min (block_width[pass], width - col)) ;

            col = col + col_increment[pass] ;
        }

        row = row + row_increment [pass] ;
    }

    pass = pass + 1 ;
}
Функція visit (row, column, height, width) отримує наступний переданий піксель і відображає прямокутник вказаної висоти і ширини, верхній лівий кут якого міститься за вказаним рядком і стовпцем, використовуючи колір вказаний даним пікселем. Зверніть увагу, що рядок і стовпець вимірюються від 0,0 у верхньому лівому куті. Якщо переглядач об'єднює отримане зображення з зображенням заднього фону, він може більш зручно малювати отримані позиції пікселів (функція visit() встановлює тільки піксель за вказаним рядком і стовпцем, а не увесь прямокутник). Це спричиняє ефект поступового появлення, поки нові зображення поступово замінюють старі. Перевагою даного підходу являється те, що правила обробки каналу прозорості можуть виконуватися по мірі того, як замінюється кожен піксель. Відмальовування прямокутної області вищенаведеним способом перепише пікселі зображення заднього фону, які можуть знадобитися пізніше, якщо врешті-решт отримані пікселі на цих позиціях виявляться повністю або частково прозорими. Це являється проблемою, якщо тільки зображення заднього фону не зберігається у пам'яті.

13.11 Обробка зображень з дійсним кольором.

Для досягнення цілі PNG, яка полягає в універсальній взаємозамінності, декодери повинні приймати усі типи зображень PNG: індекс-колірні, дійсний колір і градації сірого. Переглядачі, які працюють у індекс-колірному апаратному забезпеченні дисплея потребують спосіб зменшення зображення з дійсним кольором до індекс-колірного зображення для переглядання. Даний процес називається "квантуванням кольору". Простий, швидкий метод для квантування кольору полягає у зменшенні зображення до фіксованої палітри. Палітри з уніфікованим простором кольору ("колірні куби") зазвичай використовуються для мінімізації обчислень. Для зображень подібних на фотографії, тремтіння рекомендується для запобігання некрасивих контурів для елементів, які повинні являтися плавними градієнтами; однак, тремтіння впроваджує ступінь дроблення, який може бути небажаним. Якість рендерингу може бути ґрунтовно покращено, за допомогою використання палітри, яка обрана спеціально для даного зображення, оскільки куби кольору зазвичай мають декілька входжень, які використовуються у будь-якому зображенні. Даний підхід вимагає більше роботи, по-перше, для обирання палітри, і по-друге, у перетворенні індивідуальних пікселів до найближчого доступного кольору. PNG дозволяє кодеру вказувати пропоновані палітри, але не усі кодери будуть йти цим шляхом, і пропоновані палітри можуть виявитись несумісними у будь-якому випадку (вони можуть мати забагато, або замало кольорів). Отже, високо-якісні переглядачі потребуватимуть підпрограми роботи з палітрою. Велика таблиця зазвичай являється найбільш гнучким способом перетворення індивідуальних пікселів у записи палітри з адекватною швидкістю. Доступні деяка кількість реалізацій квантування кольору. Приклад реалізації PNG, libpng (http://www.libpng.org/pub/png/libpng.html) містить код для даних цілей.

13.12 Масштабування глибини семплів

Декодери можуть забажати масштабувати дані PNG до менших глибин семплів (точність даних) для відображення. Наприклад, 16-бітні дані повинні бути зменшеними до глибини у 8 біт для використання на найновішому апаратному забезпеченні відображення. Зменшення 8-бітних даних до 5-бітної глибини також поширене. Найбільш точне масштабування досягається за допомогою лінійного рівняння output = floor((input * MAXOUTSAMPLE / MAXINSAMPLE) + 0.5) де MAXINSAMPLE = (2sampledepth) - 1 MAXOUTSAMPLE = (2desired_sampledepth) - 1 Трохи менш точне перетворення досягається за допомогою простого бітового зсуву вправо на (sampledepth - desired_sampledepth) позицій. Наприклад, для зменшення 16-бітних семплів до 8 бітних, менш значущий байт може бути відкинутим. В багатьох ситуаціях метод зсуву являється достатньо точним для відображення на дисплеях, і він являється набагато швидшим. (Але якщо виконується корекція гамми, масштабування семплів може бути об'єднано з таблицею корекції гамми, як описано у 13.13: Обробка гамми декодером.) Якщо декодер потребує масштабувати семпли (наприклад, якщо буфер кадру має більшу глибину семплів, ніж зображення PNG), він повинен використовувати лінійне масштабування або повторення лівих бітів, як описано у 12.5: Масштабування глибини семплів. Коли присутня послідовність sBIT, дані оригінального зображення можуть бути відновленими за допомогою зсуву вправо до глибини семплів, які вказані у sBIT. Зверніть увагу, що лінійне масштабування не обов'язково відновить оригінальні дані, через те що від кодера не вимагається використовувати лінійне масштабування. Однак, від кодера вимагається використання методу, який зберігає найбільш значущі біти, отож зсув завжди працює. Це єдиний випадок, у якому можна сказати, що зсув являється більш точним, ніж лінійне масштабування. Декодер не змушений звертатися до послідовності sBIT; збережене зображення являється валідним потоком даних PNG з глибиною семплів вказаних у послідовності IHDR; однак, використання sBIT для відновлення оригінальних семплів перед їх масштабуванням для задоволення потреб дисплею часто надає більш точне відображення, ніж за ігнорування sBIT. Під час порівняння значень пікселів з значенням послідовності tRNS для визначення прозорих пікселів, порівняння повинно виконуватися точно. Тому, визначення прозорих пікселів повинно виконуватися перед зменшенням точності семплів.

13.13 Обробка гамми декодером

Перегляньте Додаток В: Гамма і кольоровість для докладної інформації по питанням гамми. Переглядачі, які спроможні на повне управління кольором [ICC] будуть виконувати більш складні обчислення, ніж описані тут. Для коректного відображення зображень програмою, необхідно брати до уваги відношення між семплами і виводом дисплея і функцію передачі системи дисплею. Це може бути зроблено за допомогою наступних обчислень: sample = integer_sample / (2sampledepth - 1.0)
display_output = sample1.0/gamma
display_input = inverse_display_transfer(display_output)
framebuf_sample = floor((display_input * MAX_FRAMEBUF_SAMPLE)+0.5) Де, integer_sample являється значенням семплу з потоку даних, framebuf_sample являється значенням для запису у буфер кадру, і MAX_FRAMEBUF_SAMPLE являється максимальним значенням семпла кадру буфера (255 для 8 біт, 31 для 5 біт, або-що). Перший рядок перетворює цілочисельний семпл у нормалізоване значення дійсного числа (у проміжку від 0.0 до 1.0), другий перетворює на значення пропорційне бажаній інтенсивності виводу, третє враховує функцію передачі дисплею, і четверта перетворює на цілочисельний семпл кадру буферу. Нуль у будь-якому позитивному степені являється нульом. Крок можна вставити між другою і третьою для налаштування display_output для врахування різниці між фактичними умовами перегляду і умовами перегляду оригінального зображення. Однак, це налаштування вимагає врахування маскуючих відблисків, чорне накладання і моделі появляння кольору, жодна з яких не може бути представленою за допомогою степеневих функцій. Такі обчислення не описуються тут. Якщо умови перегляду ігноруються, помилка зазвичай являється невеликою. Функція пeредачі дисплею може зазвичай бути приближеною за допомогою степеневої функції з експонентою display_exponent, у випадку якої другий і третій рядки можуть об'єднюватися у: display_input = sample1.0/(gamma * display_exponent) = sampledecoding_exponent отож необхідно виконати тільки одне степеневе обчислення. Для кольорових зображень, усе обчислення необхідно виконувати роздільно для значень R, G i B. Значення гамми може обиратися прямо з послідовності gAMA. Як альтернатива, програма може забажати надати користувачу можливість налаштовувати відображення зображення за допомогою впливу на значення гамми. Наприклад, користувач може вручну встановлювати параметр user_exponent, значення за умовчанням якої 1.0 і програма може встановлювати:
gamma = gamma_from_file / user_exponent
decoding_exponent = 1.0 / (gamma * display_exponent)
   = user_exponent / (gamma_from_file * display_exponent)
Користувач встановить значення user_exponent у значення більше за 1 для затемнення середніх тонів, або менше за 1 для їх висвітлення. Послідовність gAMA, яка містить нуль, являється безглуздою, але воно може означати помилку. Декодери повинні ігнорувати її і редактори можуть відкинути її і вказати попередження користувачу. Не вимагається виконувати усі математичні обчислення для кожного пікселя. Замість цього, можна обчислити таблицю для кожного можливого значення семплу. Це вимагає тільки 256 обчислень для зображення (8 бітна точність), не одне або три обчислення на піксель. Для індекс-колірних зображень, одноразова корекція палітри являється достатньою, хоча якщо, зображення використовує прозорість і воно відображається над не уніфікованим заднім фоном. Якщо дійсні обчислення не являються можливими, таблиці корекції гамми можуть бути обчисленими, використовуючи цілочисельну арифметику і вбудовано таблицю логарифмів. Приклад коду міститься у [PNG-EXTENSIONS]. Коли отримане зображення має невідому гамму (gAMA, sRGB i iCCP відсутні), обирається ймовірне значення гамми за умовчанням, але дозвольте користувачу обрати нове, якщо результат виявляється занадто темним, або занадто світлим. Значення гамми за умовчанням може залежати на знанні про зображення, наприклад, коли воно надійшло з мережі Інтернет або з локальної системи. Як показує практика, часто складно визначити, яке значення експоненти дисплею повинно використовуватися. У системах з вбудованою корекцією гамми, експонента відображення визначається повністю за допомогою CRT. Експонента відображення у 2.2 повинна використовуватися, окрім випадку коли доступні детальні виміри калібрування для поточного CRT. Велика кількість сучасних буферів кадру мають таблиці пошуку, які використовуються для виконання корекції гамми, і у даних системах значення експоненти відображення повинно бути комбінованою експонентою таблиці пошуку і CRT. У деяких ситуаціях не можливо визначити що вміщує таблиця пошуку з програми перегляду, що змушує запитувати користувача внести експоненту системи відображення. На жаль, різні виробники використовують різні шляхи вказування, що повинно вміщуватись у таблиці пошуку, отож інтерпретація системного значення гамми являється платформенно залежною. Відповідь реальних дисплеїв являється більш складним, і не може бути описаною за допомогою одного значення (експонента відображення). Якщо доступні фактичні виміри виводу світла монітора у якості функції напруги, третій і четвертий рядок вищенаведеного обчислення може бути замінене на дане вимірювання, для знаходження фактичного значення кадру буфера, яке найбільш ближче надає бажану яскравість.

13.14 Обробка кольору декодером

Перегляньте Додаток В: Гамма і кольоровість для виносок по питанням кольору. У багатьох випадках, дані зображення потоку даних PNG будуть трактуватися у якості платформенно залежних значень RGB і відображатися без перетворень (не враховуючи відповідну корекцію гамми). Це спричиняє найшвидше відображення зображень PNG. Кольори ніколи не будуть точно такими ж, якими їх бачив автор оригіналу, особливо для темніших або нейтральних кольорів, окрім випадку коли переглядач використовує такий ж пристрій відображення, який використовував автор зображення. Послідовність cHRM забезпечує інформацію, яка дозволяє точніше співставлення кольору, ніж надана за допомогою однієї корекції гамми. Дані cHRM можуть використовуватися для перетворення даних зображення з RGB до XYZ і їх у сприйнятно лінійні кольори на подобі CIE LAB. Кольори можуть бути розбитими для генерації оптимальної палітри, через те, що геометрична відстань між двома кольорами у CIE LAB сильно залежить від того на скільки дані кольори відрізняються (на відміну, наприклад від просторів RGB або XYZ). Результуюча палітра кольорів, під час перетворення назад у простір кольору RGB, може бути використаною для відображення або запису у послідовність PLTE. Декодери, які являються частинами програм обробки зображень можуть також перетворювати дані зображення у простір CIE LAB для аналізу. У програмах де точність кольору являється критичною, на подобі дизайну товарів, наукове відображення, медицина, архітектура або реклама, декодери PNG можуть перетворювати дані зображення з джерельного RGB для відображення простіру RGB, монітору який використовується для переглядання зображення. Це спричиняє обчислення матриці переходу з джерельного RGB до XYZ і матрицю для переходу з XYZ до відображення RGB, після чого комбінування їх для створення перетворення. Декодер PNG відповідальний за реалізацію перетворення гамми. Декодери, які працюють на платформах, що мають Систему Управління Кольором (CMS) можуть передавати значення даних зображення, gAMA i cHRM до CMS для відображення або подальшої обробки. Декодери PNG, які забезпечують можливості друку кольору можуть використовувати властивості у Level 2 PostScript для вказування даних зображення у каліброваному просторі RGB або платформенно незалежному просторі кольору на подобі XYZ. Це забезпечить кращу точність кольору, ніж просте перетворення RGB у CMYK. Документація по мові PostScript [POSTSCRIPT] надає приклади. Такі декодери відповідальні за реалізацію перетворень гамми між джерельним RGB (вказаним у послідовності cHRM) і цільовим принтером. Інтерпретатор PostScript відповідальний за створення необхідних кольорів. Декодери PNG можуть використовувати дані cHRM для обчислення точного представлення градацій сірого кольорового зображення. Перетворення з RGB у сірий просто являється випадком обчислення компоненту Y (яскравості) системи XYZ, що являється зваженою сумою значень R, G i B. Ваги залежать від типу монітору, тобто значення у послідовності cHRM. Декодери PNG можуть забажати виконувати це для потоків даних PNG з відсутніми послідовностями cHRM. У даному випадку, розумними значеннями за умовчанням будуть CCIR 709 [ITU-R-BT709]. Оригінальні значення NTSC не повинні використовуватися, окрім випадку, коли для зображення PNG знаходився баланс кольору для такого монітору.

13.15 Колір заднього фону

Колір заднього фону наданий за допомогою послідовності bKGD зазвичай використовується для заповнення не використаної площини екрану навколо зображення, так само як будь-який прозорий піксель у зображенні. (Тобто, bKGD являється валідним і корисним, навіть коли зображення не використовує прозорість.) Якщо послідовність bKGD відсутня, переглядач потребуватиме обрати відповідний колір заднього фону. Коли жодна інша інформація не доступна, середній сірий на подобі 153 у 8-бітному sRGB просторі кольору буде розумним вибором. Прозорий чорний або білий текст і темні тіні, які є поширеними, будуть видимими на цьому фоні. Переглядачі, які мають специфічний колір заднього фону на якому необхідно представити зображення (на подобі браузерів) повинні ігнорувати послідовність bKGD, і перезаписувати bKGD їхнім бажаним кольором заднього фону або зображення. Колір заднього фону наданий за допомогою послідовності bKGD не розглядається у якості прозорого, навіть якщо його значення випадково співпало з значенням послідовності tRNS (або, у випадку індекс-колірних зображень, відноситься до запису палітри, яке позначене у якості прозорого за допомогою послідовності tRNS). В іншому випадку програма повинна вставити щось інше "за заднім фоном" для композиції. Колір заднього фону використовується у якості заднього фону або ігнорується; він не являється посереднім шаром між зображенням PNG і іншим заднім фоном. Насправді, дуже часто виявляється, що послідовності bKGD i tRNS вказують один колір, оскільки тоді декодер, який не реалізує обробку прозорості все-одно виведе правильне зображення, хоча-б тоді коли відсутні частково прозорі пікселі.

13.16 Обробка каналу прозорості

Канал прозорості може використовуватись для компонування зображення переднього фону з заднім. Потік даних PNG визначає зображення переднього фону і маску прозорості, але не зображення заднього фону. Від декодерів PNG не вимагається підтримка цього у загальному випадку. Очікується, що більшість буде доступно для підтримки компонування з одним кольором заднього фону. Рівняння для обчислення компонованих значень семплів являється наступним: output = alpha * foreground + (1-alpha) * background де, семпли alpha і ввідний і output очікуються у вигляді дійсного числа з проміжку від 0 до 1. Дане обчислення повинно ви виконуватися разом з семплами інтенсивності (не з семплами гамми). Для кольорових зображень, обчислення виконується окремо для семплів R, G i B. Наступний код ілюструє загальний випадок компонування зображення переднього фону разом з зображенням заднього фону. Вона припускає, що оригінальні дані пікселя доступні для зображення заднього фону і що вивід виконується у буфер кадру для відображення. Можливі і інші варіанти: перегляньте коментарі нижче у коді. Код дозволяє щоб глибина семплів значень гамми зображення переднього і заднього фону були різними і не обов'язково такими, які використовує система відображення. На практиці жодні припущення про рівність не повинні робитися без перевірки. Даний код у мові ISO C [ISO-9899], з номерами рядків доданими для звернення у коментарях розміщених нижче.
   01  int foreground[4];  /* image pixel: R, G, B, A */
   02  int background[3];  /* background pixel: R, G, B */
   03  int fbpix[3];       /* frame buffer pixel */
   04  int fg_maxsample;   /* foreground max sample */
   05  int bg_maxsample;   /* background max sample */
   06  int fb_maxsample;   /* frame buffer max sample */
   07  int ialpha;
   08  float alpha, compalpha;
   09  float gamfg, linfg, gambg, linbg, comppix, gcvideo;
   
       /* Get max sample values in data and frame buffer */
   10  fg_maxsample = (1 << fg_sample_depth) - 1;
   11  bg_maxsample = (1 << bg_sample_depth) - 1;
   12  fb_maxsample = (1 << frame_buffer_sample_depth) - 1;
       /*
        * Get integer version of alpha.
        * Check for opaque and transparent special cases;
        * no compositing needed if so.
        *
        * We show the whole gamma decode/correct process in
        * floating point, but it would more likely be done
        * with lookup tables.
        */
   13  ialpha = foreground[3];
   
   14  if (ialpha == 0) {
           /*
            * Foreground image is transparent here.
            * If the background image is already in the frame
            * buffer, there is nothing to do.
            */
   15      ;
   16  } else if (ialpha == fg_maxsample) {
           /*
            * Copy foreground pixel to frame buffer.
            */
   17      for (i = 0; i < 3; i++) {
   18          gamfg = (float) foreground[i] / fg_maxsample;
   19          linfg = pow(gamfg, 1.0 / fg_gamma);
   20          comppix = linfg;
   21          gcvideo = pow(comppix, 1.0 / display_exponent);
   22          fbpix[i] = (int) (gcvideo * fb_maxsample + 0.5);
   23      }
   24  } else {
           /*
            * Compositing is necessary.
            * Get floating-point alpha and its complement.
            * Note: alpha is always linear; gamma does not
            * affect it.
            */
   25      alpha = (float) ialpha / fg_maxsample;
   26      compalpha = 1.0 - alpha;
   
   27      for (i = 0; i < 3; i++) {
               /*
                * Convert foreground and background to floating
                * point, then undo gamma encoding.
                */
   28          gamfg = (float) foreground[i] / fg_maxsample;
   29          linfg = pow(gamfg, 1.0 / fg_gamma);
   30          gambg = (float) background[i] / bg_maxsample;
   31          linbg = pow(gambg, 1.0 / bg_gamma);
               /* 
                * Composite.
                */
   32          comppix = linfg * alpha + linbg * compalpha;
               /*
                * Gamma correct for display.
                * Convert to integer frame buffer pixel.
                */
   33          gcvideo = pow(comppix, 1.0 / display_exponent);
   34          fbpix[i] = (int) (gcvideo * fb_maxsample + 0.5);
   35      }
   36  }
Варіації: а. Якщо вивід виконується у інший потік даних PNG замість буфера кадру, рядки 21, 22, 33 і 34 повинні замінятися на наступні рядки:
/*
* Gamma encode for storage in output datastream.
* Convert to integer sample value.
*/
gamout = pow(comppix, outfile_gamma);
outpix[i] = (int) (gamout * out_maxsample + 0.5);
Також необхідно обробляти пікселі заднього фону коли прозорість рівна нулю, ніж просто пропускати їх. Тобто, рядок 15 потребуватиме заміни на копії рядків 17-23, але обробка заднього фону замість значень пікселів переднього фону. б. Якщо глибина семплів вихідного файлу, файлу переднього фону і файлу з заднім фоном являються однаковими, і три значення гамми також збігаються, тоді не композитний код у рядках 14-23 зменшується до простого копіювання значень пікселів з вхідного файлу до вихідного файлу, якщо прозорість відсутня, або копіювання значень пікселів з заднього фону до вихідного файлу, якщо прозорість містить значення нуля. Оскільки прозорість зазвичай являється нульом або одиницею для більшої частини зображення, це надає відчутну економію. Не потребується жодне обчислення гамми для більшості пікселів. в. Коли однакові глибини і значення гамми співпадають, можна пропустити декодування і кодування гамми (рядки 28-31, 33-34) і просто виконати рядок 32 використовуючи значення семплів для кодованого значення гамми. Хоча це впроваджує ефект спотворення на якість зображення, збереження часу являються малими, якщо значення прозорості нуля і одиниці трактуються у якості спеціальних випадків, як вказано тут у рекомендаціях. г. Якщо оригінальні значення пікселів зображення заднього фону не доступні, тільки оброблені пікселі буферу кадру залишені відображенням заднього зображення, тоді рядки 30 і 31 потрібні для отримання інтенсивності з значення пікселя буферу кадру, використовуючи код на подобі даного:
   /*
    * Convert frame buffer value into intensity sample.
    */
   gcvideo = (float) fbpix[i] / fb_maxsample;
   linbg = pow(gcvideo, display_exponent);
Однак, можна отримати деяку похибку округлення, отож краще мати доступними оригінальні пікселі заднього фону, якщо це можливо. ґ. Зверніть увагу, що рядки 18-22 виконують такі ж обчислення гамми, які виконуються при відсутності каналу компоненту прозорості. Якщо випадок з відсутністю прозорості обробляється за допомогою таблиці пошуку, ця сама таблиця може використовуватися тут. Рядки 28-31 і 33-34 можуть також реалізованими за допомогою (іншої) таблиці. д. Цілочисельна арифметика може використовуватися замість дійсних чисел, з додатковою увагою для забезпечення достатньої точності. ПРИМІТКА. У дійсних числах, не потрібна перевірка на переповнення, через те що вхідні значення семплів гарантовано будуть у проміжку між 0 та 1, і компонування завжди дає результат, який містить між вхідними значеннями (включно). З цілочисельною арифметикою, повинен виконуватися деякий аналіз помилки округлення задля уникнення переповнення. Під час відображення зображення PNG з повним каналом прозорості, важливо мати можливість компонувати зображення з деяким заднім фоном, навіть якщо він є тільки чорним. Ігнорування каналу прозорості спричинить зображення PNG, які мають неправильний вигляд. (Звичайно, якщо канал прозорості являється відокремленою маскою прозорості, тоді ігнорування каналу прозорості являється корисною опцією: вона дозволяє прикритим частинам зображення бути відновленими.) Навіть якщо декодер містить тільки дану можливість прозорості, він повинен мати справу з повним каналом прозорості, трактуючи усі не нульові значення прозорості у якості непрозорих або з змішуванням. Ні один підхід не дасть хороших результатів для зображень перетворених з форматів з прозорістю, але вони являються більш бажаними по відношенню до бездії. Змішування повної прозорості до бінарної дуже подібне до змішування градацій сірого до чорно-білого зображення, однак повністю прозорі і непрозорі пікселі повинні залишитись без змін цим механізмом.

13.17 Використання гістограми і пропонованих палітр

Для переглядачів, які працюють на індекс-колірному апаратному забезпеченні і намагаються відобразити зображення з дійсним кольором, або індекс-колірне зображення, палітра якої являється занадто великою для буфера кадру, кодер може постачати одну або декілька пропонованих палітр у послідовностях sPLT. Якщо одна з цих палітр виявилася належною, в залежності від розміру і можливо назви, декодер PNG може використовувати дану палітру. Пропоновані палітри з глибиною семплів відмінною від потреби декодера може бути перетвореною, використовуючи масштабування глибини семплів (перегляньте 13.12: Масштабування глибини семплів). Коли задній фон являється суцільним кольором, переглядач повинен скомпонувати зображенні і пропоновану палітру відносно даного кольору, коли квантування результуючого зображення до результуючої палітри RGB. Коли зображення використовує прозорість і задній фон не являється суцільним кольором, жодна з пропонованих палітр ймовірно не являється належною. Для зображень з дійсним кольором, пропонована палітра може також постачатися у послідовності PLTE. Якщо зображення має послідовність tRNS і задній фон являється суцільним кольором, переглядач потребуватиме адаптування пропонованої палітри для використання з цим бажаним кольором заднього фону. Щоб зробити це, записи палітри найближчі до кольору tRNS повинні замінюватися з бажаним кольором заднього фону; або, як альтернатива, записи палітри для кольору заднього фону можуть додаватися, якщо переглядач може обробити більше кольорів ніж присутні у записах PLTE. Для зображень з типом кольору 6 (дійсний колір з прозорістю), будь-яка послідовність PLTE повинна бути розробленою для відображення зображення з уніфікованим заднім фоном кольору вказаному у послідовності bKGD. Переглядачі повинні зазвичай ігнорувати палітру, якщо вони бажають використовувати інший задній фон, або якщо послідовність bKGD відсутня. Переглядачі можуть використовувати пропоновані палітри для відображення з іншим заднім фоном, ніж з вказаним, але результат може виявитись не дуже хорошим. Якщо переглядачі представляють прозорі зображення з дійсним кольором з заднім фоном, який являється набагато складнішим ніж уніфікований колір, мало ймовірно що пропонована палітра буде оптимальною для компонованого зображення. У даному випадку найкраще виконувати крок компонування дійсного кольору на зображенні PNG з дійсним кольором і зображенням заднього фону, після чого квантувати вихідне зображення. У потоках даних PNG, з присутніми послідовностями PLTE i sPLT, декодер PNG може обрати з-поміж пропонованих ними палітр, беручи до уваги різну семантику прозорості, що описана вище. Частоти у послідовності sPLT i hIST корисні, коли переглядач не може відобразити вказану кількість кольорів, скільки використовується у палітрі потоку даних PNG. Якщо переглядач має недобір з-поміж кількох кольорів, зазвичай адекватно скинути найменш-використовувані кольори з палітри. Для зменшення кількості кольорів, найкраще обрати повністю нові репрезентативні кольори, ніж намагатися використовувати підмножину існуючої палітри. Це спричиняє створення нового кроку квантування кольору; однак, існуюча палітра і гістограма можуть використовуватися у якості ввідних даних, це зменшує сканування даних зображення у послідовностях IDAT. Якщо не присутні пропоновані палітри, декодер може розробити власні, за рахунок додаткового проходу через дані зображення у послідовностях IDAT. Як альтернатива, палітра за умовчанням (ймовірно куб кольорів) може бути використаною. Перегляньте також 12.6: Пропоновані палітри.

14 Редактори і розширення

14.1 Додаткові типи послідовностей

Положення даного Міжнародного Стандарту можуть бути розширеними за допомогою додаткових типів послідовностей, які можуть бути приватними або публічними. Програми можуть використовувати приватні послідовності для утримання даних, які не цікаві для інших програм користувачів. Декодери повинні підготовоюватися для зустрічі з невідомим публічним або приватним типом послідовності. Правила назв послідовностей (перегляньте 5.4: Правила іменування послідовностей) включають критичні/підпорядковані, публічні/приватні і безпечні/небезпечні для копіювання послідовності, які можна розрізнити. Додаткові публічні послідовності PNG визначаються у документі Register of PNG Public Chuncks and Keywords [PNG-REGISTER]. Послідовності описані там очікуються на менш широку підтримку ніж визначені у даному Міжнародному Стандарті. Однак, авторам програм рекомендується використовувати дані типи послідовностей за відповідності потребам їхніх програм. Додаткові типи послідовностей можуть бути запропонованими до включення у цей список через звернення до Органу Реєстрації PNG (перегляньте 4.9: Розширення і реєстрація). Нові публічні послідовності будуть зареєстрованими в тому випадку, якщо вони корисні для інших і не порушують філософію дизайну PNG. Реєстрація послідовностей не являється автоматичною, однак Реєстраційний Орган буде прямолінійним, коли нова послідовність потенційно необхідна для широкого кругу програм. Створення нової критичної послідовності не рекомендується за винятком гострої необхідності.

14.2 Поведінка редакторів PNG

"Редактор PNG" визначається у якості програми, яка читає потік даних PNG, виконує модифікації і записує новий потік даних PNG, зберігаючи так багато допоміжної інформації, як це можливо. Два приклади редакторів PNG являються програми, які додають або модифікують текстові послідовності, і програми, які додають пропоновані палітри до потоків даних PNG з дійсним кольором. Звичайні редактори зображень не являються редакторами PNG, через те що вони зазвичай відкидають усю нерозпізнану інформацію під час зчитування зображення. Щоб дозволити додавання нових типів до PNG, необхідно встановити правила розміщення для усіх типів послідовностей. В іншому випадку, редактори PNG не будуть знати що робити коли вони зустріли невідомий тип послідовності. НАПРИКЛАД. Розглянемо гіпотетичну нову підлеглу послідовність, що являється безпечною для копіювання і вимагається розміщуватися після PLTE, якщо PLTE присутній. Якщо програма намагається додати послідовність PLTE і не розпізнає нову послідовність, вона може вставити послідовність PLTE не в цьому місці, наприклад після нової послідовності. Такі проблеми можуть запобігатися, вимагаючи у редакторів PNG відкидати усі невідомі послідовності, але це являється дуже непривабливим рішенням. Замість цього, PNG вимагає, що підлеглі послідовності не мають обмеження на розміщення на подобі даного. Для запобігання цього типу проблем з зберіганням розширення у майбутньому, обмеження накладаються на поведінку редакторів PNG і дозволені вимоги на розташування для послідовностей. Біт безпечності копіювання визначає правильну обробку нерозпізнаних послідовностей у потоках даних, які були модифікованими. а. Якщо біт безпечного копіювання встановлено у значення 1, послідовність може бути скопійованою у модифікований потік даних PNG коли редактор PNG розпізнає тип послідовності, і незважаючи на ступінь зміни потоку даних. б. Якщо біт безпечності копіювання встановлений у значення 0, це показує, що послідовність залежить від даних зображення. Якщо програма зробила будь-які зміни до критичних послідовностей, включаючи додавання, модифікацію, видалення або переміщення критичних послідовностей, тоді нерозпізнані небезпечні послідовності не повинні копіюватися до вихідного потоку даних PNG. (Звичайно, якщо програма не розпізнає послідовність, вона може обрати вивести відповідно модифіковану версію послідовності.) в. Редактору PNG завжди дозволено копіювати усі нерозпізнані підлеглі послідовності, якщо він тільки додав, видалив, модифікував або перемістив підлеглі послідовності. Це означає, що не дозволено підлеглим послідовностям залежати від інших підлеглих послідовностей. г. Редактори PNG повинні завершити виконання при зустрічі з нерозпізнаною критичною послідовністю через те, що не існує впевненості, що валідний потік даних буде отримано від модифікованого потоку даних, який містить таку послідовність. (Просте відкидання послідовності не є достатньо хорошою ідеєю через те, що можуть виникнути невідомі наслідки для інтерпретації інших послідовностей.) Механізм безпеки/небезпеки призначений для використання з підлеглими послідовностями. Біт безпечності копіювання завжди буде мати значення 0 для критичних послідовностей. Правила, які управляють розміщенням послідовностей є наступними: а. Під час копіювання невідомої небезпечної для копіювання підлеглої послідовності, редактор PNG не повинен переміщувати послідовність відносно до будь-якої критичної послідовності. Він може вільно переміщати послідовність відносно до інших підлеглих послідовностей, які з'являються між однаковими парами критичних послідовностей. (Це є добре визначено оскільки редактор не повинен додавати, видаляти, модифікувати або переміщати критичні послідовності якщо він зберігає невідомі небезпечні для копіювання послідовності.) б. Під час копіювання невідомої безпечної для копіювання підлеглої послідовності, редактор PNG не повинен переміщувати послідовність з-перед IDAT або після IDAT і навпаки. (Це добре відомо, оскільки IDAT завжди присутній.) Будь-яке інше переміщення дозволене. в. Під час копіювання відомого типу послідовності, редактор повинен дотримуватися тільки специфічних правил розміщення послідовностей, які існують для даного типу послідовності. Однак, замість цього, він завжди може обрати застосування вищенаведених загальновідомих правил. Дані правила виражені у термінах копіювання послідовностей з ввідного потоку даних до вихідного потоку даних, але вони можуть бути застосованими у очевидній манері, якщо потік даних PNG модифікується на місці. Перегляньте також 5.4: Правила іменування послідовностей. Редактори PNG, які не змінюють даних зображення не повинні змінювати послідовність tIME. Ключове слово Часу Створення (Creation Time) у послідовностях tEXt, zTXt i iTXt можуть використовуватися для вказаного користувачем часу.

14.3 Розміщення послідовностей

14.3.1 Розміщення критичних послідовностей

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

14.3.2 Розміщення підлеглих послідовностей

Найсуворіші правила розміщення для підлеглих послідовностях наступні: а. Небезпечні послідовності для копіювання можуть мати вимоги розміщення по відношенню до критичних послідовностей. б. Безпечні для копіювання послідовності можуть мати вимоги для розміщення відносно послідовності IDAT. Фактичні правила розміщення для будь-яких підлеглих послідовностей можуть бути слабшими. Перегляньте, наприклад, правила розміщення для стандартних підлеглих типів послідовностей у 5.6: Розміщення послідовностей. Декодери не повинні припускати більше про розміщення будь-якої підлеглої послідовності, ніж це вказано у правилах розміщення послідовності. Зокрема, неправильно припускати, що певний підлеглий тип послідовності з'являється у певній позиції відносно іншої підлеглої послідовності. НАПРИКЛАД. Небезпечно припускати, що певна приватна підлегла послідовність з'явиться одразу перед IEND. Навіть якщо він завжди записується у цій позиції певною програмою, редактор PNG може вставити декілька інших підлеглих послідовностей після неї. Але безпечно припускати, що послідовність буде розміщуватись десь між IDAT і IEND.

15 Відповідність

15.1.1 Цілі

Даний параграф відноситься до відповідності потоків даних PNG, PNG кодерів, PNG декодерів і редакторів PNG. Головна ціль специфікації у даному параграфі: а. сприяти сумісність запобігаючи довільні підмножини правок, або розширень для даного Міжнародного Стандарту. б. сприяти уніфікованість у розробці тестів сумісності; в. сприяти однакові результати між кодерами PNG, декодерами і редакторами; г. сприяти автоматичні генерації тестів.

15.1.2 Межі

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

15.2 Умови відповідності

15.2.1 Відповідність потоків даних PNG

Потік даних PNG відповідає цьому Міжнародному Стандарту, якщо виконуються наступні вимоги. а. Потік даних PNG містить сигнатуру PNG у якості найпершого вмісту (перегляньте 5.2: Сигнатура файлу PNG). б. З використанням типів послідовностей, які визначені у цьому Міжнародному Стандарті:
  • потік даних PNG містить у якості своєї першої послідовності послідовність IHDR, який слідує одразу після сигнатури PNG;
  • потік даних PNG містить у якості своєї останньої послідовності послідовність IEND.
в. Жодний вміст або інші послідовності не розміщуються після послідовності IEND. г. Усі присутні послідовності відповідають специфікації відповідного типу послідовності даного Міжнародного Стандарту. Потік даних PNG повинен додержуватися відносин між типами послідовностей визначених у даному Міжнародному Стандарті. ґ. Ланцюжок послідовностей у потоці даних PNG додержується відносин розміщення вказаних у даному Міжнародному Стандарті. д. Усі значення полів у потоці даних PNG додержуються відносин вказаних у даному Міжнародному Стандарті, створюючи структуру вказану у даному Міжнародному Стандарті. е. У потоці даних PNG не повинні з'являтися жодні послідовності, відмінні від вказаних у даному Міжнародному Стандарті, або дані визначені у відповідності до правил створення нових типів послідовностей, як визначено у даному Міжнародному Стандарті. є. Потік даних PNG кодується у відповідності до правил даного Міжнародного Стандарту.

15.2.2 Відповідність кодерів PNG

Кодер PNG відповідає до даного Міжнародного Стандарту, якщо він задовільняє наступні вимоги. а. Усі потоки даних PNG, які генеруються кодером PNG відповідають специфікації потоків PNG. б. Під час кодування ввідних семплів, які мають глибину семплів, яка не може бути прямо відображеною у PNG, кодер масштабує семпли до наступної вищої глибини семплів, яка дозволена в PNG. Дані масштабуються у такий спосіб, що значущі біти відповідають оригінальним даним. в. Числа вищі за значення 127 використовуються при кодуванні експериментальних або приватних визначень значень для будь-яких методів або типів полів.

15.2.3 Відповідність декодерів PNG

Декодер PNG відповідає до даного Міжнародного Стандарту, якщо він задовільняє наступні вимоги. а. Він спроможний зчитувати будь-які потоки даних PNG, які відповідають до даного Міжнародного Стандарту, включаючи публічні і приватні послідовності, типи яких не можуть бути розпізнаними. б. Він підтримує усі стандартизовані критичні послідовності, і усі стандартизовані компресії, фільтри і методи інтерфейсів і типи у будь-якому потоку даних PNG, який відповідає даному Міжнародному Стандарті. в. Невідомі типи послідовностей обробляються, як описано у 5.4 Правила іменування послідовностей. Невідомі типи послідовностей не трактуються як помилки, хоча якщо вони являються критичними послідовностями. г. Неочікувані значення у полях невідомих послідовностей (наприклад, неочікувані методи компресії у послідовності IHDR) повинні трактуватися у якості помилок. ґ. Усі типи зображень PNG (колір-індексні, дійсний колір, градації сірого, дійсний колір з прозорістю, градації сірого з прозорістю) повинні оброблятися. Наприклад, декодери які являються частинами переглядачів, які працюють на індекс-колірному апаратному забезпеченні відображення повинні зменшувати зображення дійсного кольору до індекс-колірного формату для перегляду. д. Під час зустрічі невідомої послідовності у якому біт підпорядкованості встановлений у 0 генерує помилку, якщо декодер намагається витягнути зображення. е. Тип послідовності у якому біт зарезервованості встановлено, повинна трактуватися у якості невідомого типу послідовності. є. Усі валідні комбінації глибини бітів і типу кольору, як визначено у 11.2.2: Заголовок зображення IHDR, повинні підтримуватися. ж. Виводиться помилка, якщо нерозпізнане значення зустрічається у глибині бітів, типів кольору, методу компресії, методі фільтрації, або методу перекривання у послідовності IHDR. з. Під час обробки 16-бітних даних градацій сірого або дійсного кольору у послідовності tRNS, обидва байти значень семплів обчислюються для визначення того, чи піксель являється прозорим. и. Під час обробки зображення стисненого за допомогою методу компресії 0, декодер припускає що усі дані зображення представляються за допомогою одного стисненого потоку даних, який зберігається у деякій множині послідовностей IDAT. і. Не повинні робитися жодні припущення щодо позиціювання будь-яких підлеглих послідовностей, відмінних від вказаних у правилах розміщення послідовностей.

15.2.4 Відповідність редакторів PNG

Редактор PNG відповідає даному Міжнародному Стандарту, якщо він задовільняє наступні умови. а. Він відповідає вимогам для декодерів PNG. б. Він відповідає вимогам для кодерів PNG. в. Він спроможний кодувати усі послідовності, які він декодує. г. Він зберігає відносне розміщення послідовностей, які представлені правилами у 5.6: Розміщення послідовностей. ґ. Він відповідно обробляє біти безпечності копіювання і зберігає невідомі послідовності, коли даний біт дозволяє це. д. Якщо користувач дозволяє операції з втратами, або редактор показує попередження, він зберігає усю інформацію, яка вимагається для реконструкції оригінального зображення точно, за винятком того, що глибина семплів каналу прозорості не потребує збереження, якщо вона містить тільки нулі або максимальні значення. Операції на подобі зміни типу кольору, або перетворення палітри у індекс-колірному потоку даних зображення дозволяються у випадку, якщо новий потік даних безвтратно представить таке ж оригінальне зображення.

Додаток А

(інформативний)

Правила файлів і медіа типи Інтернету (Internet media type)

A.1 Розширення імена файлів

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

А.2 Медіа тип Інтернету

Медіа тип інтернету "image/png" являється Медіа Типом Інтернету для PNG [RFC-2045], [RFC-2048]. Рекомендується, щоб реалізатори також розпізнавали медіа тип "image/x-png".

А.3 Макет файлів Макінтош

У системі Apple Computer Inc. Macintosh, рекомендуються наступні правила. а. Чотирибайтовий код типу файлів для PNG являється "PNGf". (Даний код зареєстрований за допомогою Apple Computer Inc. для файлів PNG). Код створювача буде змінюватися в залежності від програми, яка створює файл. б. Вміст даних відгалуження (fork) являється PNG файлом, який описаний у даному Міжнародному Стандарті. в. Вміст джерельного відгалуження не визначається. Він може бути пустим або може містити особливі для даної програми ресурси. г. Під час передачі файлу з PNG Macintosh до відмінних систем, повинно передаватися тільки відгалуження даних.

Додаток Б

(інформативний)

Інструкція для нових типів послідовностей

Даний міжнародний стандарт дозволяє розширення через додавання нових типів послідовностей і нових методів перекривання, фільтрування і компресії. Такі розширення можуть бути зробленими для стандарту для експериментальних цілей або організаціями для внутрішнього використання. Типи послідовностей, які призначені для загального публічного використання, або вимагаються для специфічних доменів програм, повинен стандартизуватися через реєстрацію (перегляньте 4.9: Розширення і реєстрація). Процес реєстрація визначений у Органа Реєстрації. Правила для іменування послідовностей надані у 5.4: Правила іменування послідовностей. Деякі правила для визначення приватних послідовностей надані нижче. а. Не визначайте нові послідовності, які перевизначають значення існуючих послідовностей, або змінюють інтерпретацію існуючих стандартизованих послідовностей, тобто, не додавайте нову послідовність, яка вказує, що RGB і значення прозорості насправді означають CMYK. б. Мінімізуйте використання приватних послідовностей для досягнення переносимості. в. Запобігайте визначення послідовностей, які залежать від загального вмісту потоку даних. Якщо такі послідовності повинні бути визначеними, зробіть їх критичними. г. Для текстової інформації, яка представляється за допомогою Latin-1 запобігайте визначення нових типів послідовностей. Використовуйте послідовності tEXt або zTXt з відповідним ключовим словом для ідентифікування типу інформації. Для текстової інформації, яка не представляється за допомогою Latin-1, але яка може представлятися за допомогою UTF-8, використовуйте послідовність iTXt з відповідним ключовим словом. ґ. Групуйте взаємно залежну підлеглу інформацію у одну послідовність. Це запобігає потребу у впровадженні правил взаємного розміщення послідовностей. д. Запобігайте визначенню приватних критичних послідовностей.

Додаток В

(інформативний)

Гамма і кольоровість

Гамма являється чисельним параметром, який використовується для опису приближень до деякої нелінійної функції передачі, які зустрічаються у захваті зображення і відтворенні. Гамма являється експонентою у степеневій функції. Наприклад функція: intensity = (voltage + constant)exponent яка використовується для моделювання не лінійного дисплею променя катодної трубки (CRT). Часто припускається, так як у даному Міжнародному Стандарті, що константа являється нульом. Для цілей даного Міжнародного Стандарту, зручно розглядати п'ять місць у загальному конвеєрі зображення у яких не лінійна функція передачі може з'явитися, і які можуть моделюватися за допомогою степеневих законів. Експонента характеристики асоційована з кожним з них і їм надане спеціальне ім'я.
input_exponent експонента сенсора зображення.
encoding_exponent експонента будь-якої функції передачі, яка виконується процесом або пристроєм для запису потоку даних.
decoding_exponent експонента будь-якої функції передачі, яка виконується програмним забезпеченням, яке читає потік даних.
LUT_exponent експонента функції передачі, яка застосовується між буфером кадру і пристроєм відображення (зазвичай це виконується за допомогою таблиці пошуку - Look Up Table).
output_exponent експонента пристрою відображення. Для CRT, зазвичай, дане значення близьке до 2.2
Зручно визначати деякі додаткові сутності, які описують деякі функції передачі композиції, або комбінацій стадій.
display_exponent експонента функції передачі, яка застосовується між буфером кадру і площиною відображення пристрою відображення.
display_exponent = LUT_exponent * output_exponent
gamma експонента функції перетворення інтенсивності виводу дисплея до семплів потоку даних PNG.
gamma = 1.0 / (decoding_exponent * display_exponent)
end_to_end_exponent експонента функції перетворення інтенсивності вводу сенсору зображення до інтенсивності виводу дисплея. Зазвичай це значення міститься у проміжку від 1.0 до 1.5.
PNG послідовність gAMA використовується для запису значення гамми. Дана інформація може використовуватися декодерами разом з додатковою інформацією про середовище відображення для отримання, або приближення, бажаного виводу дисплея. Додаткова інформація про даний суб'єкт може бути знайденою у виносках [GAMMA-TUTORIAL], [GAMMA-FAQ], i [POYNTON] (особливо частина 6). Ґрунтовна інформація про кольоровість і простори кольору може бути знайденою у виносках [COLOUR-TUTORIAL], [COLOUR-FAQ], [HALL], [KASSON], [LILLEY], [STONE] i [TRAVIS].

Додаток Г

(інформативний)

Проста реалізація Циклічного коду надлишковості (Cyclic Redundancy Code)

Наступний приклад коду представляє практично реалізацію CRC (Cyclic Redundancy Check), яка застосовується у послідовностях PNG. (Перегляньте також ISO 3309 [ISO3309] або ITU-T V.42 [ITU-T-V42] для формальних специфікацій.) Приклад коду являється кодом у мові програмування ISO C [ISO-9899]. Підказки у Таблиці D.1 може допомогти користувачам не знайомим з мовою програмування C легше читати код.
Table D.1 — Підказки для читання коду ISO C
& Бітовий оператор "І".
^ Бітовий оператор "Виключне-АБО".
>> Бітовий оператор зміщення вправо. Коли застосовується до беззнакової сутності, як тут, правий зсув вставляє нулі зліва.
! Логічний оператор "НЕ".
++ "n++" інкрементуж змінну n. Всередині циклів "for", він застосовується після тестування охорони циклу.
0xNNN 0x впроваджує шістнадцяткове (база 16) константу. Суфікс L вказує на подвійну потужність типу (хоча б 32 біта)
 /* Table of CRCs of all 8-bit messages. */
   unsigned long crc_table[256];
   
   /* Flag: has the table been computed? Initially false. */
   int crc_table_computed = 0;
   
   /* Make the table for a fast CRC. */
   void make_crc_table(void)
   {
     unsigned long c;
     int n, k;
   
     for (n = 0; n < 256; n++) {
       c = (unsigned long) n;
       for (k = 0; k < 8; k++) {
         if (c & 1)
           c = 0xedb88320L ^ (c >> 1);
         else
           c = c >> 1;
       }
       crc_table[n] = c;
     }
     crc_table_computed = 1;
   }
  
   /* Update a running CRC with the bytes buf[0..len-1]--the CRC
      should be initialized to all 1's, and the transmitted value
      is the 1's complement of the final running CRC (see the
      crc() routine below). */
   
   unsigned long update_crc(unsigned long crc, unsigned char *buf,
                            int len)
   {
     unsigned long c = crc;
     int n;
   
     if (!crc_table_computed)
       make_crc_table();
     for (n = 0; n < len; n++) {
       c = crc_table[(c ^ buf[n]) & 0xff] ^ (c >> 8);
     }
     return c;
   }
   
   /* Return the CRC of the bytes buf[0..len-1]. */
   unsigned long crc(unsigned char *buf, int len)
   {
     return update_crc(0xffffffffL, buf, len) ^ 0xffffffffL;
   }

Додаток Ґ

(інформативний)

Онлайн ресурси

Вступ

Даний додаток надає адреси деяких ресурсів з мережі Інтернет для розробників програмного забезпечення PNG. Через природу мережі Інтернет, даний список являється незавершений і являється суб'єктом майбутніх змін.

Сайти архівів

Даний Міжнародний Стандарт може бути знайдений за адресою http://www.w3.org/TR/2003/REC-PNG-20031110/index.html.

Специфікації профілів ICC

Специфікації профілів ICC доступні за адресою: http://www.color.org/

Web-сайт PNG

Існує сайт Всесвітньої Павутини (WWW) для PNG за адресою http://www.libpng.org/pub/png/. Дана сторінка являється центральним розміщенням для поточної інформації про PNG і інструменти для PNG. Додаткова документація і переносимий код мови C для deflate, inflate і оптимізованої версії алгоритму CRC доступний з web-сайту zlib за адресою http://www.zlib.org/.

Приклади реалізації і тестові зображення

Приклад реалізації на портованому коді мови C, libpng, доступний за адресою http://www.libpng.org/pub/png/libpng.html. Приклад реалізації переглядача і програми кодера libpng доступний за адресою http://www.libpng.org/pub/png/book/sources.html і детально описуються у документі PNG: Definitive Guide [ROELOFS]. Тестові зображення можуть також отримуватися з web-сайту PNG.

Електронна адреса

Запити, які стосуються розробки PNG можуть адресуватися до скриньки png-group@w3.org.

Додаток Д

(інформативний)

Відносини до W3C PNG

Даний Міжнародний стандарт тісно заснований на рекомендаціях W3C Recommendation PNG Specification Version 1.0 [PNG-1.0], який був переглянутий членами W3C, затверджений у якості W3C Recommendation, i опублікований у жовтні 1996 року у відповідності до встановленого процесу W3C. Наступні поправки до специфікації PNG Specification також були впровадженими до даного Міжнародного Стандарту [PNG-1.1], [PNG-1.2]. Повний перегляд даного документу був зроблений ISO/IEC/JTC 1/SC 24 у співпраці з W3C для перетворення даних рекомендацій у міжнародний стандарт ISO/IEC. Головна ціль розробки даного перегляду була у запобіганні змін, які зроблять несумісними існуючі файли, редактори, або переглядачі, що відповідають специфікації W3C Recommendation PNG Specification Version 1.0. Рекомендації W3C PNG Recommendation розроблені за головної підтримки наступних людей.

Редактор (Версія 1.0)

Thomas Boutell, boutell @ boutell.com

Редактор (Версія 1.1 і 1.2)

Glenn Randers-Pehrson, randeg @ alum.rpi.edu

Редактор (Версія 1.0)

Tom Lane, tgl @ sss.pgh.pa.us

Редактор (Версії 1.1 і 1.2)

Adam M. Costello, png-spec.amc @ nicemice.net

Автори (Версії 1.0, 1.1 і 1.2 комбіновано)

Імена авторів представляються у алфавітному порядку.
  • Mark Adler,
  • Thomas Boutell,
  • John Bowler, jbowler @ acm.org
  • Christian Brunschen,
  • Adam M. Costello,
  • Lee Daniel Crocker,
  • Andreas Dilger,
  • Oliver Fromme,
  • Jean-loup Gailly,
  • Chris Herborth,
  • Alex Jakulin,
  • Neal Kettler,
  • Tom Lane,
  • Alexander Lehmann,
  • Chris Lilley,
  • Dave Martindale,
  • Owen Mortensen,
  • Keith S. Pickens,
  • Robert P. Poole,
  • Glenn Randers-Pehrson,
  • Greg Roelofs,
  • Willem van Schaik,
  • Guy Schalnat,
  • Paul Schmidt,
  • Michael Stokes,
  • Tim Wegner,
  • Jeremy Wohl,

Список змін між W3C Recommendation PNG Specification Version 1.0 і даним Міжнародним Стандартом

Зміни редакторів

Документ буф відформатований у відповідності до ISO. а. Був впроваджений параграф концепцій. б. Відповідність для потоків даних, декодерів, кодерів і редакторів визначений у параграфі відповідності.

Технічні зміни

а. Запропоновано нові типи послідовностей у PNG версії 1.1 і 1.2 і були впроваджені (iCCP, iTXt, sRGB, sPLT). У послідовності iTXt, тег мови оновлено з RFC1766 до RFC3066. б. У відповідності до версії 1.1, сфера щастосування обмеження 31-бітної довжини послідовності і розмірів зображення було розширено для усіх чотирибайтових беззнакових цілих. Значення-231 не дозволяється у знакових цілих. в. Було впроваджено перевизначення gAMA у термінах бажаного виводу дисплея, на противагу оригінальному значенню, впровадженому у PNG версії 1.1. г. Використання послідовностей PLTE і hIST у не індекс-колірних зображення було заборонене на користь послідовності sPLT. ґ. Статус деяких рекомендацій для кодерів PNG, декодерів, і редакторів був посилений до вимог. Дані зміни не змінюють відповідність потоків PNG, і не ставлять під загрозу універсальність. д. Глибина семплів каналів не згадана у послідовності sBIT була уточнена.

Бібліографія

[COLOUR-FAQ] Poynton, C., "Colour FAQ". http://www.poynton.com/ColorFAQ.html [COLOUR-TUTORIAL] PNG Group, "Colour tutorial". http://www.libpng.org/pub/png/spec/1.2/PNG-ColorAppendix.html [GAMMA-TUTORIAL] PNG Group, "Gamma tutorial". http://www.libpng.org/pub/png/spec/1.2/PNG-GammaAppendix.html [GAMMA-FAQ] Poynton, C., "Gamma FAQ". http://www.poynton.com/Poynton-color.html [HALL] Hall, Roy, Illumination and Color in Computer Generated Imagery. Springer-Verlag, New York, 1989. ISBN 0-387-96774-5. [ICC] The International Color Consortium. http://www.color.org/ [ISO-3664] ISO 3664:2000, Viewing conditions — Graphic technology and photography. [ITU-R-BT709] International Telecommunications Union, Basic Parameter Values for the HDTV Standard for the Studio and for International Programme Exchange, ITU-R Recommendation BT.709 (formerly CCIR Rec. 709), 1990. [ITU-T-V42] International Telecommunications Union, Error-correcting Procedures for DCEs Using Asynchronous-to-Synchronous Conversion, ITU-T Recommendation V.42, 1994, Rev. 1. [KASSON] Kasson, J., and W. Plouffe, "An Analysis of Selected Computer Interchange Color Spaces", ACM Transactions on Graphics, vol. 11, no. 4 , pp. 373-405, 1992. [LILLEY] Lilley, C., F. Lin, W.T. Hewitt, and T.L.J. Howard, Colour in Computer Graphics. CVCP, Sheffield, 1993. ISBN 1-85889-022-5. [ROELOFS] Roelofs, G., PNG: The Definitive Guide, O'Reilly & Associates Inc, Sebastopol, CA, 1999. ISBN 1-56592-542-4. See also http://www.libpng.org/pub/png/pngbook.html [PAETH] Paeth, A.W., "Image File Compression Made Easy", in Graphics Gems II, James Arvo, editor. Academic Press, San Diego, 1991. ISBN 0-12-064480-0. [PNG-1.0] W3C Recommendation, "PNG (Portable Network Graphics) Specification, Version 1.0", 1996. Available in several formats from http://www.w3.org/TR/REC-png-961001 and from http://www.libpng.org/pub/png/spec/1.0/ [PNG-1.1] PNG Development Group, "PNG (Portable Network Graphics) Specification, Version 1.1", 1999. Available from http://www.libpng.org/pub/png/spec/1.1/ [PNG-1.2] PNG Development Group, "PNG (Portable Network Graphics) Specification, Version 1.2", 1999. Available from http://www.libpng.org/pub/png/spec/1.2/ [PNG-REGISTER] PNG Development Group, "Register of PNG Public Chunks and Keywords". Available in several formats from: http://www.libpng.org/pub/png/spec/register/ [POSTSCRIPT] Adobe Systems Incorporated, PostScript Language Reference Manual, 2nd edition. Addison-Wesley, Reading, 1990. ISBN 0-201-18127-4. [POYNTON] Poynton, Charles A., A Technical Introduction to Digital Video. John Wiley and Sons, Inc., New York, 1996. ISBN 0-471-12253-X. [SMPTE-170M] Society of Motion Picture and Television Engineers, Television — Composite Analog Video Signal — NTSC for Studio Applications, SMPTE-170M, 1994. [STONE] Stone, M.C., W.B. Cowan, and J.C. Beatty, "Color gamut mapping and the printing of digital images", ACM Transactions on Graphics, vol. 7, no. 3, pp. 249-292, 1988. [TIFF-6.0] TIFFTM Revision 6.0, Aldus Corporation, June 1992. [TRAVIS] Travis, David, Effective Color Displays — Theory and Practice. Academic Press, London, 1991. ISBN 0-12-697690-2. [ZL] J. Ziv and A. Lempel, "A Universal Algorithm for Sequential Data Compression", IEEE Transactions on Information Theory, vol. IT-23, no. 3, pp. 337 - 343, 1977. Додаткова документація і переносимий код мови C для deflate, inflate i оптимізованої реалізації алгоритму CRC доступні з web-сайту zlib: http://www.zlib.org/. Оригінал: https://www.w3.org/TR/PNG/