Здравствуйте, 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> Testing profile 'Photoshop4DefaultCMYK.icc'
N> RGB(FFFF, FFFF, FFFF) aka 'White' corresponds to CMYK( 10, A, 0, 0)
N> RGB(FFFF, 0, 0) aka 'Red' corresponds to CMYK( 0, EB3C, FF5C, 0)
N> RGB( 0, FFFF, 0) aka 'Green' corresponds to CMYK(A5D1, 0, EE2A, 0)
N> RGB( 0, 0, FFFF) aka 'Blue' corresponds to CMYK(FFFF, DABE, 0, 0)
N>
Хорошо бы это потестировать на RGB(FF, FF, FF), тогда уже можно будет точно говорить.
