Отображение CMYK jpg файлов в браузерах

[Obl]

Здравствуйте!
В нашей типографии используется система проверки файлов заказчиков, которая позволяет просматривать для утверждения cmyk jpg через web-интерфейс. Обычно это многостраничные издания формата A3+, так что файлов много.
Эти файлы преобразуется в jpg из пдф после обработки пдф файлов заказчиков в рипе. Для корректного отображения браузрами к нему необходимо приделывать icc-профиль, но это сильно увеличивает размер jpg. Без внедренного профиля jpg файл выглядит слишком "ярким", с сильно перенасыщенными первичными цветами и бинарами. Можно ли создать (и как это сделать) уменьшенный cmyk профиль (200-300 кб) на базе iso_coated_v2.icc, который при внедрении в jpg файл давал бы в браузере визуально похожую картинку на cmyk jpg с "нормальным" cmyk профилем?

[mihas]

Да, я могу постороить такой профиль без хоть сколько-то заметных потерь в качестве отображения.

Размер профиля определяется его гранулярностью и наличием тех или иных таблиц.

Обычная гранулярность (или число степов значений полутона от 0 до 100) около 16-17 для таблицы отображения красок по цвету A2B и гранулярностью около 30 для таблицы цветоделения B2A. Такой профиль "весит" чуть более мегабайта, до двух. Никто не мешает построить профиль с гранулярностью например 6 и он будет весить всего 140 килобайт, я только что построил для эксперимента такой со всеми 6 таблицами - 3 таблицы в одном направлении преобразования и 3 в другом. Для плавных гладких стандартных офсетных данных такое снижение гранулярности не приведет к серьезным потерям.

Есть еще более продвинутый вариант: сократить ненужные в данном случае таблицы профиля. Так спокойно выкидываем все три таблицы цветоделения Lab->CMYK, ведь для просмотра они не нужны (так раньше профили сканеров строились без половины зеркальных таблиц: картинка верно отображалась и конвертировалась со сканера, но не могла быть переконвертирована обратно в профиль сканера, поскольку это и не нужно) и из трех таблиц отображения красок по цвету CMYK->Lab делаем три раза ссылку в профиле на одну единственную таблицу Рилейтив (нам не нужны еще отдельные отличающиеся таблицы отображения Сатурейшн и Перцепция, при отображении они все равно не используются, а для особых неколориметрических преобразований из красок CMYK в RGB можно воспользоваться каким-то другим профилем). Так тоже зачастую делают в профилях, все варианты рендеринг интента кроме абсолюта естественно показывают картинку одинаково. Так мы можем, сократив 6 таблиц всего до одной, даже и не жертвовать особо гранулярностью до 6, сделать ее например 12-16 при величине профиля всего в сотню килобайт или меньше.

Так например вот в этом профиле на 1 мегабайт а не на 2 все три необходимые таблицы отображения ссылаются в заголовке реально всего на одну таблицу - Релативную, перцепция и сатурация просто не нужны как отдельные варианты отображения. Это не я придумал, так часто делают в хороших профилях. Плюс указанный профиль содержит факультативно как и профили ECI еще и здоровый таргет для колористов, любящих поковырять внутренности профиля, отсутствие которого (еще минус 89 килобайт) обычный пользователь переживет совершенно безболезненно и даже не заметит. У меня половина популярных профилей цветоделения без факультативного таргета, он не нужен браузеру и фотошопу, а нужен лишь при перестроении профиля в специальном софте.

В заголовке профиля Перцепция 0, Рилейтив 1 и Сатурейшен 2 ссылаются на одну и ту же таблицу, профиль "весит" не два мегабайта, а один.

• 20.2 КБ • 9444 просмотра

У профиля без таблиц B2A будет ограничение - им нельзя будет сделать цветоделение, ну так и хорошо, оно и не нужно в случае просмотра. При попытке сделать цветоделение фотошоп не упадет, а штатно предупредит просто, что с этим профилем сделать цветоделение невозможно.

Если вам охота повозиться самим - здесь вы даже найдете пару утилит на яваскрипте с интефейсом html, немного покопавшись в коде которых можно настроить генерацию и разметку таблиц A2B для профиля с любой гранулярностью. Я позже попробую собрать такой профиль.

