LINUX.ORG.RU

xiccd - управление цветовыми профилями в X

 , ,


3

1

Сегодня вышла новая версия xiccd - демона, управляющего цветовыми профилями мониторов.

xiccd работает совместно с colord и позволяет автоматически настраивать цветовые профили (icc) в графических средах, подобных Xfce, в которых подобная функциональность не встроена. До сих пор такая возможность существовала лишь в Gnome («из коробки») и в KDE (при использовании colord-kde). Пользователям других оболочек приходилось загружать цветовые профили вручную с помощью xicc, dispwin или dispcalGUI, что может не работать в конфигурациях с несколькими мониторами или при использовании некоторых colord-совместимых графических пакетов.

После установки xiccd список существующих мониторов и пользовательских цветовых профилей становится доступен в colord, что позволяет средствами colord устанавливать и выбирать нужный цветовой профиль. Корректно обработано «горячее» подключение и отключение мониторов. Тем самым, например, при подключении к ноутбуку проектора его цветовой профиль подгружается автоматически. При отсутствии точного цветового профиля создается приближенный по EDID-информации монитора.

В отличие от демонов, подобных colord-kde, xiccd не зависит ни от каких пакетов, от которых не зависит colord (за исключением X), что позволяет использовать его в любых системах в любом окружении. На сегодняшний день поддерживается загрузка профилей в X и чтение пользовательской директории профилей. Для работы необходима поддержка XRandR 1.3 и выше.

В сегодняшней версии 0.2.2 исправлены падения и откорректировано опознание мониторов в режиме «Mirror screen».

>>> Скачать xiccd



Проверено: Shaman007 ()

Ответ на: комментарий от Yampp

Маленькая подсказка: если провести аналогию с кодировками, ты придумал, что экран должен работать в CP1251, а система должна сама конвертировать из UTF-8 в CP1251, но при этом совершенно забыл, что есть и другие однобайтовые кодировки: KOI-8 например.

Любой RGB - это как однобайтовая кодировка. Если у тебя в системе один RGB, а в файле другой - хоть надорвись, но без перекодировки отобразить правильно не сможешь.

Yampp
() автор топика
Ответ на: комментарий от Yampp

Если у тебя в системе один RGB, а в файле другой - хоть надорвись, но без перекодировки отобразить правильно не сможешь.

Но ведь очень хочется! :)

AP ★★★★★
()
Ответ на: комментарий от AP

Кстати. Надоел мне этот анонимус, а вот к тебе, AP, вопрос по делу есть. Ты смотрел, как устроена цветокоррекция в CUPS и как это взаимодействует с colord? Не знаю как тебе, а вот мне лично это место очень не нравится. Хочу переписать. Уже обсудил с Richard Hughes, он за, Till Kamppeter пока молчит (мои багфиксы он принял). Пока для чистоты эксперимента не буду говорить, что именно я придумал (и нашу переписку с Richard Hughes не ищи пока, ладно?). Интересно твое мнение о проблеме в целом, хочу сравнить со своим видением.

О чем именно я. Дано: фотопринтер, куча разных сортов бумаги, каждый сорт бумаги честно обмерян ColorMunki. Надо: печатать на этом все подряд (не только фотографии) с минимумом лазаний в настройки. Для каждого случая я выбираю индивидуально свой сорт бумаги.

Yampp
() автор топика
Ответ на: комментарий от Yampp

Ну так Тим Вох уже начинал писать printerd. Ричард про это не говорил?

https://github.com/hughsie/printerd

Они, правда, пока прикопали этот проект за отсутствием времени.

AP ★★★★★
()
Последнее исправление: AP (всего исправлений: 1)
Ответ на: комментарий от AP

Я видел этот проект, но тот кусок, который мне не нравится, они как раз «как есть» переносят из CUPS. Так что это ничего не меняет.

Несуразностьотносится к взаимодействию cupsd(printerd)-gstoraster-colord-gutenprint, а не к устройству cupsd/colord как такового.

Yampp
() автор топика
Ответ на: комментарий от Yampp

Маленькая подсказка: если провести аналогию с кодировками, ты придумал, что экран должен работать в CP1251, а система должна сама конвертировать из UTF-8 в CP1251, но при этом совершенно забыл, что есть и другие однобайтовые кодировки: KOI-8 например.

Ну, если тебе на примере кодировок понятнее, то объясню на их примере. Може тебе так действительно проще понять будет.

Вот возьмём программу на джаве, которая спокойно работает себе в юникоде, который покрывает все установленные в системе кодировки. И когда прграмме на джаве хочется вывести что-то в консоль - она просто вызывает что-нибудь типа System.out.print(), нисколько не заботясь о том, что за фигню юзер понаконфигурял. Это не её проблемы как там «система» (в данном случае включая и джавовский рантайм) будет выкручиваться с выводом этих символов.

Теперь распространим аналогию на нашу систему с видевыводом. Каждая программа содержит в себе кучу функционала, перекодирующего строки из одной кодировки в другу, зачастую разные программы используют разную реализацию одного и того же функционала. Разумеется вся эта свалка мусора украшена велосипедами наподобие демонов charsetd и ссccd - демона, управляющего цветовыми профилями мониторов.

Авторы же всего этого говна и им сочувствующие, на вопрос а не логичнее ли реализовать делать преобразование наподобие того как это делается в джавовской программе, вместо того, чтобы велосипедить этот функционал в прикладном ПО, попутно увешивая его велосипедами - утверждают что так сделать нельзя, а в ответ на вопрос «а почему, собственно» - мы получаем от них сплошные оскорбления, наезды и попытка=и перевести тему разговора.

Так тебе понятнее?

anonymous
()
Ответ на: комментарий от anonymous

А теперь анонимусу предлагается взять старый матричный принтер, который поддерживает только 8-битную кодировку, и попробовать на нем что-нибудь распечатать из программы на java, работающей в Unicode. Распечатать надо два текста - один на русском, другой на японском. Проблема ясна? В зависимости от того, какой именно текст печатается, требуется перепрограммировать принтер. Та же самая проблема, кстати, возникает при желании выводить текст на экран в текстовом (не во фреймбуферном) режиме видеокарты (как в DOS было).

Как решили проблему с кодировками. Выкинули все, что работает с 8-битными кодировками, и заменили на Unicode. А с цветом как?

Есть утопичное универсальное решение проблемы: использовать всюду цветовое пространство CIE XYZ. Все мониторы, принтеры, сканеры, фотоаппараты, телевизоры, видеокамеры и т.д., работающее в RGB и CMYK, объявить устаревшим и отнести на помойку. Весь софт, работающий в RGB, тоже отнести на помойку. Стандарт HTML переделать. Веб-мастера, привыкшие писать цвет #FF00EA, программисты, привыкшие писать RGB, дружно идут вешаться - работать в CIE XYZ очень непросто. Так выглядел бы «unicode» для цвета. В 2113-м году оно может быть так и будет, но нам надо сейчас. Даже если мы в линуксе сейчас всюду CIE XYZ введем, откуда мы такие мониторы возьмем? Кто нам их сделает?

Есть РЕАЛИСТИЧНОЕ решение проблемы. Продолжить работать в RGB, но смириться с тем фактом, что для разных целей требуются разные RGB, разные устройства могут работать в разных RGB и так далее. (Продолжая аналогию с кодировками: представь, как если бы мы внезапно обнаружили, что знакогенераторы всей техники никакого Unicode не поддерживают и в ближайшие 20 лет точно не собираются, и никакого графического режима отображения текста у нас нет и не будет, и вообще и все, что у нас есть - это 256 символов, как в старом добром DOS). По мере надобности придется делать перекодировку или перепрограммировать железо. Это как раз то, что во всех системах и делают. Поскольку одних лишь RGB-пространств есть не меньше четырех штук (и это не считая не-RGB, вроде всяких XYZ и Lab), одно из них объявляется дефолтным. Это - sRGB (оно играет ту же роль, что кодировка Latin-1 - ни фига не умеет, зато заведомо всеми кое-как поддерживается). Все, кто хочет нарисовать просто кнопочку красного цвета, идут в sRGB. Кому этого не хватает, работают в том, в чем считают нужным.

Зачем демон. Затем, что железо иногда надо перепрограммировать под нужды той или иной программы. На многих мониторах, например, есть переключение режима: «десктоп», «игра», «мультимедиа», не говоря уж о яркости и контрасте. Что делать, если одна программа хочет включить один режим, а другая другой? Отправить одну из программ лесом, очевидно. Какую именно? Решает единый центр управления цветом - демон, который всегда знает, какие настройки железа в данный момент в каком драйвере установлены. Почему не сам драйвер? Потому что железо - это не только мониторы, но и принтеры, сканеры и т.д. Чтобы не велосипедить код в каждом драйвере, его собрали в одно место - в демон.

Зачем перепрограммировать железо. Опять пример с кодировками. Есть кодировка русская cp866, в ней есть символы рисования рамок, но нету буквы Ґ некоторых языков. Есть кодировка русская cp1251, в которой есть буква Ґ, но нет символов рамок. В знакогенератор старой видеокарты влезает только одна из них, работа идет в текстовом режиме. Что делать, если сначала мы работаем с текстом с буквой Ґ, а потом хотим запустить Norton Commander, который рисует рамки? Решение очевидно. С цветами - то же самое: современное железо может охватить только часть любого из RGB-пространств, но какую именно часть - от настроек зависит. (Это на принтерах особенно хорошо видно). Чтобы выжать из железа максимум возможностей, надо переключать настройки на лету.

Как этим пользоватья. Если ты просто рисуешь в sRGB, тогда рисуй и все - драйвер все правильно сделает. Если тебе в sRGB тесно, рисуй через lcms2 и попроси colord загрузить в железо нужные тебе особые настройки. Интерфейс одинаков для рисования на экране, печати на принтере, захвата видео с камеры и т.д.

