nabbla (nabbla1) wrote,
nabbla
nabbla1

Category:

Вспомогательные фрагменты PNG (окончание)

Опишем кратко, что там еще бывает.

bKGD (background) - самый недооцененный и вследствие этого нереализованный фрагмент. К примеру, формулы TEX часто рендерятся как черный текст на прозрачном фоне, и пока они висят где-нибудь на сайте (т.е фон обеспечен) - все хорошо. Но захочется нам посмотреть их просто в папке, и дальше как повезет. Почти половина вьюверов показывают картинки на белом фоне - тогда нам повезло. Еще столько же - на черном - тогда вместо формулы у нас будет супрематическая картина, растянутая до 4:3 либо 16:9.

С помощью фрагмента bKGD можно задать цвет фона для изображения, которым программа для просмотра может воспользоваться, если никакого другого фона в наличии нет. Как по мне, разработчики малость перемудрили с его структурой - в зависимости от типа цвета bKGD будет состоять либо из одного байта (индекс цвета фона в палитре), либо из двух (в случае Grayscale или GrayscaleAlpha, 1, 2, 4, 8 или 16 бит, ненужные биты слева заполнены нулями), либо из шести (компоненты R,G,B, по 2 байта на каждую, если у нас RGB или RGBAlpha), ну да ладно, могло быть и хуже.

Вот две картинки, в которые я добавил bKGD, в надежде что черный текст отобразится на белом фоне и наоборот:

https://img-fotki.yandex.ru/get/65759/41043419.38/0_12d403_96c38414_orig
https://img-fotki.yandex.ru/get/65759/41043419.38/0_12d404_460d6ae9_orig

Тортик тому, кто найдет хоть одну программу-просмотрщик, которая обе картинки отобразит правильно, первую на белом фоне, вторую на черном, автоматически!

А вообще PNG с заданным фоном встречаются, довольно редко, интересного мало, чаще всего предлагается черный:
PNGRepack_bKGD.png

А самый распространенный фрагмент - tRNS (transparency) - позволяет получать прозрачные и полупрозрачные изображения, не прибегая к полноценному альфа-каналу.

Если в изображении используется палитра, то в tRNS записывается прозрачность цветов этой палитры, причем не обязательно всех, можно только первых, что позволяет немножко сэкономить места - считанные байты, но в маленьких картиночках и то хлеб.

Вот пример очень дурацкого применения PLTE и tRNS:
stupid_trns.png
Хотя в палитре можно задать ровно столько цветов, сколько реально используется, здесь она набита под завязку - 256 цветов, последние из которых - повторяющийся черный. Мало того, во всей палитре был только один прозрачный цвет, его надо было сунуть в самое начало, что дало бы tRNS размером в 1 байт (не считая обязательных 12 байт - размер, название и CRC), здесь же и tRNS имеет максимальный размер в 268 байт.

Если же формат пикселя - RGB или Grayscale, то в tRNS запишется ровно один цвет, который должен будет во всем изображении интерпретироваться как полностью прозрачный. Эдакий "хромакей", хотя в файлах в качестве прозрачного традиционно используется фуксия (255;0;255):

correct_tRNS.png

Впрочем, никакого особенного правила нет, за прозрачный можно взять любой приглянувшийся цвет.

Получается, что в PNG есть три разных способа задания прозрачности - "битовая прозрачность" (так называют последний описанный нами способ, когда один из цветов назначается прозрачным), "палитра с прозрачностью" и - самый тяжеловесный - альфа-канал. Как по мне, это немножко перебор - довольно тяжело обрабатывать прозрачные изображения максимально корректно, нужно либо переходить к альфа-каналу для внутренних операций, и только под конец находить наименее затратный способ представления, либо каждый раз дробить выполнение на 3 разных варианта.

На данный момент PNGRepack не умеет упрощать прозрачные картинки, это не её специальность, в деле сканирования книг прозрачность вроде как и не нужна. Я думал о применении прозрачных PNG в механизме undo, типа спрайтов, показывающих, где именно прошелся инструмент, но пока такой необходимости не возникло, схема предиктора-корректора с сохранением разностного изображения вполне оправдывает себя.

Что еще хуже, при текущей реализации PNGRepack может даже подпортить прозрачные изображения, поменяв формат изображения (заметив, например, что цветов всего 16 и применив палитру вместо RGB), но не трогая заодно и tRNS, чтобы она подстроилась под новый формат. Поставить ей запрет менять формат при наличии tRNS недолго, сделаю на днях.

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

Еще несколько фрагментов, которые уже вряд ли будут применены, ибо устарели морально. Их назначение было помочь просмотрщику отобразить нечто, смутно напоминающее наше изображение, если монитор не может показывать более 16 или 256 цветов одновременно, но тем не менее, которому можно задать палитру.

Первый из них - hIST (histogram), гистограмма, в неё записывается частота, с которой появляется тот или иной цвет в палитре. Идея в том, что программа просмотра сможет выбрать самые часто используемые цвета для своей урезанной палитры, и ей не придется просматривать файл лишний раз.