Если особо не важно весит профиль 100 килобайт или 200 - сохраняем в нем всего пару зеркальных таблиц, а не только таблицу отображения, остальные 2+2 тега просто переадресуем на них. Словом интересных разных вариантов много, разными путями и их комбинацией можно весьма достойно сделать компактный профиль CMYK без потерь в качестве.

При просмотре CMYK без профиля большинство простеньких просмотровщиков применяют совершенно безобразную математику, которая и близко не лежала с нормальным управлением цветом. Эту математику даже не сложно найти, она примитивная и неправильная. Конечно во всех случаях контроля цвета верный профиль должен быть внедрен в файл, считается, что наиболее адекватным является просмотр пдф со внедренным профилем. Но и растровый формат тоже неплохо, я зачастую растрирую спуски чтобы изучить детально какой-то участок именно в фотошопе. У вас правильная идея внедрить в него легкий правильный профиль icc вашей печати и порекомендовать заказчику те программы просмотра, которые используют нормальный колорменеджмент на базе технологии icc.

Ну и по поводу браузеров замечание: они не умеют правильно показывать CMYK даже с профилем. То есть порекомендовать заказчику просмотр можно в Photoshop, в FastStone, в XnView, но не в браузере.

[Obl]

Михаил, спасибо за развернутый ответ. Буду копать далее.
Интересно, а fancybox, который вы используете на форуме, правильно отображает CMYK растр?

[mihas]

Проверка фансибокса (это яваскрипт, который отображает изображения поверх форума всплывающим окном) не удалась. Дело в том видимо, что ImageMagic сервера почему-то не может обработать CMYK-файл с профилем или без профиля и сделать превьюшку. Веб вообще не дружит с цмиком, так что не удивляюсь, что форум и сервер тоже не дружит. Раньше не пробовал в веб залить цмик кстати. Просто создатели форума подобного не предусмотрели, сам по себе ImageMagic может с разными цветовыми моделями работать, но видимо ему специально надо такие вещи указывать. Я конечно ковыряю понемногу серверные скрипты форума когда нет нужного мне мода, но на предмет цмика пока не ковырял, может быть потом. Фансибокс не относится к серверной части обработки изображения, просто клиентский яваскрипт (у меня похожий сто лет как используется в домашнем семейном архиве фоток, этот яваскрипт фотки поверх веб-страницы очень древний), за обработкой надо лезть в серверную часть php, где вызывается ImageMagic или GD.

Ну а для вашего вопроса - вы можете остановиться на облегченном pdf также с небольшим профилем внутри: акробат такие CMYK файлы правильно показывает, внедренный профиль верно использует, а компрессия jpg в пдф доступна. Типографии не любят на входе пополосные пдф, в каждом из которых 2 мегабайта занимает просто профиль отображения. Но если это будет профиль всего 100 килобайт - вопрос интересный, кто от такого добра откажется и зачем!-) Тема внедрения цветовых профилей в графические файлы обсуждалась еще в 2012 году, и судя по опросу - многие из читателей форума согласны с тем мнением, что типографии и вебдизайну правильный внедренный профиль не повредит, в конце концов - его же можно и игнорировать, если есть такая необходимость.

[mihas]

На скриншоте показано, что заголовки 3+3 таблиц отображения и цветоделения ссылаются на 1+1 таблицу для уменьшения размера. Справа размер таблиц в байтах.

• 22.27 КБ • 9325 просмотров

Повозился, потестировал, остановился на таком варианте.

Встречайте ISO Coated v2 Smaller Embedded AK.icc всего 101 килобайт!

Как и говорил, уменьшил гранулярность, сократил кол-во таблиц с шести всего до двух, остальные четыре ссылаются на эти две: одна в одном направлении преобразования и другая в другом. Совсем уж классный и особенный профиль на 90 килобайт с единственной таблицей просмотра красок AToB и гранулярностью 11 - фотошоп конечно видит и внедряет, а вот иллюстратор все же не признает профиль просмотра без таблицы цветоделения. Так что сделал таблицу BToA чисто номинально с гранулярностью всего 9 (вместо типичных 30) и всего на 10 килобайт (хотя ничего плохого не произойдет если даже и поделить, там хороший удобный Black TAC 240 при TIL 300, то есть и генерация черного из полезных).