Понятно объяснил, или троллить будешь?

Yampp
() автор топика
Ответ на: комментарий от Yampp

Ну и напоследок. Почему lcms2 вызывает софт, а не драйвер? Чтобы избежать двойной перекодировки. Умеющий работать с графикой софт всегда умеет переконвертировать цвета хотя бы потому, что он умеет открывать файлы, созданные в разных цветовых пространствах. Разумеется, перед выводом изображения ему придется сделать переконвертацию из своего рабочего цветового пространства в системное (например, из Adobe RGB в CIEXYZ или в sRGB). Затем драйверу придется переконвертировать еще раз - из CIEXYZ или sRGB в цветовое пространство железа. Переконвертация во-первых страшно дорогая операция, во-вторых может быть с потерями. Логично конвертировать в один шаг, а не в два (сразу из Adobe RGB в цветовое пространство железа). В программе или в драйвере? В программе конвертация и так уже есть, при открытии файла. Поэтому - в программе. Иначе опять же будет двойная переконвертация, если мы просто хотим просмотреть файл.

Yampp
() автор топика
Последнее исправление: Yampp (всего исправлений: 1)
Ответ на: комментарий от Yampp

А теперь анонимусу предлагается взять старый матричный принтер, который поддерживает только 8-битную кодировку, и попробовать на нем что-нибудь распечатать из программы на java, работающей в Unicode. Распечатать надо два текста - один на русском, другой на японском. Проблема ясна? В зависимости от того, какой именно текст печатается, требуется перепрограммировать принтер.

Ну так я о чём и говорю - зачем программы будут таскать в себе код, который будет перепрограммировать принтер? Прикладные программы должны решать свои задачи, а за перепрограммирование устройств вывода, если таковое необходимо, несёт ответственность соответствующий драйвер.

Программа всего лишь должна сказать системе: «а напечатай-ка мне вот этот буфер который содержит данные в таком-то поддерживаемом тобой формате» - и всё.

Как решили проблему с кодировками. Выкинули все, что работает с 8-битными кодировками, и заменили на Unicode.

В джаве решили так. Но в принципе это лишь один из способов передавать информацию о кодировке символов, как ты можешь догадаться.

А с цветом как?

Отдельным параметром при выводе буфера передавать интент, например. Юникодный аналог - передавать информацию об интенте с каждым пикселом - наверное, не самое эффективное решение :)

--- Дальше твой пост пока не читал, потому что вижу, что ты и с кодировками пока ещё не разобрался.

anonymous
()
Ответ на: комментарий от Yampp

Разумеется, перед выводом изображения ему придется сделать переконвертацию из своего рабочего цветового пространства в системное (например, из Adobe RGB в CIEXYZ или в sRGB).

В системе используются железонезависимые типы буферов, которые я тебе несколько раз уже перечислял на примере Х11. Там нет профилей Adobe RGB или sRGB, они линейные же.

Затем драйверу придется переконвертировать еще раз - из CIEXYZ или sRGB в цветовое пространство железа.

Нет, ему придётся преобразовывать твоё XYZ, u'v'Y, xyZ L*a*b*, L*u*v*, TekHVC или RGB Intencity в цветовое пространство, специфичное для данного устройства, с использованием профиля, специфичного для данного устройства и с учётом интента, указанного прикладной программой, которая знать ничего не должна про твоё устройство.

anonymous
()
Ответ на: комментарий от anonymous

Ну так я о чём и говорю - зачем программы будут таскать в себе код, который будет перепрограммировать принтер?

Ну так ОНИ И НЕ ТАСКАЮТ! Этот код содержится в демоне. Программы просто говорят демону, чего именно они хотят от железа.

Программа всего лишь должна сказать системе:

Предлагаешь сделать в каждом драйвере каждого устройства велосипед цветопередачи? Отдельно в драйвере принтера, отдельно в драйвере графики, отдельно в драйвере камеры, отдельно для фотоаппарата и т.д.?

Может быть все-таки ЕДИНОЕ решение лучше?

В джаве решили так. Но в принципе...

А не приведешь ли конкретный пример системы, в которой сделано иначе?

Дальше твой пост пока не читал, потому что вижу, что ты и с кодировками пока ещё не разобрался.

Эх, анонимус, анонимус... Любишь ты обвинять в некомпетентности... высокооплачиваемых специалистов с 15-летним стажем, собаку съевших на кодировках и не только. Не ровен час, ко мне же и на собеседование придешь когда-нибудь. Как раз про кодировки я кандидатов люблю спрашивать.

Юникодный аналог - передавать информацию об интенте с каждым пикселом - наверное, не самое эффективное решение :)

А где это, скажи мне, в юникоде передается информация о кодировке с каждым символом? В UTF обычное арифметическое кодирование чисел, код символа занимает от 1 до 6 байт, длина кода определяется по первым битам кода. В UCS вообще числа фиксированного размера. Не выдумывай то, чего нету и не рассказывай сказки о том, в чем не разбираешься. Над тобой тут и так уже все откровенно смеются.

Yampp
() автор топика
Ответ на: комментарий от anonymous

В системе используются железонезависимые типы буферов, которые я тебе несколько раз уже перечислял на примере Х11. Там нет профилей Adobe RGB или sRGB, они линейные же.

То, что в иксах именуется «RGB» и «RGBi», по факту совпадает с sRGB. В этом нетрудно убедиться, просто выведя любое sRGB-изображение без преобразования цвета.

Нет, ему придётся преобразовывать твоё XYZ...

То есть - преобразование будет делаться ДВА РАЗА. Один раз я преобразую из Adobe RGB в XYZ, потом драйвер из XYZ в железо. За-ме-чательно. Ничего, что на Core i7 каждая из этих операция для полного экрана занимает около 0.5 секунды?

Кстати, анонимус, ты уже расшифровал смысл всех этих аббревиатур? Например, что такое «RGB Intensity» и чем оно отличается от «RGB», знаешь? Также не забудь сказать, какая в каждом из этих пространств точка белого и чему равны цветовые координаты каждого из основных цветов. Продемонстрируй свои знания.

Yampp
() автор топика
Ответ на: комментарий от morse

Победа! Я понял как вручную назначить профиль изображению. Крутота!

Поздравляю! Кстати, видна разница в интентах отрисовки. По этой картинке правильность цвета легко определить: там слева вверху фотографии трех цветовых эталонов, X-Rite Color Checker (он же GretagMacbeth), ITU и Kodak/Tiffen. Можно просто сравнить фото с оригиналом.

Yampp
() автор топика
Ответ на: комментарий от Yampp

У меня нет color checker'а. Есть только его фотография которую я делал у знакомых когда создавал профиль для своего фотика :)

morse ★★★★★
()
Ответ на: комментарий от morse

Дорогая штука, на самом деле. Впрочем, одолжить можно. Вообще для создания профилей работает только один нормальный вариант - спектрофотометр (не спектроколориметр), а «недорогой» ($500) спектрофотометр пока есть ровно один, ColorMunki Design/Photo (отличие только в комплектации и в цвете корпуса). Если что, рекомендую комплектацию «Photo», там почти халявный ColorChecker в комплекте. Вещь полезная, но мало кто может себе позволить. Если сам фотограф и с фотографами дружишь, советую всем вместе скинуться и купить один на всех. Ну а если зарплата хорошая, тогда просто себе купи :) Им еще удобно в цвет попадать - к любому предмету прикладываешь и сразу его XYZ знаешь. Или свет измерять, чтобы фотку напечатать с коррекцией под лампы, при которых ее смотреть будут.

Я в общем-то потому xiccd и написал, что купил ColorMunki и обнаружил, что нормально воспользоваться им могу только в Gnome. Решил исправить этот непорядок.

Yampp
() автор топика
Ответ на: комментарий от Yampp

Ну так ОНИ И НЕ ТАСКАЮТ! Этот код содержится в демоне. Программы просто говорят демону, чего именно они хотят от железа.

А демон сам разбирается как на чём рисовать?

Предлагаешь сделать в каждом драйвере каждого устройства велосипед цветопередачи?

Ну да, естественно. Драйвер каждого устройства вывода должен уметь сам выводить массив пикселей в устройствонезависимом формате на своё устройство.

Отдельно в драйвере принтера, отдельно в драйвере графики, отдельно в драйвере камеры, отдельно для фотоаппарата и т.д.?

Что из перечисленного является устройствами вывода?

Может быть все-таки ЕДИНОЕ решение лучше?

Ну так это и есть единое решение.

В джаве решили так. Но в принципе...

А не приведешь ли конкретный пример системы, в которой сделано иначе?

Да в любой системе, где программисту не навязывают юникод, сейчас всё это сделано через жопу. Далеко не все системные утилиты, предназначенные для обработки текста, даже в линупсе сегодня могут обработать юникодную строку даже если с локалью у тебя всё в порядке, по умолчанию там вообще локаль не учитывается. В венде тоже всё своеобразно. Но я бы не сказал что так и должно быть.

Эх, анонимус, анонимус... Любишь ты обвинять в некомпетентности... высокооплачиваемых специалистов с 15-летним стажем, собаку съевших на кодировках и не только. Не ровен час, ко мне же и на собеседование придешь когда-нибудь. Как раз про кодировки я кандидатов люблю спрашивать.

Понял, если я приду на собеседование и передо мной окажется прыщавый юнец, не имеющий никакого представления о разработке ПО, то я буду знать с кем имею дело :)

А где это, скажи мне, в юникоде передается информация о кодировке с каждым символом? В UTF обычное арифметическое кодирование чисел, код символа занимает от 1 до 6 байт...

И ты совсем не задумывался, почему они такие длинные бывают?

