Преобразование RGB в L*a*b*. Фотошоп врет. Почему?

  • Автор темы Автор темы Fedor_Fedor
  • Дата начала Дата начала
Статус
Закрыто для дальнейших ответов.
Другого такого ICC у нас нет и значит пользуемся этим пока что. Лично меня это никак не беспокоит и все нормально считается.
Да, пользуемся, учитываем его ошибки кто в них понимает, другой компьютерной спецификации управления цветом нет. Нормально у тебя считается только когда ты загоняешь себя в узкие рамки, ограничиваешь, сужаешь огромный мир цвета до крохотной точки, даже лампы купил D50 только ради того, чтобы ошибки ICC проходили мимо тебя, хотя полиграфия сто лет с лампами D65 сидела. А ты попробуй с лампами накаливания или D65 проскочить мимо логических ошибок ICC - это весьма не просто. ICC своими ошибками не расширил мир колориметрии а сузил до примитива так, что даже очевидные прорывы науки вроде CIECAM02 вообще никак в эту убогую концепцию и встроить нельзя. Говеная спецификация но другой для компа и правда нет. PCS - зло! Просто упрощение задачи для программиста и снижение нагрузки на процессор, реализация PCS в ICC - это одна большая логическая ошибка.
 
Последнее редактирование:
@TRANTOR CIE даже не соизволила до сих пор опубликовать спектры источника D50 с такими же подробностями, как для источника D65. А ты говоришь D50 имеет какое-то преимущество по CIE. Да никакого, 5003К - просто одна в ряду тысяч температур источника D для расчета CIE Lab.
 
Последнее редактирование:
Но для ICC PCS используется CIE Lab с D50. Все. Конец истории. :)
Есть поправка. Если "Device class: Display" то PCS XYZ (если и не всегда, то во многих случаях). Примеры: встроенный sRGB, eciRGB_v2, eciRGB_v2_ICCv4 и т.д.
показывает координаты цветности (x,y).
OK. Тогда если Вы инженер, этот прибор для Вас не черный ящик.
И понятно, что фиксируют он спектральные данные (Emission). Из которых встроенный микроконтроллер вычисляет XYZ, а затем уже координаты x,y, что собственно и отображает на дисплее. С таким прибором правда много не навоюешь.
Но вот если ориентироваться на "абсолютно черного тела, нагретого до" 5000 Кельвин (не помню я сейчас координат). Потом получить с этих данных RGB-значения и считать используя их, то с фотошоп все сойдется.
Лабов много хороших и разных и свет клином не сошелся на D50.
Ага. А теперь представим, что цвет в брендбуке или где еще задан в Lab. Или библиотека Pantone имеется/встроена только в виде Lab-значений. Пока есть стандарт D50/2 -- все однозначно. Если появятся еще два параметра -- сумасшедший дом покажется раем.
Многие ли заказчики выполняют технические требования? Хотя бы сколько из них встроят профиль если отдают заказ на цифровую печать или цветопробу? Что делать с кучей рипов/софта, которые знают только D50/2 и главное -- где набрать столько квалифицированных операторов?
 
в колориметрии вообще пока нет однозначности, начиная с ламп D50( да хоть 85), спектрально-то они вообще никак не играют с реальным солнечно-небесным D. Ну сделали они тест по 18 образцам - насколько это репрезентативно для всех остальных спектров? да никак. Большой качественный скачок былбы при получении технологичном (массовом) источника E, что ИМХО возможно с QDOT технологией чтобы спектрально сделать ровно - подобрать возбуждающий источник и пленку так, чтобы спектр на выходе был ровный, не говоря пока о дисплеях.
На реальном солнечном свете я вижу, что и D50, и D65 - химеры, все очень сильно плывет от минуты к минуте и от измерения прямого солнца и тени.
При нынешних технологиях пора наработать новую базу данных по тому же "врожденному" нейтральному цвету оттенку после темновой адаптации.
Например, дать 3 минуты на регулировку 3мя выбранными монохромами ( да хоть от REC2020) субъективной точки белого после темноты хотя бы нескольким сотням людей.

