РА>Авторы: РА> Роман Акопов
РА>Аннотация: РА>Статья рассказывает о различных цветовых схемах и о способах преобразования цветовых значений, представленных в различных схемах.
Статья хорошая. Но, есть несколько замечаний:
1) Прочитав аннотацию, я расчитывал увидеть больше формул преобразования цветов. В статье есть все всего одна.
2) Наличие примера работы через ICM это плюс.
3) Описание различных цветовых схем не очень полное.
А так, все круто!
Есть и другие схемы, основанные на представлении цвета не как смеси базовых цветов, а функции параметров иного рода. Например, довольно популярна схема HSB, в которой параметрами являются оттенок (Hue), насыщенность (Saturation), и яркость (Lightness).
А где в слове Lightness буква бэ? Лень самому рыться, может, имелось в виду Blackness?
> А где в слове Lightness буква бэ? Лень самому рыться, может, имелось > в виду Blackness? >
Тогда уж Brightness!!!
Posted via RSDN NNTP Server 1.9 gamma
Не бойся выглядеть глупо, от этого ты выглядишь ещё глупей!!!
Re: Цветовые схемы
От:
Аноним
Дата:
12.10.04 12:30
Оценка:
Здравствуйте, Роман Акопов, Вы писали:
РА>Аннотация: РА>Статья рассказывает о различных цветовых схемах и о способах преобразования цветовых значений, представленных в различных схемах.
А вот кстати, если можно, вопрос: как строить программно графики цветового охвата для конкретного устройства?
(тот который типа
)
Сам цветовой охват я строил так: перебирал все цвета r=0..255, g=0.255, b=0.255, для каждого цвета переводил RGB —> XYZ -> xy, по которым и строил график.
Вопрос в том, как определить, цвета, входящие в гамут определенного устройства? Я использовал функции типа IsColorInGamut (или как-то так, точно не помню), но какая-то фигня получалась...
Re: Цветовые схемы
От:
Аноним
Дата:
15.10.04 11:17
Оценка:
какая-то лажа... формулы перевода RGB->CMY неправильные. правильно
C = 255-R
M = 255-G
Y = 255-B.
также результаты работы программы выглядят сомнительно.
кажется, что 240-C, 240-M, 240-Y, 204-K должны дать правильные значения.
белый цвет в CMYK должен быть (0,0,0,0).
Re[2]: Цветовые схемы
От:
Аноним
Дата:
18.10.04 10:51
Оценка:
Здравствуйте, Аноним, Вы писали:
А>какая-то лажа... формулы перевода RGB->CMY неправильные. правильно А>C = 255-R А>M = 255-G А>Y = 255-B. А>также результаты работы программы выглядят сомнительно.
Не совсем так.
Приведенные формулы — для "идеального" устройства. Реальное устройство вывода будет иметь цвета, отличные от этих. Это связано с тем, какое реально количество краски надо вывести, чтобы получить нужный цвет. Для сравнения можно открыть в Фотошопе файл, задать цвет и посмотреть его значения CMYK. Кстати, значение "точки черного" в Шопе настраивается, по умолчанию RGB(0, 0, 0) = CMYK(75, 68, 67, 90).
Re[3]: Цветовые схемы
От:
Аноним
Дата:
18.10.04 23:50
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Аноним, Вы писали:
А>>какая-то лажа... формулы перевода RGB->CMY неправильные. правильно А>>C = 255-R А>>M = 255-G А>>Y = 255-B. А>>также результаты работы программы выглядят сомнительно.
А>Не совсем так. А>Приведенные формулы — для "идеального" устройства. Реальное устройство вывода будет иметь цвета, отличные от этих. Это связано с тем, какое реально количество краски надо вывести, чтобы получить нужный цвет. Для сравнения можно открыть в Фотошопе файл, задать цвет и посмотреть его значения CMYK. Кстати, значение "точки черного" в Шопе настраивается, по умолчанию RGB(0, 0, 0) = CMYK(75, 68, 67, 90).
гхм... я-то привел формулы для перевода в CMY, а не в CMYK. какие-такие реальные устройства, отображающие цвет в CMY?
ну да ладно, мы с тобой, тезка, в главном-то согласны... что единственная формула приведенная в статье — чушь полная.
Здравствуйте, Lonely Dog, Вы писали:
LD>Статья хорошая. Но, есть несколько замечаний:
Ура!
LD>1) Прочитав аннотацию, я расчитывал увидеть больше формул преобразования цветов. В статье есть все всего одна.
Дело в том, что в интернете повсеместно разбросаны эти формулы. но как показала моя личная практика пользы от них, как от сферического коня в вакууме. Цветные принтеры (особенно струйные) и мониторы ох какие не идеальные устройства.
LD>2) Наличие примера работы через ICM это плюс.
Это не плюс, это суть!
LD>3) Описание различных цветовых схем не очень полное.
Есть и другие схемы, основанные на представлении цвета не как смеси базовых цветов, а функции параметров иного рода. Например, довольно популярна схема HSB, в которой параметрами являются оттенок (Hue), насыщенность (Saturation), и яркость (Lightness).
S>А где в слове Lightness буква бэ? Лень самому рыться, может, имелось в виду Blackness?
Здравствуйте, Аноним, Вы писали:
А>А вот кстати, если можно, вопрос: как строить программно графики цветового охвата для конкретного устройства?
Никак. Это особенность аппаратуры. Либо производитель вам её сообщит, либо нет. Насколько я знаю Photoshop и PhotoPaint показывая Gamut Colors имеют ввиду некие усреднённые устройства.
Здравствуйте, Аноним, Вы писали:
А>ну да ладно, мы с тобой, тезка, в главном-то согласны... что единственная формула приведенная в статье — чушь полная. А>
Идеальной само собой пользоваться бесполезно. Смесь бирюзового, фиолетового и жёлтого цветов даст совсем не чёрный.
Переводить RGB в CMY можно по моим формулам. Но это будет вне контекста устройства, а значит практически бесполезно.
CMYK избыточное пространство. Один и тот же цвет можно теоретически получить разными сочетаниями компонент. Какие конкретно выбрать сочетания сильно зависит от особенностей устройства. Конвертировать RGB в CMYK вне контекста устройства не имеет большого смысла.
Соотвественно и формулы для конвертации RGB в CMYK это нонсенс. Может быть только таблица соответствия созданная производителем аппаратуры.
A>Переводить RGB в CMY можно по моим формулам. Но это будет вне контекста устройства, а значит практически бесполезно.
Роман, я уже 2 раза написал: нельзя переводить RGB в CMY по Вашим формулам! По ним получается, что черный цвет (0,0,0) в RGB переводится в (0,0,0) в CMY. Но (0,0,0) в CMY это белый цвет! Ведь очевидно, что если одна схема аддитивная, а другая субтрактивная, то схемы перевода из одной в другую должны включать компоненты цвета с отрицательными коэффициентами.
А по Вашей формуле перевода CMY->RGB A>R = (M + Y — C) A>G = (C + Y — M) A>B = (C + M — Y)
вообще можно получить отрицательные значения RGB: (1,0,0) в CMY переводится в (-1,1,1) в RGB.
Аналогично, результат работы программы тоже неверен. В чем проблема, я сказать не могу, с ICM я не работал, но базовые цвета должны переводиться в базовые. А у Вас белый переводится в что-то бессмысленное: A> RGB(255, 255, 255) aka 'White' corresponds to CMYK(240, 240, 240, 204)
На самом деле, в CMYK есть ограничение на сумму компонент C+M+Y+K, т.е. на общее количество краски на точку. И такое количество краски (240+240+240+204) никто не позволит налить. А если бы позволили, то в результате получилось бы что-то черное.
Здравствуйте, Аноним, Вы писали:
А>Аналогично, результат работы программы тоже неверен. В чем проблема, я сказать не могу, с ICM я не работал, но базовые цвета должны переводиться в базовые. А у Вас белый переводится в что-то бессмысленное:
Вы судя по всему вообще не разобрались в программе! Ничего аналогичного там бытьне может, так как используется ICM. Но я вполне готов признать, что Я и все разработчики ICM, вместе не правы, если вам так лучше спится.
A>Вы судя по всему вообще не разобрались в программе! Ничего аналогичного там бытьне может, так как используется ICM.
А Вы, судя по всему, вообще не удосужились задуматься над тем, что я пишу. Я не слепой и не идиот, вижу, что используется. Но для того, чтобы понять, что программа работает неверно, не обязательно разбирать код, если видно, что она выдает неверные результаты. Даже удивительно, почему автора не озадачил тот факт, что blacK-компонента всех цветов (в том числе белого!) оказалась равна 204.
A>Но я вполне готов признать, что Я и все разработчики ICM, вместе не правы, если вам так лучше спится.
Я про разработчиков ICM вроде ничего не говорил. А Вы уж будьте готовы к тому, что текст, который Вы предлагаете для публичного внимания, будет также публично обсуждаться и критиковаться. А постольку, поскольку этот текст может кем-то воспринят как руководство по использованию ICM, то я готов обсуждать его до тех пор, пока мы не придем к какому-то согласию. Пользы от этого больше, чем от отзывов типа "Все круто!".
Я потратил некоторое время на то, чтобы попытаться разобраться в ICM. На уровне моего сегодняшнего понимания я вижу две ошибки в использовании функции TranslateColors в статье.
1. Компоненты цвета (RGB, CMYK, XYZ, LAB) в структуре COLOR имеют тип WORD, т.е. 16-битные, а автор пытается работать с ними как с 8-битными:
2. Нельзя использовать произвольно выбранный профайл для преобразования в требуемую цветовую систему (в нашем случае CMYK). Профайл должен поддерживать эту цветовую систему. На фоне практически полного отсутсвия информации по ICM, следующее сообщение, которое я нашел в группе microsoft.public.win32.programmer.gdi, прямо-таки откровение:
From: Antti Nivala (antti.nivala@motivesys.com)
Subject: Re: Transforming colors with ICM
Date: 2004-01-06 05:04:42 PST
> > Doesn't anybody have any clue about this? It can't be that I'm the only
> > one experiencing this problem, am I?
I think I had the same problem, too. I first assumed I can just use ICM to
convert from CMYK to RGB using TranslateColors. However, this only works if
the color transformation you give to TranslateColors is compatible with the
color spaces involved.
To convert from CMYK to RGB using TranslateColors, you must have a color
transform that converts from a CMYK-based ICC profile's color space to an
RGB-based profile's color space. If you just take the printer's profile and
use it as the source you might likely have an RGB profile because
non-PostScript Windows printers can only have RGB profiles. Only PostScript
printers can have CMYK profiles in Windows.
What I found most strange was that if I use TranslateColors to convert from
CMYK to RGB and give it an RGB-RGB transformation, it claims success but
does not really do the conversion. I think it just copied the values
literally and reported success (why???). This could explain why your CMYK
yellow (0, 0, 65535, 0) results in RGB blue (0, 0, 65535): TranslateColors
did not really do any conversion, and you are interpreting the original CMYK
values as if they were RGB (yellow and blue are in the same byte slots in
the union...).
TranslateBitmapBits reports an error in a similar situation, I don't
understand why TranslateColors does not.
Antti Nivala
Motive Systems
В моем случае TranslateColors с использованием профайла монитора в действительности меняет каким-то образом RGB-компоненты (которые расположены там же, где и CMY-компоненты в union COLOR), но, как оказывается, оставляет неизменной K-компоненту. Таким образом, K=204 (или 0xCC) появляющееся при конвертации всех четырех цветов в статье — просто мусор, оставшийся просто потому, что переменная source не была полностью проинициализирована.
Неудивительно, что профайл монитора не поддерживает CMYK. Список профайлов, поддерживающих CMYK, можно получить следующим образом:
Здравствуйте, nikkie, Вы писали:
N>А Вы, судя по всему, вообще не удосужились задуматься над тем, что я пишу. Я не слепой и не идиот, вижу, что используется. Но для того, чтобы понять, что программа работает неверно, не обязательно разбирать код, если видно, что она выдает неверные результаты. Даже удивительно, почему автора не озадачил тот факт, что blacK-компонента всех цветов (в том числе белого!) оказалась равна 204.
Кто сказал, что не озадачил? Просто я печатал на струйных принтерах (которые несомненно CMYK) изображения в BMP/GIF/JPEG форматах (которые хранятся в программах как RGB) явно указывая какие ICM-профили использовать. Результаты были разные (не редко довольно поганые), но белый всегда оставался белым, а чёрный — чёрным. Я не имею ни малейшего понятия как принтер воспринимает число 204 (80%) в качестве чёрной составляющей, я знаю что когда этот цвет посылаешь на принтер, то выходит белый. Мне этого достаточно. Зачем вникать в особенности восприятия принтером значений CMYK когда ICP-api создано как раз чтобы НЕ вникать?
A>>Но я вполне готов признать, что Я и все разработчики ICM, вместе не правы, если вам так лучше спится. N>Я про разработчиков ICM вроде ничего не говорил. А Вы уж будьте готовы к тому, что текст, который Вы предлагаете для публичного внимания, будет также публично обсуждаться и критиковаться. А постольку, поскольку этот текст может кем-то воспринят как руководство по использованию ICM, то я готов обсуждать его до тех пор, пока мы не придем к какому-то согласию. Пользы от этого больше, чем от отзывов типа "Все круто!".
Вот с этим абсолютно согласен! Только давайте не скатываться на фразы типа "ты — дурак" (ОК, я тоже был резок — извиняюсь), а обсуждать конструктивно.
N>Я потратил некоторое время на то, чтобы попытаться разобраться в ICM. На уровне моего сегодняшнего понимания я вижу две ошибки в использовании функции TranslateColors в статье.
N>1. Компоненты цвета (RGB, CMYK, XYZ, LAB) в структуре COLOR имеют тип WORD, т.е. 16-битные, а автор пытается работать с ними как с 8-битными:
OK, принимается. Вот вывод если везде 255 заменить на 65535
DISPLAY ADAPTERS
Enumerating for adapter '\\.\DISPLAY1'
Testing profile 'C:\WINDOWS\system32\spool\DRIVERS\COLOR\995E.ICM'
RGB(65535, 65535, 65535) aka 'White' corresponds to CMYK(255, 40, 248, 204)
RGB(65535, 0, 0) aka 'Red' corresponds to CMYK(255, 0, 0, 204)
RGB( 0, 65535, 0) aka 'Green' corresponds to CMYK( 21, 105, 0, 204)
RGB( 0, 0, 65535) aka 'Blue' corresponds to CMYK( 9, 168, 74, 204)
End of enumeration for adapter '\\.\DISPLAY1'
Enumerating for adapter '\\.\DISPLAYV1'
End of enumeration for adapter '\\.\DISPLAYV1'
Enumerating for adapter '\\.\DISPLAYV2'
End of enumeration for adapter '\\.\DISPLAYV2'
END DISPLAY ADAPTERS
PRINTERS
Enumerating for printer 'PDFConverter'
End of enumeration for printer 'PDFConverter'
Enumerating for printer 'PDF Creator'
End of enumeration for printer 'PDF Creator'
Enumerating for printer 'Fax'
End of enumeration for printer 'Fax'
END PRINTERS
Как видишь значения CMYK остались в пределах 0-255, хотя структура CMYKCOLOR объявлена так
struct CMYKCOLOR {
WORD cyan;
WORD magenta;
WORD yellow;
WORD black;
};
Так что на мой взгляд входные данные должны быть в диапазоне 0-255, а тип WORD это. Более того, если бы погляден заголовочный файл, где описывается константа COLOR_RGB то увидел бы рядом другую. вот всё объявление полностью.
typedef enum {
COLOR_GRAY = 1,
COLOR_RGB,
COLOR_XYZ,
COLOR_Yxy,
COLOR_Lab,
COLOR_3_CHANNEL, // WORD per channel
COLOR_CMYK,
COLOR_5_CHANNEL, // BYTE per channel
COLOR_6_CHANNEL, // - do -
COLOR_7_CHANNEL, // - do -
COLOR_8_CHANNEL, // - do -
COLOR_NAMED,
} COLORTYPE;
N>2. Нельзя использовать произвольно выбранный профайл для преобразования в требуемую цветовую систему (в нашем случае CMYK). Профайл должен поддерживать эту цветовую систему. На фоне практически полного отсутсвия информации по ICM, следующее сообщение, которое я нашел в группе microsoft.public.win32.programmer.gdi, прямо-таки откровение:
From: Antti Nivala (antti.nivala@motivesys.com)
Subject: Re: Transforming colors with ICM
Date: 2004-01-06 05:04:42 PST
...............
...............
..............
N>В моем случае TranslateColors с использованием профайла монитора в действительности меняет каким-то образом RGB-компоненты (которые расположены там же, где и CMY-компоненты в union COLOR), но, как оказывается, оставляет неизменной K-компоненту. Таким образом, K=204 (или 0xCC) появляющееся при конвертации всех четырех цветов в статье — просто мусор, оставшийся просто потому, что переменная source не была полностью проинициализирована.
ОК, теперь давай разберёмся, что мы утверждаем. Что TranslateColors вообще нельзя использовать или что мой пример был неудачным потому что основывался на мониторе — не CMYK устройстве.
С другой стороны, что нам мешает CMYK трансформировать в RGB в контексте монитора? Это-то точно имеет смысл.
Как показал мой экперимент значение source.cmyk.black не имеет никакого значения для трансформации.
N>Тестирование TranslateColors с использованием профайла, поддерживающего CMYK, дает следующий результат, который уже больше похож на правду: N>
N>>1. Компоненты цвета (RGB, CMYK, XYZ, LAB) в структуре COLOR имеют тип WORD, т.е. 16-битные, а автор пытается работать с ними как с 8-битными:
A>OK, принимается. Вот вывод если везде 255 заменить на 65535
A>
A>...
A>
A>Как видишь значения CMYK остались в пределах 0-255
Осталось еще насильное приведение к BYTE убрать.
A>Более того, если бы погляден заголовочный файл, где описывается константа COLOR_RGB то увидел бы рядом другую. вот всё объявление полностью. A>
A>typedef enum {
A> COLOR_GRAY = 1,
A> COLOR_RGB,
A> COLOR_XYZ,
A> COLOR_Yxy,
A> COLOR_Lab,
A> COLOR_3_CHANNEL, // WORD per channel
A> COLOR_CMYK,
A> COLOR_5_CHANNEL, // BYTE per channel
A> COLOR_6_CHANNEL, // - do -
A> COLOR_7_CHANNEL, // - do -
A> COLOR_8_CHANNEL, // - do -
A> COLOR_NAMED,
A>} COLORTYPE;
A>
Ну и о чем это говорит? Структура COLOR состоит из 4 WORD. Поэтому 5-6-7-8-канальный формат цвета использует BYTE на каждый канал. Остальные — WORD.
A>ОК, теперь давай разберёмся, что мы утверждаем. Что TranslateColors вообще нельзя использовать или что мой пример был неудачным потому что основывался на мониторе — не CMYK устройстве.
ИМХО, ошибка была в том, что использовался профайл, неподдерживающий CMYK.
Более того, я привел цитату Antti Nivala (и я склонен ему доверять — чувствуется, что он понимает то, о чем пишет), в которой он утверждает, что профиль принтера вполне может оказаться RGB. То есть, если брать профиль от принтера, то еще нет гарантии, что он будет поддерживать CMYK.
A>С другой стороны, что нам мешает CMYK трансформировать в RGB в контексте монитора? Это-то точно имеет смысл. A>Как показал мой экперимент значение source.cmyk.black не имеет никакого значения для трансформации.
ИМХО, TranslateColors может игнорировать параметры ctInput и ctOutput в определенных ситуациях (например, при попытке выполнить преобразование к CMYK с помощью RGB-профиля). Тот же Antti Nivala написал:
TranslateBitmapBits reports an error in a similar situation, I don't understand why TranslateColors does not.
A>>ОК, теперь давай разберёмся, что мы утверждаем. Что TranslateColors вообще нельзя использовать или что мой пример был неудачным потому что основывался на мониторе — не CMYK устройстве. N>ИМХО, ошибка была в том, что использовался профайл, неподдерживающий CMYK.
ОК, недоглядел.
N>Более того, я привел цитату Antti Nivala (и я склонен ему доверять — чувствуется, что он понимает то, о чем пишет), в которой он утверждает, что профиль принтера вполне может оказаться RGB. То есть, если брать профиль от принтера, то еще нет гарантии, что он будет поддерживать CMYK.
Ну лично для меня довольнос транно, что принтер имеет RGB профиль.
N>ИМХО, TranslateColors может игнорировать параметры ctInput и ctOutput в определенных ситуациях (например, при попытке выполнить преобразование к CMYK с помощью RGB-профиля). Тот же Antti Nivala написал: N>
N>TranslateBitmapBits reports an error in a similar situation, I don't understand why TranslateColors does not.
N>
И это полнейший идиотизм со стороны данной функции. Я подумаю можно ли как-то отследить данные случаи.