anonymous
()
Ответ на: комментарий от Yampp

То, что в иксах именуется «RGB» и «RGBi», по факту совпадает с sRGB.

Тебе не кажется, что правильнее было бы сказать, что рендеринг на экран Х-ы осуществляют используя профиль sRGB по умолчанию?

В этом нетрудно убедиться, просто выведя любое sRGB-изображение без преобразования цвета.

В этом невозможно убедиться подобным образом.

То есть - преобразование будет делаться ДВА РАЗА. Один раз я преобразую из Adobe RGB в XYZ, потом драйвер из XYZ в железо. За-ме-чательно.

Оно так и делается. Программа считывает изображение в некоем формате с неким профилем в свой внутренний формат (желательно один из перечисленных, поддерживаемых системой) - тут ничего не поделаешь, придётся преобразовывать в любом случае. Потом производит преобразования изображения, ну там хотя бы масштабирование. Потом отдаёт буфер системе для отрисовки. И вовсе незачем каждой программе прикладывать профиль устройства вывода к выводимым байтам, лучше это делать в устройство-специфических частях системы, т.е. в драйверах.

Ничего, что на Core i7 каждая из этих операция для полного экрана занимает около 0.5 секунды?

Ничего не мешает аппаратно ускорить преобразование из наиболее распространённых форматов. Об этом, кстати, тоже должен знать только драйвер.

anonymous
()
Ответ на: комментарий от Yampp

Маленькая подсказка: если провести аналогию с кодировками

Кстати, раз уж в кодировках ты тоже не сильно понимаешь, я придумал для тебя ещё более простую аналогию, с которой ты наверняка встречался.

Допустим ты хочешь послать пользователю AP обычную бандероль по обычной почте.

Любой нормальный человек взял бы обычный стандартный пакет, упаковал бы в него своё вложение, снабдил бы его метаинформацией о том, куда надо доставить и по устоявшемуся интерфейсу передал бы его в почтовую систему не особо парясь о том, как именно отправление будет доставлено пользователю AP.

А то, что мы сейчас видим в линуксе, в рамках аналогии выглядит так, как если бы ты сам доставил бандероль пользовалею AP, но по пути ещё заходил бы в каждое встречное почтовое отделение оплачивая посылку. Разумеется, демон, который прибегал бы к тебе за оплатой для каждого почтового отделения сам, слегка облегчил бы твою участь избавив от необходимости забегать в почтовые отделения лично, но в целом вся система от этого не становится менее маразматичной.

anonymous
()
Ответ на: комментарий от anonymous

Ну так это и есть единое решение.

Ну да, естественно. Драйвер каждого устройства вывода должен уметь сам выводить массив пикселей

Хорошенькое единое решение. Велосипеды, связанные единой веревочкой. Продолжай.

И ты совсем не задумывался, почему они такие длинные бывают?

Первоначально 32 бита, после арифметического кодирования часть укорачивается, часть удлиняется, что за детский сад? Ясно, в арифметическом кодировании анонимус тоже не разбирается.

Yampp
() автор топика
Ответ на: комментарий от anonymous

Тебе не кажется, что правильнее было бы сказать, что рендеринг на экран Х-ы осуществляют используя профиль sRGB по умолчанию?

Нет, потому что это не так. X по умолчанию использует цветовое пространство (а анонимус не знает разницы между пространством и профилем, как я погляжу?) монитора, а большинство мониторов работают (пытаются работать) в sRGB. Вывод без конвертации равноценен выводу в sRGB.

В этом невозможно убедиться подобным образом.

Ой ли? Ты каждый день в этом убеждаешься, разглядывая сайты. Цвет показывается приблизительно верно, потому что на сайте sRGB и у твоего монитора тоже примерно sRGB.

Оно так и делается. Программа считывает изображение в некоем формате с неким профилем в свой внутренний формат

Так работают только профессиональные пакеты для работы с графикой, и то не всегда. Программы вроде веб-браузеров и игр никогда так не делают.

Ничего не мешает аппаратно ускорить преобразование из наиболее распространённых форматов.

Расскажи мне еще про набор VLIW-инструкций видеокарты и про композитинг. Нелинейные преобразования видеокарта делает даже хуже, чем процессор. У нее набор инструкций под умножение матриц заточен.

Yampp
() автор топика
Ответ на: комментарий от anonymous

А то, что мы сейчас видим в линуксе, в рамках аналогии выглядит так, как если бы ты сам доставил бандероль пользовалею

Анонимус, я понимаю, какое поведение ты пытаешься описать, и спешу разочаровать: оно существует только в твоих фантазиях. Поведение Linux совершенно иное.

Воспользуюсь твоей же аналогией.

Поведение, которое запрограммировано СЕЙЧАС: чтобы связаться с AP, я беру Адресную Книгу (colord), смотрю в ней Адрес AP (цветовой профиль), с этим адресом отправляюсь на Почту (X), беру там Коробку (цветовое пространство) удобного мне размера, пишу адрес на коробке, Оплачиваю (пропускаю через lcms2), отдаю сотруднику почты. Дальше я уверен, что посылка будет доставлена по адресу.

Поведение, которое предлагаешь ты: чтобы связаться с AP, я беру Стандартную Коробку без адреса, засовываю туда посылку (если не влезает - корежу посылку, чтобы влезла), отдаю на Почту (X), после чего надеюсь, что AP (драйвер) сам найдет посылку по ее содержимому (цветам пикселей) и сам ее оплатит. Для меня это, конечно, проще, Адресная Книга (colord) не нужна, Коробку (пространство) выбирать не надо, Оплачивать (lcms2) не надо... Это ты верно заметил, ОТПРАВКА в этом случае проще становится. Только вот ПОЛУЧЕНИЕ, к сожалению, превращается в кошмар.

Yampp
() автор топика
Последнее исправление: Yampp (всего исправлений: 3)
Ответ на: комментарий от Yampp

Добью-ка я тебя. Ты ведь у нас знаток X и того, какие цветовые пространства он поддерживает? Вот такая простая задачка - я хочу вывести всего один пиксель, я знаю цвет этого пикселя в CIE XYZ. Не подскажешь, какую функцию X API для этого надо вызвать и с какими параметрами? Go!

Yampp
() автор топика
Ответ на: комментарий от Yampp

Драйвер каждого устройства вывода должен уметь сам выводить массив пикселей

Хорошенькое единое решение. Велосипеды, связанные единой веревочкой. Продолжай.

Стандартная схема взаимодействия - программа делает свою работу, а за вывод отвечает драйвер, знающий особенности устройства. Не понимаю, что тебя так удивляет.

И ты совсем не задумывался, почему они такие длинные бывают?

Первоначально 32 бита...

И ты совсем не задумывался, почему они такие длинные?

anonymous
()
Ответ на: комментарий от anonymous

Стандартная схема взаимодействия - программа делает свою работу, а за вывод отвечает драйвер, знающий особенности устройства. Не понимаю, что тебя так удивляет.

Удивляет желание перенести на драйвер часть работы, не имеющей прямого отношения к выводу изображения (перекодировку). Удивляет желание засунуть перекодировку в каждый драйвер, хотя это легче и проще сделать в одном месте в общей библиотеке.

А еще я добавлю, что при рисовании линий и 3d цвет желательно переконвертировать на самом раннем этапе - не пикселы уже готовой линии, а цвет будущей линии. Поскольку не весь рендеринг делается аппаратно, драйвер просто стоит в цепочке слишком поздно.

И посмотри-ка повнимательнее на API X, там для тебя есть интересный сюрприз. (Ты с этим API так хорошо разогнался, что сейчас о него и шмякнешься с разбегу).

И ты совсем не задумывался, почему они такие длинные?

А чего задумываться? В одном лишь традиционном китайском 100k иероглифов, т.е. на них уже 16 бит не хватает. Ну ради арабского письма справа налево и еще для подобных вещей разбито пространство кодов на плоскости (planes) по 16 бит в плоскости, только пожалуйста плоскости с кодировками не путай, а то вижу ведь, к чему ведешь. Нет, номер плоскости нигде отдельно не кодируется, это просто старшие биты единого когда. Да, нумерация символов сплошная по всему Unicode. Нет, 32-битный код символа Unicode не содержит внутри себя номер кодировки. Нет, плоскость и кодировка - совершенно разные вещи. Весь Unicode - одна единая кодировка.

А теперь давай я про кодировки вопрос задам. Назови мне символ в первой (латинской) плоскости Unicode, который обрабатывается по-разному в зависимости от выбранного языка (ошибка, допущенная разработчиками Unicode в связи с незнанием тонкостей лингвистики некоторых стран Европы). Можешь?

Yampp
() автор топика
Ответ на: комментарий от Yampp

Сразу поясню, откуда 100k берется, пока ты в википедию не полез и не начал оттуда цифры списывать: 8k ходовых + 40k редких + 40k устаревших + альтернативные начертания. Что характерно (Восток матерится), создатели раннего Unicode не увидели разницы между японскими и китайскими иероглифами и стали их писать одним и тем же кодом, а разница есть. Тем более что в японском книжных иероглифов всего 2997 штук + хирагана + катакана, могли бы и полностью отдельно сделать. (По непроверенным слухам, разработчики Unicode имели политический заказ на ущемление языков Востока).

Yampp
() автор топика
Ответ на: комментарий от Yampp

Нет, потому что это не так. X по умолчанию использует цветовое пространство (а анонимус не знает разницы между пространством и профилем, как я погляжу?) монитора, а большинство мониторов работают (пытаются работать) в sRGB. Вывод без конвертации равноценен выводу в sRGB.

Хорошо, допустим. Даже в этом случае sRGB у нас всё равно является устройство независимым цветовым пространством, с гамутом отличным от любого подключенного к компу монитора. К тому же, в случае профмониторов, оно этот гамут ещё и ограничивает, ведь если монитор может выводить некоторые цвета, но они не представимы в sRGB - то и всё, приехали.

