а вообще это жопа какая-то, не могу в голове уложить весь процесс профилирования, мозгов не хватает 
Давай попробую на пальцах объяснить. Вот смотри на ужасную картинку (я её честно стырил с википедии и пририсовал к ней ещё 3 треугольника - камеру и 2 монитора):
http://2xsamara.com/temp/Colorspace2.pngЭто картинка с цветовыми охватами (gamut). Внизу на ней, в виде подковы - это те цвета, которые видит человеческий глаз. Всё, что снаружи - мы не видим и формально, это уже не цвет. Почему оно в виде подковы - это сейчас не важно, такая система координат. Важно, что это стандартизованная система координат, точно измеренная в реальном мире и одинаковая для всех.
Большинство цветов в реальной жизни лежат ближе к центру этой подковы, чем дальше от центра - тем цвета насыщенее (и, соответственно, реже встречаются). Поэтому охваты стандартизованных пространств (sRGB, Adobe RGB...) растут вокруг центра подковы.
С точки зрения компьютеров цветовые пространства - это системы координат для реальных цветов. Грубо говоря, в каждом пространстве компьютер может “адресовать” цвет от 0 до 100% насыщенности (условно - расстояние от центра) и 0-100% оттенка (условно - азимут от центра). То есть зная численные значения насыщенности и оттенка, и зная, в какой это системе координат - можно вычислить, какой это будет цвет в реальном мире.
У современных камер довольно широкий охват (красный треугольник), и они видят “цвет” даже там, где его нет - народ снимает и УФ и ИК фото. Это, естественно, для данных, которые лежат в раве. При проявке рава ты выбираешь более узкий охват, для простоты пусть будет sRGB. То есть из всех снятых цветов оставляешь только те, которые входят в треугольник sRGB. Все остальные цвета тем или другим способом тоже загоняются внутрь меньшего треугольника.
Кроме охвата камеры есть ещё охват у монитора. Это все цвета, которые он физически может показывать. В реальном мире. На картинке условно это белый и желтый треугольники, белый для обычного монитора, желтый для wide gamut. Они, естественно, не совпадают с границами стандартных пространств - сильно большая зависимость от физических свойств матриц. А эти свойства, кроме всего прочего, ещё и плавают со временем. Хотя производители и стараются, на хороших мониторах охваты близки к стандартным.
Внутри охвата монитора компьютер оперирует значениями 0-100% по насыщенности и оттенку. И отсюда вытекает основная задача color management-а - “если я в монитор передам команду показать цвет X%,Y% - какой это будет цвет в реальном мире?” (или обратная - “чтобы получить такой-то реальный цвет, какие значения мне надо передать?”). Решить её можно только если для конкретного монитора замерить в реальном мире, что он показывает. Этот замер как раз и делает калибратор. И результат замера сохраняется как профиль монитора.
Дальше, этот профиль в системе прицепляется к монитору, и все желающие его могут взять и посмотреть.
В винде color management не принудительный, и сама система так и продолжает работать в пространстве монитора. Ей пофигу, что зелёная кнопка пуск немного синее будет, она выдаёт значения цветов как если бы монитор четко работал в пространстве sRGB.
Но если приложение сильно хочет - оно может взять из системы профиль и перед тем, как в систему выдавать значения цветов - скорректировать их, чтобы они на выходе из монитора в реальном мире соответствовали эталонным.
Например, фотошоп знает, что он редактирует файл, данные которого определены в пространстве sRGB. Он берёт профиль монитора у системы, и для каждого цвета расчитывает такое значение, которое даст в реальном мире правильный цвет.
Опять же, фотошоп знает исходное пространство потому, что к нему из рав-конвертора пришел файл с прицепленным профилем, в котором написано “я - sRGB”, например.
То же самое делает лайтрум, умные просмотрщики, браузеры. Каждый в меру сил. Например, браузер может скачать картинку, к которой профиля не прицеплено. Тогда он в зависимости от фазы луны и настроек может её считать картинкой в sRGB, а может и не считать. Или например тот же хром по умолчанию считает, что монитор -- точно показывает sRGB. Чтобы он реально профиль из системы взял надо ему ключ при запуске указывать какой-то там.
Глупые просмотрщики и сама система значения никак не преобразовывают. Поэтому когда к ним приходит, например, значение 100% зелёного -- они его в систему и отдают как 100% зелёного. И в реальном мире цвет, который должен был быть с верхней вершины треугольника sRGB, будет показан с верхней вершины треугольника охвата монитора. Для обычных мониторов это не так заметно, вершины рядом. Для wide gamut - цвет выйдет сильно перенасыщенным.
Та же фигня происходит, если делать Assign profile, только уже не в охват монитора, а в охват, который назначается (adobe rgb например). Численные значения для цветов пикселей не меняются, но меняется их интерпретация, система отсчета.
Кроме назначения профиля можно также сделать конвертацию. При этом меняются данные пикселей - они пересчитываются чтобы давать те же реальные физические цвета, что и в исходном пространстве. Тут есть два варианта - конвертация в более узкое пространство, и в более высокое, в каждом свои ньюансы.
При конвертации в более узкое фотошопу надо решить, что делать с цветами, которые не влазят в новый охват. Там в настройках есть несколько вариантов, но в целом этот вопрос очень хорошо освоен в полиграфии, где в очень узкий CMYK пытаются всунуть буйство цветовой фантазии дизайнеров. Для примера картинка с двумя вариантами конвертации, она лучше текста всё поясняет:
http://digitaldog.net/files/Gamut_Clipping_vs_Compression.jpgИ вот тут как раз та проблема, о которой я упоминал - этот процесс нельзя автоматизировать. Нужно смотреть, внимательно, какие цвета потерялись, какие в какие превратились, корректировать, настраивать. Нельзя работать в AdobeRGB/ProPhotoRGB, а потом просто при выводе жпега сказать “а теперь сконвертируй в sRGB”, ибо цвета уйдут нафиг, непредсказуемо.
При конвертации в более широкий охват, казалось бы, всё нормально будет, просто не будет ни единого цвета за пределами оригинального охвата. Но ньюанс тут в том, что цвет у нас дискретно задаётся. Упрощенно: для 8 бит - 256 значений, при расширении охвата в те же 256 значений надо впихнуть больше цветов, значит оригинальные цвета нужно представить меньшим количеством значений. Часть цветов, разных в оригинале, будет представлена одним значением - и здравствуйте градиенты с бандингом. В 16 битах, конечно, проблема нивелируется.
Теперь к вопросу о том, в каком пространстве строить рабочий процесс для стоков. Подразумевается, что финальный вывод будет в жпег/sRGB.
Вариант 1: проявка RAW в ProPhotoRGB, рабочее пространство в фотошопе ProPhotoRGB, перед выводом - конвертация в sRGB.
+ сохраняем все цвета из камеры до самого конца, может быть важно если в процессе обработки в фотошопе(!) есть много работы в насыщенностью, особенно её уменьшения
- поскольку на сегодня ни один монитор не показывает ProPhotoRGB, работать придётся на половину вслепую, постоянно помня, что часть цветов мы не видим, в ходе работы обязателен постоянный пруфинг в sRGB.
- вывод в жпег для стоков становится дополнительной отдельной операцией по цветокоррекции
- обработка только в 16 битах, иначе разрешение по цвету будет никакое
Вариант 2: проявка RAW в AdobeRGB, рабочее пространство в фотошопе AdobeRGB, есть монитор с широким охватом (если монитора с широким охватом нет - это по сути тот же вариант 1).
+ аналогично варианту 1 сохраняем много цветов, не так много, но всё равно примерно на 30% больше sRGB.
+ на широкоохватном мониторе все цвета видно
- нужен пруфинг при работе
- вывод в жпег - тоже отдельная операция
Вариант 3: проявка в sRGB, рабочее пространство в фотошопе sRGB
- всю работу с цветом, особенно с насыщенностью, желательно перенести на этап проявки. (хотя, это сомнительный минус применительно к стокам - “конвеер” в лайтруме сделать проще).
+ можно работать и на мониторе с узким охватом
+ если сильной обработки по цвету в фотошопе нет - есть возможность работы в 8 битах, разрешение по цвету не страдает.
+ не нужен пруфинг
+ не нужен вывод как отдельная операция, просто сохраняется жпег и всё
То есть для стоков наиболее логичным выглядит вариант 3 (я, например, так работаю), но если нужно много обработки по цвету в фотошопе - тогда вариант 2.
Варианты с проявкой в одно пространство, конвертацией в фотошопе в другое и выводом в третье быть не должно в принципе - это тупо лишняя работа и лишние потери на каждом этапе.