Главная таблица AToB или CMYK->Lab отсмотра изображения гранулярностью повыше - 11. При том что обычно примерно 16 и 30 делают для профилей цветоделения, тут 11 и 9 для профиля просмотра. И не добавлял лишний в данной ситуации тег targ с содержанием промеров для построения профилей.

Попробовал внедрить в пдфку небольшую векторную (158 КБ) из соседней темы про градационные характеристики - полет нормальный.
Можно тестировать.
Обращаю внимание, что цветоделение все же лучше выполнять не этим маленьким профилем для просмотра красок по цвету, а лучше этим: ISO Coated v2 (Arkhip Kuinji shadows).icc и маленький профиль просмотра под фогрой 39 с правильными кстати глубокими тенями лишь внедрять в оконцовке.

Колористика fogra39 improved таблицы CMYK->Lab продолжает развивать эту недавнюю тему верного отображения высоких TIL. Иногда клиенту полезно честно взглянуть на локальные контрасты в глубоких тенях, которые получатся в печати, а не на те, которые он нафантазировал при неверной визуализации своих красочных сепараций в глубоких тенях.

Мы зачастую не заполняем в наших PDF Output Intent профилем просмотра красок просто потому, что не хотим "утяжелять" файл еще на 2 мегабайта, а не потому что плохо относимся к управлению цветом. Все мы прекрасно понимаем, что в настройках акробата клиента может стоять и SWOP и японская газета, и проще профиль в документ внедрить, чем надеяться, что на другой стороне все сами правильно настроят по дефолту для просмотра. Особенно это касается различного рода типографских превью результата растрирования рипом для клиента, когда и файлы делаются покомпактнее, и хочется, чтобы цвет увидели правильно. PDF с нормальным профилем для таких целей, как еще Игорь Бон заметил давно, отлично подходит.

Таблицы в представленном профиле - относительные колориметрические. Rendering Intent Perceptual и Saturation использует их же. Почему Relative - обстоятельно пояснено в этом топике в конце.

Теперь чисто техническая информация, обычные пользователи могут ее пропустить. Таблица AToB сделана в этой моей утилите с небольшими изменениями по коду. Вот код обычный создания разметки таблицы профиля с гранулярностью 16:

Код: Выделить всё

function example2() {
	granular = [0,6.667,13.333,20,26.667,33.333,40,46.667,53.333,60,66.667,73.333,80,86.667,93.333,100]; //16
	//granular = [0,10,20,30,40,50,60,70,80,90,100]; //11
	var outgran = "";
	for(var a=0; a < 16; a++) {
	for(var b=0; b < 16; b++) {
		for(var c=0; c < 16; c++) {
		for(var d=0; d < 16; d++) {
		outgran += granular[a]+'\t'+granular[b]+'\t'+granular[c]+'\t'+granular[d]+'\n';
	}
	}
	}	
	}
	document.table.format.value = outgran;
}

Здесь я временно закомментил массив granular в первой строке функции и раскомментил во второй, то есть сменил гранулярность с 16 на 11. И соответственно в 4 вложенных циклах поменял 16 на 11. Все просто.

Переадресация в профиле с одного тега на таблицу другого делается так в ICCMax:

Код: Выделить всё

<AToB1Tag SameAs="AToB0Tag"/>
<AToB2Tag SameAs="AToB0Tag"/>

И аналогично для обратного направления преобразования. Эти записи включаются вместо таблиц AToB1 и AToB2, таблицы удаляются из профиля. Но ссылка на них ведет всегда в таблицу AToB0 в примере, и профиль стопроцентно правильно верифицируется. Если просто выкинуть таблицы те или иные и не дать на них для тега ссылки - профиль не будет проходить верификацию, может быть не виден программам, словом разные неприятности всего-то без этих пары приведенных строк.

[Obl]

Спасибо, Михаил, буду пробовать ваш профиль в моей системе.

[mihas]

И вам спасибо за интересный вопрос по теме!

[mihas]

Может быть эта тема в привязке к браузеру цветового охвата офсета будет вам любопытна.