Ой ли? Ты каждый день в этом убеждаешься, разглядывая сайты. Цвет показывается приблизительно верно, потому что на сайте sRGB и у твоего монитора тоже примерно sRGB.

Это происходит только потому, что броузер знает, что если у джипега из интернета отсутствует встроенный профиль - то это картинка в формате sRGB. Что бы с этой картинкой потом броузер или система не делали исходя из этого предположения - пока картнка действительно sRGB она будет отображена правильно. Короче, этот пример нам ничего не говорит о том, что происходит с картинкой после считывания её программой.

Так работают только профессиональные пакеты для работы с графикой, и то не всегда. Программы вроде веб-браузеров и игр никогда так не делают.

Пусть броузеры не делают. Хочу профессиональную программу для работы с графикой. Хоть одну.

Расскажи мне еще про набор VLIW-инструкций видеокарты и про композитинг. Нелинейные преобразования видеокарта делает даже хуже, чем процессор. У нее набор инструкций под умножение матриц заточен.

Утипути, про 3D LUT почитай - чем тебе не ускоритель. А когда под ллинуксом появится первая профессиональная программа для работы с графикой - прозводители видях просто в очередь выстроятся предлагая всё более оптимизированные решения под эти задачи. Из окна придётся водой поливать дерущихся за рынок производителей графических карт.

anonymous
()
Ответ на: комментарий от Yampp

Поведение, которое запрограммировано СЕЙЧАС: чтобы связаться с AP, я беру Адресную Книгу (colord), смотрю в ней Адрес AP (цветовой профиль), с этим адресом отправляюсь на Почту (X), беру там Коробку (цветовое пространство) удобного мне размера, пишу адрес на коробке, Оплачиваю (пропускаю через lcms2), отдаю сотруднику почты. Дальше я уверен, что посылка будет доставлена по адресу.

Оплачиваю (пропускаю через lcms2)

Чего-то не очень аналогия, можно подумать у тебя система не примет байты, не проврнутые через lcms

Дальше я уверен, что посылка будет доставлена по адресу.

Или не будет. Зависит от почты. При хорошей почте получатель мог перехать, но посылка таки его всё равно найдёт. А при плохой.. А зачем нам проектировать плохую почту?

anonymous
()
Ответ на: комментарий от Yampp

Удивляет желание перенести на драйвер часть работы, не имеющей прямого отношения к выводу изображения (перекодировку). Удивляет желание засунуть перекодировку в каждый драйвер, хотя это легче и проще сделать в одном месте в общей библиотеке.

Обоснование почему так должно быть я выше уже списочком предлагал.

А чего задумываться?

В самом деле. Проще же нести чушь не думая :)

В одном лишь традиционном китайском 100k иероглифов, т.е. на них уже 16 бит не хватает.

Ну так в русском же букв меньше чем 255, а байтов на каждую букву приходится два

$ echo -n "абв" | hexdump -C
00000000  d0 b0 d0 b1 d0 b2                                 |......|

Вот и подумай - какая дополнительная информация там передаётся с каждой буквой.

anonymous
()
Ответ на: комментарий от anonymous

К тому же, в случае профмониторов, оно этот гамут ещё и ограничивает, ведь если монитор может выводить некоторые цвета, но они не представимы в sRGB - то и всё, приехали.

До жирафа дошло. Я еще на первой странице это говорил.

Пусть броузеры не делают. Хочу профессиональную программу для работы с графикой. Хоть одну.

Профессиональная программа способна преобразовать цвет сама, причем сделает это лучше, чем драйвер. Драйвер ограничен скоростью - он обязан делать преобразование быстро (а вдруг игра? а вдруг FPS?), а значит, сложные нелинейные матрицы не для него. У профессиональной программы таких ограничений нет, она делает то, что считает нужным. Тем не менее, драйвер простое преобразование делает - оно калибровкой называется. Кому не хватает, дополняют его характеризацией, медленной и довольно слабо влияющей на качество. Браузеры и игры без характеризации перетопчутся, а для профессиональной программы не проблема.

Утипути, про 3D LUT почитай - чем тебе не ускоритель.

Какого размера должна быть LUT для работы с профессиональным цветом? Если пытаться построить качественный цветовой профиль из одной лишь LUT, он легко достигнет гигабайта размером, и это не предел. Поиск по такой LUT сам по себе медленный, она в кеш не влезет. Видел структуру ICC-файла? Там всегда сначала идут грубые коррекции, и только под конец, на самом чистовом этапе - LUT. Для непрофессиональных программ применение такой LUT не требуется, она уже только самые тонкие оттенки правит.

можно подумать у тебя система не примет байты, не проврнутые через lcms

Байты цветового пространства sRGB вышеупомянутый профессиональный монитор не примет, переконвертировать в простанство монитора надо. Считаем, что дрянному монитору коррекция все равно не поможет (у него цвет от угла зрения плавает), и мыслим профессиональный монитор.

Ну так в русском же букв меньше чем 255, а байтов на каждую букву приходится два

Анонимус, ты совсем идиот? Тебе термин «арифметическое кодирование» ни о чем не говорит? Ответ: «потому что коды русских букв больше 127, и число 255 тут вообще ни при чем».

В Unicode нумерация всех символов СПЛОШНАЯ по ВСЕМ человеческим языкам, ЛЮБОЙ символ кодируется 32 БИТАМИ, например:

S = 0x00000053
z = 0x0000007A
щ = 0x00000449
∫ = 0x0000222B
猫 = 0x0000732B
Символы с кодами от 0x00001000 до 0x001FFFFF существуют, но на письме обычно не используются. Символы с кодами 0x00020000 и до 0x7FFFFFFF пока официально пустуют. Коды 0x80000000-0xFFFFFFFF зарезервированы для технических нужд (так что реально из 32 бит для кода используется 31).

Когда код символа записывается байтами, производится процедура арифметического кодирования по очень простому правилу, похожему на гамма-код Элиаса: отбрасываются ведущие нули, при кодах больше 1 байта дописывается количество единиц, равное количеству ненулевых байтов, и нолик. Начиная со второго байта, в каждый байт кладем 6 бит и в старшие биты «10». Например:

щ = 0x00000449 =
0000 0000 0000 0000  0000 0100 0100 1001
^^^^ ^^^^ ^^^^ ^^^^  ^^^^ ^ отбрасываем эти нули
Остается 100 0100 1001 (то есть 0x449). Дробим на две части:
10001--001001
Частей две, значит байтов будет два. К старшему байту дописываем две единицы и нолик:
110 ; 10001
К младшему биту дописываем 10:
10; 001001
Получилось:
11010001 10001001 = 0xD1 0x89

Проверяем:

$ echo -n "щ" | hexdump -C
00000000  d1 89
Бинго!

А теперь объясни, из какого пальца ты высосал 255 и при чем оно тут вообще. Русские буквы кодируются двумя байтами не потому, что их много, а потому, что все однобайтные коды были уже заняты другими языками (английским). Чем более редкий язык, тем больше у него коды символов, тем меньше в них ведущих нулей, которые можно отрезать. Первые 128 кодов ушли на символы ASCII, поэтому любой другой символ всегда кодируется не менее чем 2 байтами (большинство - ровно 2, но экзотика может занимать 3-4, теоретически до 6).

И ты так и не ответил на вопрос об ограничении Unicode. Повторю вопрос: какой символ с небольшим кодом в Unicode требует нестандартной обработки при написании программ, связанной с тем, что его поведение отличается в разных языках Европы?

Короче говоря, прежде чем выпендриваться, научись летать.

Yampp
() автор топика
Ответ на: комментарий от Yampp

Еще вопросик. Будучи таким знатоком Unicode, ты ведь легко посчитаешь, какой максимальной длины могли бы быть UTF-8-коды для символов, если бы мы взяли за основу не 32-битные, а 64-битные числа? Ну?

Yampp
() автор топика
Ответ на: комментарий от anonymous

Хочу профессиональную программу для работы с графикой. Хоть одну.

Неполный список программ, поддерживающих профессиональное управление цветом в Linux «из коробки»:

  • GIMP
  • Darktable
  • Krita
  • Calligra
  • Digicam
  • UFraw
  • Inkscape
  • Entangle
  • Eye of Gnome

А также Firefox и Simple Scan, которые профессиональными программами не являются, но цвет корректировать все равно умеют. А также Photoprint, который вполне профессиональный, но, к сожалению, не поддерживается больше.

Признавайся, не знал?

Yampp
() автор топика
Ответ на: комментарий от Yampp

До жирафа дошло. Я еще на первой странице это говорил.

Теперь представь мы делаем картинку, которую предполагаем выводить на несколько разных устройств с нетождественным гамутом. В каком цветовом прстранстве мы должны работать? Это должно быть пространство, в котором представимы все цвета воспроизводимые на всех целевых устройствах, желательно даже с большим количеством оттенков чем на целевых устройствах, не так ли?

Профессиональная программа способна преобразовать цвет сама, причем сделает это лучше, чем драйвер.

Лучше не сделает, с чего бы это - ведь и там и там может быть один и тот же код, значит препятствия нет. А вот хуже - да, сделает. Рассмотрим такой вариант когда у нас окно программы отображается сразу на нескольких устройствах. Ни одна ныне существующая программа не позволит тебе качественно отобразить окно и там и там. По причинам, клоторые ты сам мне и расписывал.

Драйвер ограничен скоростью - он обязан делать преобразование быстро (а вдруг игра? а вдруг FPS?), а значит, сложные нелинейные матрицы не для него.