CIELab -D50, PCS он же - в рамках ICC.
А что там дяди намеряют проверяющие - так они тем же прибором вооружены, им неведомо про цветопробу у клиента под их частным светом, они заводские спецификации блюдут, а не потребительскую калибровку.
 
Последнее редактирование:
Я думаю, что автор темы получил исчерпывающие ответы и сможет доказать свою правоту.
 
Я думаю, что автор темы получил исчерпывающие ответы и сможет доказать свою правоту.
Да, я же писал. Все ОК.
Господа, в частности, Tantor и Mihas. Не могли бы вы аргументировано пояснить, откуда берется информация о разнообразии колориметрических систем Lab? Я спрашиваю не с целью поспорить, а с целью самообразования. Сам учился у советских авторов учебников по колориметрии, потом сам работал преподавателем в смежной области. У меня другие сведения. Хочу выслушать вашу точку зрения, чтобы попытаться найти истину.

Еще раз кратко изложу то, что сам знаю.
Итак, в 1931 году ученые из МКО (=CIE) предложили систему XYZ, которая всем была хорошо, но одно было плохо - пороговые значения различения ошибки цвета были разными для разных областей локуса. Ученые думали-думали и, кажется, в 1967 или 76-м году - забыл) придумали такое нелинейное преобразование координат XYZ, при котором разница порогов цветоразличения для разных областей колориметрического пространства уменьшается. Хорошие картинки порогов по Мак-Адаму есть в книжке "Колориметрия при видеообработке" (Жак Годен). Назвали они новую колориметрическую систему L*a*b*, чтобы не путать с Hunter Lab. В EN-Вике пишут, что иногда написание L*a*b* можно заменять аббревиатурой CIELAB. Итак, есть только одна система CIELAB.
Далее. При переводе координат XYZ в систему CIELAB используется нормирующий белый Wn(Xn, Yn, Zn). Смысл применения нормирующего белого понятен из формул преобразования XYZ->CIELAB. Это такой цвет, при воспроизведении которого координаты L*a*b* = 100,0,0. То есть если в качестве нормирующего белого я выберу источник А(x = 0.448, y = 0.407), то при пересчете цвета с координатами цветности (x = 0.448, y = 0.407) я получу в системе CIELAB координаты (100,0,0). Очень удобно. Белый в RGB - это 1,1,1 (или 255, 255,255), он же в CIELAB - (100,0,0). Как я уже говорил и приводил ссылки на статью немецкого колориметриста из ICC, кстати (!), в качестве нормирующего белого при пересчете RGB->CIELAB должен использоваться тот же белый, который является опорным для цветового пространства RGB. Если вы производите расчет XYZ->CIELAB, то приведенное выше требования становится бессмысленным, и тогда для в качестве нормирующего нужно использовать белый D50. (Это для меня новость, вычитал в статье Хофмана).
Я так полагаю, что когда в CIELAB используется нормирующий D50, вы называете систему LAB-D50. Когда используется нормирующий D65, вы называете систему LAB-D65. Если так, то я согласен - может существовать бесконечное множество систем CIELAB.

Прошу всех не опускаться до пустых комментариев в стиле "ой дурак, тебе еще учиться и учиться, а я тут из-за вас свое бесценное время трачу".
 
и не предусмотрели вообще защиты от глупейших ошибок производителей софта и производителей профилей
Mihas, а как вы представляете себе защиту от ошибок при создании профиля?
Спрашиваю исключительно из практического интереса. Цветовой профиль (*.icm) в нашей организации я делаю.
 
Спектроанализатор, уважаемый, DimB, показывает координаты цветности (x,y). Для абсолютно черного тела, нагретого до 6500 Кельвин, это 0,313/0.329. Настраивая Cut_Off, Gain и Gamma для каждого из трех каналов монитора, я добиваюсь того, чтобы спектроанализатор показывал заданные значения цветности для всех градаций серого: от черного до белого. Смотрите приложение - спектроанализатор показывает значения цветности x и y.
Вы что-то путаете.
blackbody 6500K - это 0.314 0.324
0.313 0.329 - это daylight 6500K
 