Второй - sPLT (suggested palette) - предлагаемая палитра. Таких палитр может быть даже несколько на файл, хотя мне до сих пор не встретилось ни одной.

Ну и последний из официальных фрагментов, sBIT (significant bits) - количество значащих бит. Допустим, у нас есть фотоприемная матрица с АЦП на 14 бит, и мы хотим сохранить изображение с нее, и применили для этого PNG. Не бывает PNG на 14 бит, бывает на 16, он нам подойдет, два младших бита заполним нулями (или, еще лучше, скопируем в них два старших, что будет эквивалентно умножению на (2^16-1)/(2^14-1), т.е раскрытия до диапазона 0..FFFFh). Но неплохо бы после этого сохранить информацию, что эти младшие 2 бита не несут никакой полезной информации, так что при первой возможности (переконвертация в какой-то еще формат, какая-то обработка и пр) от них можно избавиться, вот для этого и нужен sBIT. Количество значащих бит можно задать для каждого канал по отдельности - серый, R,G,B и альфа.
Файлы PNG, в которых включен sBIT, попадаются время от времени, хотя пока все, что я встречал, содержали тривиальную информацию - 8 бит на канал, что можно было и не говорить, по умолчанию мы бы так и поняли:
2016-03-24 02-44-08 Скриншот экрана.png

У меня вчера появились файлы с теми самыми 14 битами, и соответствующий sBIT я внёс для порядку, хотя понадобится ли он - не знаю пока.

Следующие chunk'и, ну нет, слово фрагмент к ним плохо подходит, может вообще "куски"? В общем, через некоторое время после выпуска спецификаций на PNG появились так называемые PNG Extensions, которые некоторое время спустя тоже стали официальным стандартом. Единственный из них, который мне встретился - это oFFs, остальные пока не пойманы.

Файла кусок oFFs (offset) должен сохранять некое смещение изображения от левого верхнего угла страницы, а как это применить - личное дело каждого.

sCAL (scale) - в отличие от pHYs, который показывает реальное разрешение бумажной копии, которую мы отсканировали, sCAL показывает размеры того ОБЪЕКТА, что у нас изображен. Скажем, если у нас нарисована карта, то sCAL может дать масштаб, скажем, 10 метров на пиксель, а для картины звездного неба - указать угловой размер. Полезная вещь, в хозяйстве пригодится.

Ну и pCAL (physical calibration) - предполагается сопоставить цвету пикселя значение некоторой величины, распределение которой на плоскости мы и запечатлели. Скажем, тепловизор мог бы записать в pCAL, каким реальным температурам соответствуют цвета на картинке, так что открыв изображение в специальной программе просмотра, мы могли бы вести мышкой по картинке и смотреть в строке состояния или где-то сбоку температуру. Я даже предложил так сделать разработчикам из SeekThermal, они пообещали подумать:)

Правда, в описании pCAL есть косяк - все понятно, если у нас изображение в градациях серого, там мы выбираем тип шкалы (линейная, степенная или логарифмическая, еще и арктангенс есть для самых упоротых), крайние точки шкалы, и все хорошо. Но вот что с RGB делать, непонятно, есть смутное упоминание, что каждый цвет преобразуется независимо, но почему же тогда величина одна, а значения три? Так что все равно придется "недокументированным образом" довести это преобразование до конца, или вовсе отказаться от pCAL, а придумать свой собственный фрагмент.

Есть еще несколько фрагментов, часть из них - чтобы взаимно однозначно можно было преобразовать один gif в последовательность png, которую потом можно будет собрать обратно, есть цифровая подпись, но работу с ними я не реализовывал вовсе, какие-то они скучные.

Такой вот зоопарк. Пожалуй, PNG проще обрабатывать, чем TIFF, вот все возможные вариации TIFF правильно обработать - это вообще задача почти невыполнимая. Мириады способов сжатия, разные варианты ориентации страницы и интерпретации цвета пикселя, все известные цветовые схемы, размещение пикселей по строкам или по тайлам (мозаикой), многостраничные документы, мало не покажется!


В самом скором времени ожидайте альфа-версию PNGRepack, вот только исправлю известные глюки, и выложу. Останется вам найти неизвестные - и все хорошо.
Tags: scancombine, Программки
Subscribe

  • Мышки плакали, кололись,

    но продолжали смотреть Доктора Кто... Что-то не то, всё-таки. Какая-то бессмыссленность происходящего, простые сюжеты. Расизм - это плохо, экология…

  • И ещё о 13-й докторе

    В воскресенье вышла первая серия, посмотрел это дело. Да в общем, нормально, вполне себе "Доктор Кто". Вот она, компаньон моей мечты - ЯЯЯЯЗЬ!…

  • Великая Октябрьская резня бензопилой

    Сегодня прокатился прочистить Абрамцевскую просеку. Как обычно, с приключениями. Выезжал на велосипеде, а вернулся на самокате. Первый раз по этим…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 0 comments