Ну и что? В чём ты видишь непреодолимое препятствие? Ну будет программа передавать интент - драйвех будет делать характеризацию, не будет - и драйвер не будет её делать. Это просто не вдаваясь в то, что завтра массово появятся карты с аппаратной характеризацией цвета для лучшей производительности в играх.

У профессиональной программы таких ограничений нет, она делает то, что считает нужным. Тем не менее, драйвер простое преобразование делает - оно калибровкой называется. Кому не хватает, дополняют его характеризацией, медленной и довольно слабо влияющей на качество. Браузеры и игры без характеризации перетопчутся, а для профессиональной программы не проблема.

Какого размера должна быть LUT для работы с профессиональным цветом? Если пытаться построить качественный цветовой профиль из одной лишь LUT, он легко достигнет гигабайта размером, и это не предел. Поиск по такой LUT сам по себе медленный, она в кеш не влезет. Видел структуру ICC-файла? Там всегда сначала идут грубые коррекции, и только под конец, на самом чистовом этапе - LUT. Для непрофессиональных программ применение такой LUT не требуется, она уже только самые тонкие оттенки правит.

Бла-бла-бла. Я просто замер в восхищении перед таким троллингом - ты утверждал, что аппаратного ускорения управления цветом не существует, что это невозможно, и даже когда оказалось, что оно есть практически во всех видяхах страны, продолжаешь порствовать во лжи :)

Байты цветового пространства sRGB вышеупомянутый профессиональный монитор не примет

Ой, да куда он денется. Схавает всё, что в него запихают, любой мусор.

Анонимус, ты совсем идиот? Тебе термин «арифметическое кодирование» ни о чем не говорит? Ответ: «потому что коды русских букв больше 127, и число 255 тут вообще ни при чем».
В Unicode нумерация всех символов СПЛОШНАЯ по ВСЕМ человеческим языкам, ЛЮБОЙ символ кодируется 32 БИТАМИ

Раньше, в доюникодные времена, для передачи русских букв хватало одного байта. Подумай о том, какую дополнительную информацию содержит каждая русская буква в юникоде

anonymous
()
Ответ на: комментарий от Yampp

Неполный список программ, поддерживающих профессиональное управление цветом в Linux «из коробки»:

GIMP

А вот AP выше утверждал, что Гимп работает в sRGB. Что, кстати, правда. Какая же это нафиг профессиональная программа?

anonymous
()
Ответ на: комментарий от anonymous

Теперь представь мы делаем картинку, которую предполагаем выводить на несколько разных устройств с нетождественным гамутом. В каком цветовом прстранстве мы должны работать?

В цветовом пространстве исходного изобржения.

Это должно быть пространство, в котором представимы все цвета воспроизводимые на всех целевых устройствах, желательно даже с большим количеством оттенков чем на целевых устройствах, не так ли?

Нет, не так. Достаточно цветового пространства, охватывающего все оттенки изображения, которое выводится на монитор. Это может быть и меньше, чем охват даже самого плохого из устройств - смотря какая картинка. Нам не нужно иметь цветовое пространство с супер-мега-охватом, если мы не имеем цветов, которые будут изображаться.

В частности, если мы пользуемся софтом, который внутри работает в sRGB, то даже для профессионального монитора мы можем использовать sRGB. та часть охвата, которую мы при этом потеряем, все равно недоступна этому софту.

Поскольку 99% софта работает в sRGB, мы можем сделать именно sRGB цветовым пространством для непрофессиональных программ. Для профессиональных лучше всего будет дать непосредственно пространство устройства вместе с профилем этого устройства и просто не мешать им делать с цветом все, что они хотят. К сожалению, калибровку под каждую программу мы индивидуально менять не можем, а хорошо бы.

Подумай о том, какую дополнительную информацию содержит каждая русская буква в юникоде

Ты сейчас ведешь к тому, что якобы там содержится информация «о кодировке» или «о языке». Неправильно. Дополнительные биты, которые к русской букве добавляются, информации по Шеннону в себе не несут. Это исключительно издержки кодирования.

Я могу довольно легко показать, как строится кодировка, в которой будут представимы все символы Unicode, но при этом любая русская буква будет занимать 1 байт, и любая другая буква будет занимать тоже в среднем 1 байт, ценой того, что иероглифы начнут занимать по 4 байта. Достаточно всего лишь записать 32-битные коды символов кодом Левенштейна. Сам факт того, что это возможно, доказывает, что информация в UTF8-кодах - избыточна.

К примеру, в любом UTF8-коде из 2 и более байтов есть не меньше 3 бит (2n-1 для n байт), которые чисто избыточны и несут информацию лишь для восстановления испорченных UTF8-кодов. Это старшие биты «10» в каждом из байтов, начиная со второго (маркер непервого байта) и лишняя единичка в старшем бите первого байта (во избежание случайных совпадений старших битов с «10»).

Короче, не пытайся мне доказать, что в кодировках разбираешься лучше меня. Я напомню, что на два заданных тебе вопроса о кодировках ты так ничего и не ответил, из чего следует вывод, что ты просто этого не знаешь, но строишь из себя знатока. Ты собираешься на них отвечать, или засчитываем поражение?

Ну будет программа передавать интент - драйвех будет делать характеризацию, не будет - и драйвер не будет её делать.

А ничего, что программе надо бы сделать характеризацию до того, как сделан антиалиасинг, который профессиональная программа наверняка хочет сделать сама, не передавая драйверу?

Я просто замер в восхищении перед таким троллингом - ты утверждал, что аппаратного ускорения управления цветом не существует,

Не передергивай. Аппаратная калибровка существует, я это утверждал еще в самом-самом первом сообщении. Пролистай на первую страницу и убедись. Я утверждал, что не существует полного аппаратного управления цветом (калибровки и характеризации, очевидно). Если ты все тексты так по диагонали и читаешь, неудивительно, что ты не знаешь ответов даже на простые вопросы про кодировки.

Все, что реально может сделать видеокарта - это применить кривую коррекции к каждому из каналов. В самом-самом лучшем случае, быть может, матрицу. Ни о каком чистовом LUT речи не идет. Ну так гамма-кривые и так применяются (см. хотя бы исходники xiccd). И это лучшее, что можно сделать для непрофессионального софта. А для профессионального работает вот эта функция.

Ой, да куда он денется. Схавает всё, что в него запихают, любой мусор.

Ну так давай в него тогда гнать любой мусор, не? Зачем тогда вообще какая-то там цветокоррекция, не?

А вот AP выше утверждал, что Гимп работает в sRGB. Что, кстати, правда. Какая же это нафиг профессиональная программа?

Ну GIMP в sRGB работает по умолчанию, это правда. Тем не менее, там в настройках (Edit->Preferences->Color management) можно установить любое другое цветовое пространство. Выпадающий список «RGB Profile» как раз за это и отвечает. Если скачать и загрузить туда профиль для Adobe RGB, то GIMP начнет работать в Adobe RGB. Если там выбрать «None», это будет sRGB. Другое дело, что GIMP пока что частично 8-битный (часть уже переведена на длинные числа, часть еще нет), поэтому выбор слишком широкого гамута нежелателен.

Профиль монитора в GIMP может быть загружен абсолютно любой. Если поставить галочку «Try to use system monitor profile», профиль будет браться из colord/xiccd.

Yampp
() автор топика
Ответ на: комментарий от Yampp

Вот смотри еще, как цветовое пространство выбирается.

Пусть юзер не рисует сам картинок и фотографирует только на недорогую «мыльницу». Тогда все картинки в его компьютере будут в sRGB, потому что в интернете все лежит в sRGB и фотик у него тоже в sRGB работает. У этого юзера (если он не фрик) нету спектрофотометра, поэтому характеризовать монитор он не может (и вряд ли хочет). Брать чужую характеризацию - хуже, чем не брать никакой. Поэтому он пользуется только калибровкой. Это делается драйвером для всех программ, никакой поддержки на стороне программ не требуется. Все программы должны тогда быть в sRGB. Это типичная ситуация на типичном десктопе под Windows или Linux.

Пусть юзер сам создает изображения (фотографирует или рисует) и настолько озабочен вопросами цвета, что купил себе спектрофотометр или взял напрокат. Такой юзер, очевидно, рисует не для того, чтобы показать это на своем wide gamut-мониторе себе, любимому. Его конечный продукт - либо файл в интернете, либо твердая копия (фотография в рамке или тираж журнала, например), либо, гипотетически, демонстрация в большом зале на проекторе. В каком цветовом пространстве человеку работать? Очевидно, в цветовом пространстве конечного результата. Какой прок в цветах, которые никто, кроме автора, не увидит? Если конечный результат идет в Интернет, то это снова sRGB - и это тот случай, когда профессионал будет пользоваться sRGB. Ведь смотреть будут те самые юзеры, у которых кроме sRGB ничего нету - профессионалу лучше смотреть на свой результат «их глазами». С проектором неясно; скорее всего он тоже sRGB или хуже, но может быть и wide gamut. Тут профессионал возьмет цвет с запасом, например Adobe RGB, но слишком сильно за sRGB вылезать все равно поостережется - если, конечно, не знает заранее, какой именно проектор будет. Ну и, наконец, печать. При печати охват обычно бывает меньше, чем sRGB, и почти наверняка меньше, чем Adobe RGB. Поэтому те, чей конечный результат - твердая копия, чаще всего используют Adobe RGB. Более широкое пространство - это риск нарисовать детали в цветах, которые все равно не будут правильно напечатаны.