Есть поправка. Если "Device class: Display" то PCS XYZ
Все так. Они, в общем, равноправны. Но считать удобнее в Lab.
Если они равноправны, а так оно и есть, что тогда ты так настаиваешь, что в ISO 11475 речь идет об XYZ D65 а не о лабе непременно. С моей точки зрения одно и то же, белую точку мы берем D65 явно по стандарту. Ну нет у меня на вскидку всех стандартов с иными лабами, солнышко светит, лабы разные, не приходило в голову это доказывать, поди найди стандарт что солнышко оно светит.
 
Если так, то я согласен - может существовать бесконечное множество систем CIELAB.
На остальные вопросы чуть позже отвечу. Множество систем и существует, для удобства формально сократили до нескольких, типа Lab D55, Lab D65 и так далее. В компьютерном колорменеджменте благодаря спецификации ICC прижилось D50 как некая универсальная точка отсчета, упрощающая задачу хромадаптации. Исторически чаще оперировали D65.
 
Mihas, а как вы представляете себе защиту от ошибок при создании профиля?
Ну вот тут я уже описывал подробно типичный пример ошибки, прочитайте обязательно, тему не обсуждали, а она важная: Матрица смены хром. адаптации в новых профайлах от iProfiler
То есть надо быть экстрасенсом чтобы угадать, будет ли применяться матрица из профиля или программа свою зачем-то посчитает и как - ICC позволяет тут любой волюнтаризм и речь идет не о каких-то погрешностях а о заметных цветовых ошибках с дельтой эдак под 30.
Есть еще несколько логических багов. Тоже уже описывал не помню где. Из ошибок на поверхности. Профилировщики не читают из characterisation data данные об иллюминанте, со всем что отлично от D50 надо быть очень осторожным. Argyll вообще ничего не ведает о хромадаптации и путается в правильной белой точке для XYZ и лаба из него. Некоторые другие программы тайно от тебя вообще преобразовывают любой иллюминант в адаптированный к D50 иллюминант уже на стадии charactreisation data и нигде не сообщают об этом. Так же ICC загнало себя в рамки матричных уравнений хромадаптации и PCS, хотя по современному и наиболее достоверному было бы правильно адаптировать по CIECAM02 непосредственно от одной белой точки к другой минуя ненужный вносящий ошибку PCS, но это вообще в рамках icc-профилей невозможно.
Чтобы понимать как защититься надо знать досконально что за матрица в профиле, как программа работает с хромадаптацией. Как-то так.
 
Вот кстати, для программирующих самостоятельно -- ColorPy
Довольно интересный модуль на языке Python. Сам язык простой, на другие можно перевести довольно легко.
 
Да ладно. Может что-то Михаилу пригодится. Та же CIE Chromacity Diagram. Она там вроде честно строится.
А по chromatic adaptaion итак полно информации/источников.
 
Последнее редактирование:
Если человек взялся писать библиотеку и тем более сделал ее общедоступной, то реализовывать надо все, а не только то, о чем успел по-быстрому в Википедии почитать. Например так: Little CMS – Great color at small footprint
 
Пример конечно отличный. И действительно -- она работает. По крайней мере с монитором и с отображением на нем CMYK (Scribus) в линуксе например проблем нет. Изучить API и вперед потихоньку.
Но жестко как-то у Вас выходит. Все или ничего. Только хардкор, только С++. '\:E@@@'
 
Да ладно. Может что-то Михаилу пригодится. Та же CIE Chromacity Diagram. Она там вроде честно строится.
Дмитрий, спасибо! Но для меня это темный лес, посмотрел формулы на непонятном мне языке, проще самому написать на нужном языке даже чем с другого перевести. Недавно надо было алгоритм из Эксела перетащить на яваскрипт, так было мучительно рыться в чужих формулах Excel что просто написал алгоритм с нуля сразу на нужном языке и быстрее получилось и не мучился с чужим файлом. Там картинка была, которая поясняла как алгоритм считает, этого оказалось достаточно.
Да с локусами я разобрался уже давно:
locus.JPG locusa.png
В них просто для xy и ab немного по-разному определяются края.
 
Статус
Закрыто для дальнейших ответов.