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.