Отсюда и идут все «странные» с точки зрения простого пользователя требования к профессиональной цветопередаче. Никто из профессионалов не делает, чтобы цвета на мониторе были просто «как можно лучше», монитор используется скорее для print preview и характеризуется соответственно. Не «чтобы охват пошире», а «чтобы на принтер похоже было». Вот поэтому делать характеризацию в драйвере «для всех» ну очень-очень не стоит. Она индивидуальна для каждой задачи/программы, а по дефолту - отключена. Технически сделать у драйвера API для характеризации, конечно, можно, но этот API будет просто велосипедить API lcms2 (как, кстати, и API из <X11/Xcms.h>, который, к слову, еще и неудобен - если его вообще выкинуть, никто и не заметит; им вообще хоть кто-то пользуется?). Поэтому профессиональная программа просто дергает lcms2, причем вызовы lcms2 мешает со своими собственными действиями так, как ей удобнее. И это оказывается даже проще, потому что тогда код не дублируется в разных драйверах, а оказывается весь собран в одной lcms2. И программе проще, потому что она точно знает, что произойдет с цветом, и не будет фокусов вроде «а вот у nVidia все нормально, а у ATi криво (или наоборот)». Что в общем-то и сделано.

Yampp
() автор топика
Ответ на: комментарий от Yampp

Теперь представь мы делаем картинку, которую предполагаем выводить на несколько разных устройств с нетождественным гамутом. В каком цветовом прстранстве мы должны работать?

В цветовом пространстве исходного изобржения.

Глупость. Например у нас исходное изображение - чернобелый скан. С двумя цветами - чёрное и белое, и вовсе не RGB. Мы его масштабируем и там появились бы полутона, но если работать в исходном пространстве - получится говно. А если мы работаем с несколькими исходными изображениями в разных пространствах? Ну ты сам подумай своей никчёмной тыквою - не голится такой подход для профессиональной программы.

Это должно быть пространство, в котором представимы все цвета воспроизводимые на всех целевых устройствах, желательно даже с большим количеством оттенков чем на целевых устройствах, не так ли?

Нет, не так. Достаточно цветового пространства, охватывающего все оттенки изображения, которое выводится на монитор. Это может быть и меньше, чем охват даже самого плохого из устройств - смотря какая картинка. Нам не нужно иметь цветовое пространство с супер-мега-охватом, если мы не имеем цветов, которые будут изображаться.

На любой, усреднённый, монитор? Т.е. то же самое sRGB которое типа поддерживается всеми современными мониторами? И плевать на то, что некоторые мониторы могут лучше? А что если ты готовишь картинку для печати и вовсе не на мониторе, и вовсе не в RGB?

В частности, если мы пользуемся софтом, который внутри работает в sRGB, то даже для профессионального монитора мы можем использовать sRGB. та часть охвата, которую мы при этом потеряем, все равно недоступна этому софту.

Ога, недоступна софту, потеряем - это именно то, что надо :D

Поскольку 99% софта работает в sRGB, мы можем сделать именно sRGB цветовым пространством для непрофессиональных программ. Для профессиональных лучше всего будет дать непосредственно пространство устройства вместе с профилем этого устройства и просто не мешать им делать с цветом все, что они хотят. К сожалению, калибровку под каждую программу мы индивидуально менять не можем, а хорошо бы.

А ты не задумывался как должен выглядеть алгоритм каких-нибудь штатных функций твоего любимого фотошопа или ГИМПа чтобы работать с любым произвольным пространством?

Подумай о том, какую дополнительную информацию содержит каждая русская буква в юникоде

Ты сейчас ведешь к тому, что якобы там содержится информация «о кодировке» или «о языке».

Ты такой проницательный :D

Когда ты системе говоришь что локаль у нас, скажем KOI8 - ты ей говоришь, что сейчас будешь скармливать ей ASCII-символы и кириллицу где каждому байту соответствует определённая буква. А когда ты ты ей говоришь, что кодировка у тебя в юникоде - ты должен с каждым символом передавать к какому блоку он относится.

В случае с текстом юникод может быть оправдан, особенно учитывая безрукость таких погромистов как ты, но для изображений это пока что тяжеловатая задача выдавать интент с каждым пикселом, да и не факт что для вообще подходит - дизеринг ведь бужет производиться над группой пикселов в случае необходимости, например.

Ну будет программа передавать интент - драйвех будет делать характеризацию, не будет - и драйвер не будет её делать.

А ничего, что программе надо бы сделать характеризацию до того, как сделан антиалиасинг, который профессиональная программа наверняка хочет сделать сама, не передавая драйверу?

Ничего. Если ей надо - пусть делает сама и не просит характеризацию у драйвера. Я не очень понимаю юзкейс, но если есть такая нужда - то почему бы и нет, это вполне укладывается в предложенную схему.

anonymous
()
Ответ на: комментарий от Yampp

Я просто замер в восхищении перед таким троллингом - ты утверждал, что аппаратного ускорения управления цветом не существует,

Не передергивай. Аппаратная калибровка существует, я это утверждал еще в самом-самом первом сообщении.

Вот что ты утверждал: «Расскажи мне еще про набор VLIW-инструкций видеокарты и про композитинг. Нелинейные преобразования видеокарта делает даже хуже, чем процессор»

Как видим, он отлично делает табличные преобразования, именно то, что профиль прописал. И не видно ни одной причины, по которой туда нельзя было бы вставить любой другой функцонал.

Все, что реально может сделать видеокарта - это применить кривую коррекции к каждому из каналов.

Ага, как внезапно выяснилось :D А то, что их, видеокарт, бурное развитие внезапно остановится - это тебе Биил Гей нашептал? И что 640КВ хватит всем, да?

А для профессионального работает вот эта функция.

Хер знает про что ты несёшь чушь, но покажи мне функцию, которую нельзя реализовать аппаратно.

Ну так давай в него тогда гнать любой мусор, не? Зачем тогда вообще какая-то там цветокоррекция, не?

Ты утверждал что «Байты цветового пространства sRGB вышеупомянутый профессиональный монитор не примет». Я не утверждаю, что в монтор надо пихать всякое говно, я просто отметил, что это очередное твоё враньё.

Ну GIMP в sRGB работает по умолчанию, это правда. Тем не менее, там в настройках (Edit->Preferences->Color management) можно установить любое другое цветовое пространство.

Только в своём руководстве сам ГИМП не рекомендует это делать. И ты самостоятельно мог бы догадаться почему :D

Выпадающий список «RGB Profile» как раз за это и отвечает. Если скачать и загрузить туда профиль для Adobe RGB, то GIMP начнет работать в Adobe RGB. Если там выбрать «None», это будет sRGB. Другое дело, что GIMP пока что частично 8-битный (часть уже переведена на длинные числа, часть еще нет), поэтому выбор слишком широкого гамута нежелателен.
Профиль монитора в GIMP может быть загружен абсолютно любой.

Да ладно, давай забудем про гамут :D Объясни мне, что будет делать ГИМП если его попросить работать в пространстве anonymous.icc, таком же даже RGB, но в котором характеристическая кривая инвертирована и самому яркому цвету соответствует ноль? Лично мне кажется (не проверял), что результат применения ГИМПовских функций будет несколько неожиданным для пользователя. :D

anonymous
()
Ответ на: комментарий от Yampp

Все эти рассуждения в стиле «так сойдёт» не сделают систему лучше. Если бы Стив Джобс рассуждал так же, то он бы был обычным Биллом Гейтсом.

anonymous
()
Ответ на: комментарий от anonymous

Глупость. Например у нас исходное изображение - чернобелый скан. С двумя цветами - чёрное и белое, и вовсе не RGB.

Мимо кассы. Цветовое пространство черно-белого скана - действительные числа от 0 до 1. В оригинальной картинке есть только 0 и 1, но в цветовом пространстве существуют и серые тона, например 0.561 или 0.775. Поэтому при масштабировании в нем появятся полутона.

Я ведь специально спрашивал, в чем отличие RGB от RGBi в X. Ты не ответил. Теперь вижу, почему: разницы между цветовым пространством и представлением цветового пространства ты не знаешь. Правильный ответ: в Xcms.h под названиями RGB и RGBi фигурирует одно и то же цветовое пространство, но в первом случае оно представлено 16-битными целыми числами, масштабированными на 65535, а во втором - вещественными, масштбированными на 1.0.

но покажи мне функцию, которую нельзя реализовать аппаратно.

Дельта-функция Дирака. Съел?

«Аппаратно» обычно означает «там где-то есть еще один процессор, который запрограммирован на заводе». Исключения есть: например, применение кривых в CRTC (там обычная ОЗУшка стоит, массив изображает), регулировка громкости в некоторых звуковых картах (там резисторы переключаются) и т.д. А вот всякие «аппаратные» реализации криптографии, сжатия видео, 3D и прочего - это уже процессоры, зачастую запрограммированные на заводе. И они не волшебные. В лучшем случае они VLIW, как в видеокарте, но могут быть и обычными RISC.

А когда ты ты ей говоришь, что кодировка у тебя в юникоде - ты должен с каждым символом передавать к какому блоку он относится.

Я тебе уже кажется говорил, что блок и кодировка - это совершенно разные вещи. Ну ты как обычно прослушал и протроллил. Блоки нужны не для того, чтобы разные языки кодировать. Блоки - они для того, чтобы, например, направление письма менять - например, в тексте на арабском с отдельными словами на английском, как часто бывает у арабов.

Я могу тебе на спор построить представление Unicode, в котором все буквы европейских языков без диакритики (латинский, русский, греческий) будут кодироваться ровно 1 байтом, японские иероглифы и арабский - ровно 3 байтами, а любой произвольный Unicode-символ - 5 байтами. Я не буду в этом представлении указывать плоскость символов.

особенно учитывая безрукость таких погромистов как ты

Но вот после этого заявления я готов спорить исключительно на деньги, потому что ты даже не знаешь, что именно я писал и каких оно масштабов. Подсказываю: объем обработанной без ошибок информации уже перевалил за несколько петабайт. Я сомневаюсь, что тебя хотя бы близко подпускали к таким системам. Хочешь посостязаться в программировании - пожалуйста. Опять же, на деньги и с независимым арбитром. Бодаться на форуме я не собираюсь.

