Ну, я - маковод
Спасибо за замечания! Про свое место на графиках можно подумать хотя изначальная идея - сбор анонимной статистики а не персонификация. По поводу отличий по всем трем характеристикам - в вашем скриншоте таких отличий нет - там только отличие по цветовому тону hue на 4.5 градуса (80 оттенков). Скрипт не генерит картинок сразу по трем отличиям, в том весь смысл. Каждый может сам это проверить поскольку в ваш скриншот честно внедрен цветовой профиль вашего некалиброванного монитора и проверить не проблема. Конвертим ваш скриншот из вашего монитора в sRGB чтобы работать с цифрами RGB не абы чего а оригинальных изображений (в идеале лучше их скачать а не конвертировать скриншот в sRGB из профиля монитора - погрешность накапливается), затем переходим в 16-бит режим и уменьшаем голубой прямоугольник в фотошопе до размера 2х1 пикселов (я уменьшал половинки прямоугольника по одной и потом слепил 1+1 пиксел в один файл 2х1 пикселов. Поскольку тестовые изображения 11-битные (2560 оттенков, стохастически перемешанных соседних пикселов по цвету) то переход в 16 бит обязателен. Открываем полученный тиф 16 бит в колорлабе! К сожалению колорлаб экспортирует все в 8 бит, тем не менее учитывая эту погрешность все равно видно, что квадраты одинаковые по хроматичности и светлоте и отличаются лишь по тону. В колорлабе создаем из нашего тифа тесткарту для спектроскана и сохраняем как текстовой файл, открываем, проверяем, вот его содержимое:и должен сказать, что тест нуждается в доработках, например вот этот патч:
имеет различия по всем трем характеристикам. Причем практически одинаковую.
Понятно, что это неизбежно в рамках веб-показа sRGB - но дайте тогда возможность выбрать несколько отличий одновременно, потому, что пока приходится тупо угадывать, что вы имели в виду в таких ситуациях.
И было бы отлично увидеть свое место на графиках со статистикой
LGOROWLENGTH 1
CREATED "4/11/2013" # Time: 19:34
KEYWORD "SampleID"
KEYWORD "SAMPLE_NAME"
NUMBER_OF_FIELDS 5
BEGIN_DATA_FORMAT
SampleID SAMPLE_NAME RGB_R RGB_G RGB_B
END_DATA_FORMAT
NUMBER_OF_SETS 2
BEGIN_DATA
1 A1 169.42 194.32 216.98
2 B1 169.16 194.44 222.04
END_DATAну ведь результат с такой точкой все равно останется анонимным - точнее его может опубликовать только сам прошедший тестирование, так что проблем не вижу. Впрочем, вы автор - вам виднее
Не-а
я сначала померял, а потом выложил. завтра могу конкретные цифры указать.К сожалению это возможно только в теории. На практике при генерации в _целочисленном_ LCH и последующей конверсии в _целочисленный_ sRGB (тем более с низкой разрядностью) так красиво не будет. А при отображении с учетом профиля монитора - вообще трудно предсказать, что увидит конкретный пользователь.
Вас ввело в заблуждение название профиля. На самом деле монитор откалиброван с помощью eye-one pro и i1Profiler'a с конечной средней dE меньше 0,75
Зачем такие сложности? у вас в цепочке 4 нелинейных преобразования и интерполяция с не вполне понятным алгоритмом и чудовищным коэффициентом, все это - в целочисленной математике - о какой точности измерений можно говорить?
Опс, я поторопился - преобразований гораздо больше, с сменой разрядности - и потом снова преобразования. Все-таки предлагаю мерять прямо. Пипетка фотошопа нам переводит в лаб и панель инфо - из лаба в нужную модель, если хотите - в 16 бит предварительно перебросьте. По прежнему не понимаю смысла такой длинной цепочки и трех программ. Тем более, что глазами уверенно видно отличие по насыщенности чуть-ли не раньше, че
настраивается в префах панели инфо в новых фотошопах. имеются в виду те префы, что в самой панели.
. Зачем? Я фактически гоню в лаб и оттуда в нужную модель непосредственно из профиля монитора. А как раз профиль монитора как-бы соответствует именно тому, что я вижу. Ну настолько, насколько можно о таком соответствии говорить.
Маковский сафарик? вас обманули. Он там в принципе не отключается.
вот тут:
У меня все расчеты не с целочисленными значениями а с вполне дробными, более 16 знаков после запятой. Для того, чтобы RGB были с точностью до десятых я их свечу на картинку произвольными соседними точками в заданном количестве, например если надо отобразить 12,3 то я создаю 7 точек со значением 12 и 3 точки со значением 13, перемешиваю их и вывожу в картинку в перемешанном виде. Так по каждому цветовому каналу. Получается 2560 оттенков на канал - это позволяет снизить погрешности преобразования на последнем этапе вывода картинки в RGB.
Наверное, я в HSB не проверял что фотошоп насчитывает, все преобразования LCh->Lab->XYZ->sRGB строго по формулам CIE. Хотите еще раз точно все проверить уже в LCh - советую скачивать оригинальные картинки а не делать скриншот в сафари. И фотошоп с целочисленными значениями и пипеткой не очень точный инструмент проверки да и в LCh не умеет считать.
Спасибо, я стараюсь все по науке делать. Ваши скриншоты не совсем понял - если там действительно что-то объясняющее причину, вы их прокомментируйте. Я не скажу наверняка, тут меня пусть поправят гуру Sabos или Алексей Шадрин, но цветовая модель HSB которой вы пытаетесь оперировать ущербная, в ней нельзя корректно оперировать цветом так как она базируется на циферках RGB. Насколько я понимаю, при серьезной работе с цветом можно оперировать только теми цветовыми моделями CIE, которые базируются на координатах XYZ. Не берусь это утверждать стопроцентно но CIE кажется вообще ничего не знает о HSB - формул для нее нет. Какая-то самодеятельность неколориметрическая а не цветовая модель прости господи !-)
комментирую - первая картинка - задран контраст в L при полностью задавленном S(aturation)
Именно дабы не спорить по этому вопросу, на скринах выше я оперировал LCH компонентами.
Не вполне понял, что значит "честно"? Что использовалось и что именно не устроило? Посмотрите в сторону астрономического софта, там с этим строго. IRIS какой-нибудь например очень популярен и находится легко.
Только тиф - штука гибкая, поэтому в дальнейшем лучше той-же программой той-же версии писать самплы.
Спасибо! Нашел где включить для пипетки отображение в 16 бит по вашему скриншоту! Просто надо взять пипетку а не просто мышью по изображению водить другими инструментами!
Ясно! Тогда просьба - исправьте левую или правую часть скриншота так, чтобы между левой и правой половиной была разница в 4,5 градуса по hue и по нулям отклонения по Lightness и Chroma. Присылайте цифры RGB или поправленный таким образом скриншот и скриншоты с задранным контрастом в этой "правильной" картинке - проанализируем правильно ли ваша программа из вашего профиля монитора в LCh пересчитывает.
А нельзя обойтись без Saturation а попробовать в модели LCh задавить именно Chroma в ноль тогда? Не уверен что алгоритм Saturation не задевает светлоту или тон.
в градусах не буду, ладно? там все в флоат, в диапазоне 0-1. Можно конечно пересчитать, но зачем?
Задираем контрасты вокруг зоны перехода, линейно, даже сильнее, чем в первый раз:
Вам нужно будет быть очень убедительным чтобы доказать мне, что ошибается именно "моя" программа. Учитывая ее целевые задачи
можно, но результат будет тот-же. Я его ВИЖУ в оригинале, понимаете? Я скриншот сделал именно на глаз - и уже потом стал мерять, чтобы убедиться.
Я не хочу доказывать, что ваша программа ошибается, я вижу огрехи и пытаюсь битый час в коде найти возможные изъяны но не получается. Методично от формуле к формуле перехожу и проверяю результаты. Я не вижу, чтобы отклонялось все сразу на большую величину но небольшая ошибка в RGB да присутствует, кроме одной величины из LCh слегка колеблются и две остальные. Может 11 бит мало, может в другом месте что-то не так - вобщем ищу пока, где точность падает.Вам нужно будет быть очень убедительным чтобы доказать мне, что ошибается именно "моя" программа. Учитывая ее целевые задачи
Я использую те же формулы CIE на яваскрипте, что и здесь например http://www.brucelindbloom.com/iPhone/ColorConv.html . Вся разница в том, что я гоняю формулы по циклу, обсчитывая массивы, а здесь единичные вычисления. Но в остальном все так же работает - можете понажимать попеременно LCHab и RGB и посмотреть - дрейфа нет. Может в каком 16 знаке после запятой и есть но в целом все эти матричные преобразования CIE работают очень неплохо. Фактически точность упирается только в количество знаков после запятой в матрице перехода а их там 10. А Lab-Lch - это вообще косинус и синус - то есть идеально точно, Lab-XYZ - там аналитические функции тоже без таблиц, умножение, деление и возведение в степень. Фактически погрешность может быть внесена только на этапе XYZ->sRGB коэффициентами матрицы. Но они у Линдблума и у меня в скриптах до 10 знака после запятой так что такой погрешностью можно пренебречь. Вот матрица перехода XYZ->sRGB у меня в тесте:
var MtxXYZ2RGB = {m00:3.2404541621, m10:-1.5371385128, m20:-0.4985314096, m01:-0.9692660305, m11:1.8760108454, m21:0.0415560175, m02:0.0556434310, m12:-0.2040259135, m22:1.0572251882}; // sRGB
Да посмотрите еще парой глаз а то у меня уже все мозги опухли. На вскидку не вижу нигде шумов заметных.