Вот что ты утверждал: «Расскажи мне еще про набор VLIW-инструкций видеокарты и про композитинг. Нелинейные преобразования видеокарта делает даже хуже, чем процессор»

Тролль даже не потрудился переспросить, не поняв фразу. Объясняю. Процессор видеокарты в калибровке не участвует. В каждой видеокарте на каждом из CRTC есть специальная штука, которая применяет кривые калибровки. Это то, куда я через XRandR калибровку гружу. Матрицы она применять не умеет. Процессор видеокарты может применить линейную матрицу, но на применение нелинейного набора матриц у него кишка тонка. Поэтому нелинейные преобразования (не те простые кривые, которые в CRTC) делают на процессоре или не делают совсем.

Как видим, он отлично делает табличные преобразования, именно то, что профиль прописал.

Разбежался. Табличные преобразования - это (RGB)->(RGB), а не R->R, G->G, B->B. То есть когда любой цвет можно переделать в любой, например к красному добавить синего, если красный слишком желтит. CRTC умеет только простые кривые применять (да, по таблице), но ни в коем случае не смешивает цвета. Для этого существует термин «кривые» (да, кривые обычно применяют тоже через LUT, но они от этого не становятся полноценной универсальной LUT), применять термин «табличные преобразования» неправомерно.

Объясни мне, что будет делать ГИМП если его попросить работать в пространстве anonymous.icc, таком же даже RGB, но в котором характеристическая кривая инвертирована и самому яркому цвету соответствует ноль?

Он отработает «правильно» в том смысле, что на выходе самому яркому цвету будет соответствовать ноль. Функции GIMP, которые уже переведены на GEGL, отработают абсолютно правильно (яркость они будут смотреть с учетом кривых профиля). Среди сторонних плагинов и среди функций, которые еще не переведены на GEGL, в принципе может что-нибудь глюкануть (короче, на GEGL все давно уже переводить надо). Большинство функций, даже старых, даже в таких извращенных ситуациях отработают корректно, потому что они просто копируют или даже смешивают цвета, не придавая значения конкретным цифрам.

Разумеется, можно сделать «плохой» ICC, в котором ни одна программа не будет правильно работать. Это совершенно не проблема. Можно сделать, например, ICC для цветового пространства, в котором есть только черный цвет и чуть-чуть близких к черному оттенков. Не запрещается. Кто это себе загрузит, тот ССЗБ.

Yampp
() автор топика
Ответ на: комментарий от Yampp

Я еще раз спрашиваю

Ты собираешься на заданные тебе вопросы о кодировках отвечать? Или засчитываем поражение и пустобрехство?

Yampp
() автор топика
Ответ на: Я еще раз спрашиваю от Yampp

Когда ты системе говоришь что локаль у нас, скажем KOI8 - ты ей говоришь, что сейчас будешь скармливать ей ASCII-символы и кириллицу где каждому байту соответствует определённая буква.

До изобретения Unicode система не знала, какая буква соответствует какому коду. Она даже не знала, что KOI-8 является кириллицей. В систему грузили шрифт, в котором каждому коду соответствовала какая-то картинка буквы, и именно шрифт определял, какие буквы на экране будут появляться. Отсюда и пошел термин «кодировка» - одни и те же коды могли означать совершенно разные символы, причем не всегда и не во всех системах программа могла узнать, какие. Например, в DOS шрифт тупо грузился в аппаратный знакогенератор, программы не знали, что там в знакогенераторе. Ошибки приводили к «кракозябрам».

В современном мире за стандарт приняты номера символов по Unicode, и любая кодировка задается таблицей из номеров своих символов. Третий вопросик по Unicode подкинуть?

Если бы Стив Джобс рассуждал так же, то он бы был обычным Биллом Гейтсом.

Ой, а Стив Джобс с анонимусом не проконсультировался, и теперь в MacOS используется система управления цветом ColorSync, структура и принцип действия котрой совершенно такие же, как в линуксовом colord. Как жаль, правда?

Yampp
() автор топика
Ответ на: комментарий от Yampp

Мву-ха-ха-ха-ха!

Внезапно из документации Apple:

Color from one device-dependent color space, such as a display, is translated to a device-independent color space, such as sRGB, and then translated to another device-dependent color space, such as a printer.

Да, в Apple определенно забыли проконсультироваться с анонимусом.

А то, что их, видеокарт, бурное развитие внезапно остановится

А кто говорил, что оно остановится? Они просто развиваются в другую сторону. Цветовая характеризация - это такой маленький рынок, что закладывать ее в архитектуру видеокарт ни один производитель специально не будет. Нужные возможности когда-нибудь скорее всего появятся, просто потому что они для некоторых работ с текстурами тоже полезны, но это произойдет не завтра и даже не через полгода. Ибо для 3d и фильмов поважнее вещи есть. А цвет нам сейчас нужен.

Это как с CUDA. Еще в конце 90-х понятно было, что видеокарты могут вычисления делать, но поддержка появилась спустя почти 10 лет - в 2007-м. Я не собираюсь ждать 10 лет, пока производители соизволят включить в видеокарты поддержку тонкой цветокоррекции.

Yampp
() автор топика
Ответ на: комментарий от Yampp

Мимо кассы. Цветовое пространство черно-белого скана - действительные числа от 0 до 1. В оригинальной картинке есть только 0 и 1, но в цветовом пространстве существуют и серые тона, например 0.561 или 0.775. Поэтому при масштабировании в нем появятся полутона.

Не присутствуют и не появятся - напомню, что мы сейчас говорим о твоём утверждениичто мы должны работать в цветовом пространстве исходного изображения. Вот если изображение перевести в цветовое пространство, в котором полутона существуют - вот тогда у них будет шанс появиться. Но это уже будет в другом цветовом пространстве, а не в цветовом пространстве исходного изображения.

Я ведь специально спрашивал, в чем отличие RGB от RGBi в X. Ты не ответил. Теперь вижу, почему: разницы между цветовым пространством и представлением цветового пространства ты не знаешь. Правильный ответ: в Xcms.h под названиями RGB и RGBi фигурирует одно и то же цветовое пространство, но в первом случае оно представлено 16-битными целыми числами, масштабированными на 65535, а во втором - вещественными, масштбированными на 1.0.

Ты просто туп как пробка. Какое отношение написанное тобой имеет отношение к обсуждаемому вопросу? Мне кажется ты просто не владеешь темой - вот и брякаешь что попало без разбору.

но покажи мне функцию, которую нельзя реализовать аппаратно.

Дельта-функция Дирака. Съел?

Там и реализовывать-то нечего, при чём реализация может быть любой разрядности, от однобитовой (инвертор) до возвращалки нуля при параметре !+ нулю или +Infinity в формате хоть 128-битного числа с плавающей запятой при подаче нуля на вход.

«Аппаратно» обычно означает «там где-то есть еще один процессор, который запрограммирован на заводе»...
процессоры, зачастую запрограммированные на заводе. И они не волшебные.

Аппаратная реализация той или иной функции означает тлько то, что у тебя есть железяка, которая умеет реализовывать эту функцию. Что там внутри стоит нас никоим образом тут не интересует (ты всё равно не имеешь об этом никакого представления), важно лишь для чего прибегают к подобным решениям.

Я тебе уже кажется говорил, что блок и кодировка - это совершенно разные вещи. Ну ты как обычно прослушал и протроллил. Блоки нужны не для того, чтобы разные языки кодировать. Блоки - они для того, чтобы, например, направление письма менять - например, в тексте на арабском с отдельными словами на английском, как часто бывает у арабов.

Ты ещё более туп, чем это казалось изначально. Юникод даёт тебе возможность смешивать разные языки в одном тексте поэтому информация о языковой принадлежности символа должна передаваться вместе с символом в то время как в доюникодную эру язык для всех букв текста задавался для всего теста сразу. И «блок» в юникоде - именно что аналог кодовой страницы, пусть и со своим блекджеком.

Я могу тебе на спор построить представление Unicode, в котором все буквы европейских языков без диакритики (латинский, русский, греческий) будут кодироваться ровно 1 байтом, японские иероглифы и арабский - ровно 3 байтами, а любой произвольный Unicode-символ - 5 байтами. Я не буду в этом представлении указывать плоскость символов.

Ну и что?

особенно учитывая безрукость таких погромистов как ты

Но вот после этого заявления я готов спорить исключительно на деньги, потому что ты даже не знаешь, что именно я писал и каких оно масштабов.

Это, несомненно, очень важно для всех нас :D

anonymous
()
Ответ на: комментарий от Yampp

Тролль даже не потрудился переспросить, не поняв фразу. Объясняю. Процессор видеокарты в калибровке не участвует. В каждой видеокарте на каждом из CRTC есть специальная штука, которая применяет кривые калибровки. Это то, куда я через XRandR калибровку гружу. Матрицы она применять не умеет. Процессор видеокарты может применить линейную матрицу, но на применение нелинейного набора матриц у него кишка тонка. Поэтому нелинейные преобразования (не те простые кривые, которые в CRTC) делают на процессоре или не делают совсем.

Ты утверждал, что аппаратное ускорение невозможно, при этом налил какой-то бессмыссленной словесной воды. Когда тебя ткнули носом в то, что аппаратное ускорение уже повсеместно реализовано в чуть ли не каждой видяхи - ты снова напрудил целую лужу блаблаблы. Теперь, когда над тобой по этому поводу посмеялись - ты снова льёшь эту бессмысленную блаблаблу. Чего ты этим хочешь добиться кроме того, что окружающие станут воспринимать тебя как полного кретина?

Как видим, он отлично делает табличные преобразования, именно то, что профиль прописал.

Разбежался. Табличные преобразования - это (RGB)->(RGB), а не R->R, G->G, B->B.

Только в твоей голове. Во вторых существует ещё и 3D LUT, про который, ты наверное, не слышал.

не смешивает цвета. Для этого существует термин «кривые»

Ты даже не знаешь для чего существют термины?

Объясни мне, что будет делать ГИМП если его попросить работать в пространстве anonymous.icc, таком же даже RGB, но в котором характеристическая кривая инвертирована и самому яркому цвету соответствует ноль?

Он отработает «правильно» в том смысле, что на выходе самому яркому цвету будет соответствовать ноль. Функции GIMP, которые уже переведены на GEGL, отработают абсолютно правильно (яркость они будут смотреть с учетом кривых профиля).

Разве кто-то ещё верит в GEGL в ГИМПе после эпохального патча 2.8.2 в котором самым важным улучшением было «Remove all 'Use GEGL' menu items, they only add bugs and zero function» :D

Как бы то ни было, возвращаемся к проблеме. Судя по «яркость они будут смотреть с учетом кривых профиля» ты вообще не врубаешься в чём проблема. Ведь тот факт, что «программы будут смотреть что-то с учетом кривых профиля» означает, что программы работают в другом цветовом пространстве, а это противоречит документации ГИМПа и заверениям жирного тролля AP. Так что ты, скорее всего, слишком оптимистично оцениваешь возможности ГИМПа.

Среди сторонних плагинов и среди функций, которые еще не переведены на GEGL, в принципе может что-нибудь глюкануть (короче, на GEGL все давно уже переводить надо). Большинство функций, даже старых, даже в таких извращенных ситуациях отработают корректно, потому что они просто копируют или даже смешивают цвета, не придавая значения конкретным цифрам.

Они в любой ситуации отработают корректно.. Для заданного цветового пространства %) Скажем, мы усредняем пару соседних пикселов с оттенком зелёного. Ну да, в цветовом пространстве картинки цвет, находящийся посередь этих оттенков соответствует... ну, скажем малиновому. Ну такое уж у нас цветовое пространство. Т.е. отработает-то оно корректно, только вот результат будет неожиданный.

Поэтому работать программа должна в своём заведомо определённом пространстве, а преобразования осуществлять при чтении данных и их выводе. Мне странно видеть, что такие простые вещи могут быть для кого-то неочевидными.

anonymous
()
Ответ на: Мву-ха-ха-ха-ха! от Yampp

Color from one device-dependent color space, such as a display, is translated to a device-independent color space, such as sRGB, and then translated to another device-dependent color space, such as a printer.

Да, в Apple определенно забыли проконсультироваться с анонимусом.

Тот факт, что они независимо пришли к таким же выводам как и Анонимус выше по треду, только подтверждает слова анонимуса: " sRGB у нас всё равно является устройство независимым цветовым пространством, с гамутом отличным от любого подключенного к компу монитора"

А кто говорил, что оно остановится? Они просто развиваются в другую сторону. Цветовая характеризация - это такой маленький рынок, что закладывать ее в архитектуру видеокарт ни один производитель специально не будет.

Ну так рынок маленький почему? Потому, что всякие пидорасы предпочитают увешивать систему гроздьями велосипедов вместо того чтобы просто переместить функции управления цветов в устройство и его драйвер.

Я не собираюсь ждать 10 лет, пока производители соизволят включить в видеокарты поддержку тонкой цветокоррекции.

А зачем этого ждать? Можно же пока софтово всё реализовать - ведь уже существет ряд проблем, требующих решения. В частности - принципиальная невозможность характеризованного вывода сразу на два одновременно подключенных устройства. Иногда лучше медленно, чем никак в принципе.

anonymous
()
Ответ на: комментарий от anonymous

Тот факт, что они независимо пришли к таким же выводам как и Анонимус выше по треду

Хорош врать. Я весь тред тебе эти выводы в башку пытался вдолбить. А теперь они, оказывается, уже «твои» стали. Вот в этом сообщении ты писал:

В стандарте жёстко задано RGB? Ты больной?

А теперь, оказывается, Анонимус «независимо от Apple» «пришел к выводу», что стандарт - это sRGB.

Ты будешь очень удивлен, но у Apple стандартного цветового пространства, единого для всей системы, нету. В качестве «независимого» может быть использовано любое подходящее цветовое пространство, например sRGB, но это всегда остается на усмотрение приложения. При этом работа с устройством ведется в цветовом пространстве устройства. В точности то решение, которое анонимус весь тред поливал дерьмом.

Ну так рынок маленький почему? Потому, что всякие пидорасы...

... не покупают себе калибраторы за $500, не калибруют ими свою технику и не строят правильные цветовые профили.

Во вторых существует ещё и 3D LUT, про который, ты наверное, не слышал.

Во-первых, для того, чтобы придумать такую тривиальную вещь, как 3D LUT, вовсе не надо о ней слышать. Технике построения таких таблиц для любых задач обучен любой программист. Если ты не встречал этот прием нигде, кроме как в цветокоррекции - очень жаль, но в программировании тебе делать нечего.

Во-вторых, а давай размер этого 3D LUT для худшего случая посчитаем. Пусть у нас 16 бит на цвет. Тогда в худшем случае (когда необходима запись в LUT для каждого значения цвета) размер LUT будет 3*16*(2^16)^3 = 13510798882111488 бит, то есть 1536 терабайт. Реальная 3D LUT для 16 бит гораздо меньше, но все равно легко достигает гигабайтов. Ну ладно, пусть будет лишь 8-битный цвет. Тогда получается 48 мегабайт в худшем случае. Это все равно не лезет в кеш.

Поэтому одной 3D LUT не обойдешься. Поэтому LUT применяют всегда в комбинации с другими методами, чтобы избежать гигантских ее размеров.

В частности - принципиальная невозможность характеризованного вывода сразу на два одновременно подключенных устройства.

Зависит от того, куда они подключены. Если на один и тот же CRTC видеокарты (это от программиста не зависит, это зависит от наличия в видеокарте возможности подключить тот или иной CRTC к тому или иному выходу, и обычно выходов больше, чем CRTC), тогда это то же самое, как если два монитора посадить на один кабель через разветвитель. Тогда хоть тресни, но ничего софтом не сделаешь. Сигнал физически один и тот же. То же самое, если CRTC разные, но физический фреймбуфер один (уже не так стремно, калибровку можно разную сделать). Это те случаи, когда драйвер выводит картинку один раз, но попадает она на два экрана.

Если два разных устройства подключены на разные CRTC и на разные фреймбуферы, так никаких проблем тогда и нету. У меня как раз такая конфигурация, и она замечательно работает - с характеризацией раздельно на обоих мониторах.

Когда тебя ткнули носом в то, что аппаратное ускорение уже повсеместно реализовано в чуть ли не каждой видяхи - ты снова напрудил целую лужу блаблаблы.

Меня не устраивает схоластика под видом «тыканья носом». Это блаблабла в квадрате. Если хочешь ткнуть носом - напиши proof of concept code. Покажи, какой именно код должен быть написан на Си, чтобы применить 3D LUT аппаратно ко всему выводу всех приложений, раз уж утверждаешь, что это возможно.

Там и реализовывать-то нечего, при чём реализация может быть любой разрядности, от однобитовой (инвертор) до возвращалки нуля при параметре !+ нулю или +Infinity в формате хоть 128-битного числа с плавающей запятой при подаче нуля на вход.

Это не будет правильная дельта-функция Дирака. По той простой причине, что хоть 128 бит с плавающей запятой бери, хоть 1280 бит - все равно множество любых чисел с плавающей запятой конечно, а значит, не может быть всюду плотным. Обобщенные функции вроде дельты вообще в принципе не могут быть представлены численно, хоть программно, хоть аппаратно. Компьютер с ними может только в символьных вычислениях работать. (Ну да, я сжульничал - назвал функцию, которую вообще вычислить саму по себе невозможно, можно вычислить только выражение, в котором дельта фигурирует как его часть, но ты ведь просил просто какую-то функцию, верно?)

Yampp
() автор топика
Ответ на: комментарий от Yampp

В общем так.

Я оскорбления в этом треде терпеть не намерен и от вранья и схоластики устал. Если ты все еще считаешь себя правым, можешь мне это попытаться доказать на очной ставке при свидетелях. Мой e-mail найдешь в исходниках xiccd. Спорить будем на Си: сказал «можно» - покажи как, сказал «нельзя» - я покажу, как можно. Не хочешь - как хочешь, я в принципе уже понял, что ты не профессиональный программист, а просто еще один воинствующий дилетант, и в дополнительных доказательствах этого не нуждаюсь.

Так или иначе, своей цели я достиг. Я заставил тебя как минимум прочитать про цветовые пространства, LUT, охваты, узнать о существовании sRGB. Уже хорошо. Жаль только, что ты про scRGB не слышал (знаю, что не слышал, а то бы уже давно им троллил, ну не может тролль пройти мимо такого вкусного цветового пространства), ну да и это поправимо. Наверняка ведь сейчас побежишь читать, что в этом scRGB такого особенного - ну и славненько, еще одним фактом в твоей башке больше станет. Так, глядишь, и всю теорию изучишь.

На оба вопроса про кодировки ты отвечать отказался, я не забыл. Значит, кодировок ты не знаешь. Ну так хоть про плоскости Unicode прочитал, уже неплохо. Осталось понять, почему их неправомерно сравнивать с однобайтовыми кодировками, ну да это дело наживное. Ну тут я сразу подскажу: даже первая плоскость, которая латинская - уже она в разных языках по-разному себя ведет (в каких? когда?), а в «старых» кодировках такого поведения не бывает.

Yampp
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.