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

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

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

Вот в этом сообщении ты писал:В стандарте жёстко задано RGB? Ты больной?

Ну да, мне и до сих пор кажется что ты больной - ты же там рассждал про цвета, которыми осуществляется вывод. Только полный идиот может подумать, что какой-нибудь стандарт обозначения цвета пикселей типа HTML-ного RGB-триплета вида 0xFF0000 обязывает устройство вывода использовать именно красный, синий и зелёный для синтеза требуемого цвета. Иди перечитай о чём там шла речь

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

Стандарт чего, можно поинтересоваться? :D

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

Ты выше уже писал про ColorSync. Раз тема Эппла так важна для тебя, я поясню почему я её игнорирую: я не знаю как это реализовано в маках, а на слово тебе верить не могу потому, что ты врёшь как дышишь - как видно из этого треда. Поэтому поступим так. Ты приводишь того, как именно реализовано то, на что ты ссылаешься и поясняешь какое отношение этот аргумент имеет к обсуждаемому вопросу - например, может быть все должны реализовывать такое же управление цветом как у Эппл и на этом основании твой пример является аргументом против того, чтобы преобразования, специфичные для конкрентного устройства делались в драйвере ус-ва. Правда из того, что ты понаписал, невозможно понять кто в маках делает это преобразование - прикладные программы или система, так что может ты опять по глупости чего недопонял :D

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

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

Спорить будем на Си

А почему именно на Си, кстати?

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

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

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

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

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

Главное, что применяют.

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

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

Так ты это, расскажи как оно работает, об этом же и речь в этом треде, а ты как-то вскользь упомянул. Это в твоём фотошопе, который ты упоминал, так можно или ГИМП под Линуксом тоже умеет выводить картинку одновременно на N устройств с особой характеризацией для каждого из них?

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

Меня не устраивает схоластика под видом «тыканья носом». Это блаблабла в квадрате. Если хочешь ткнуть носом - напиши proof of concept code.

Бу-га-га. Какой POC, когда оно повсюду широко применяется :D

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

Анонимусу больше заняться по-твоему нечем чем бегать там «показывать» что-то? Ты говоришь аппаратного ускорения нет - тебя тыкают носом в то, что оно есть повсюду - вполне достаточное доказательства твоего вранья. Если ты можешь доказать что то, чем все пользуются невозможно - авэк плезир, «показывай» или доказывай что считаешь нужным, может даже тебе удастся обмануть кого-нибудь из доверчивых пользователей ЛОРа :D

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

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

Я все сказал. Либо отвечаешь на мои вопросы и демонстрируешь proof-of-concept-код, либо отправляешься в задницу. Не нравится архитектура в Linux - сделай свою, система открытая, любые нововведения могут стать ее частью, если докажут свою состоятельность. Не нравится Linux - пользуйся Apple, но имей в виду, что архитектура colord как раз с Apple и слизана один в один. Не нравится Си - можешь писать на любом другом языке, только чтобы работало шустро и к железу обращаться могло.

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

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

Какой POC, когда оно повсюду широко применяется :D

Ссылку на исходник. Желательно с конкретной строчкой. Слово «повсюду» не является доказательством.

Мне бы хотелось вернуть тебя в русло темы.

В частности на первной странице ты написал: «мы НЕ ВСЕГДА можем вывести картинку правильно на ВСЕХ устройствах»

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

У меня вопрос: когда ты врал - тогда или сейчас?

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

Логика к тебе в башку ни разу не заходила.. Признайся, ты специально упарываешься перед тем как постить на ЛОРе или ты просто всегда упоротый?

Какой POC, когда оно повсюду широко применяется :D

Ссылку на исходник. Желательно с конкретной строчкой. Слово «повсюду» не является доказательством.

Прекращай заявляться на ЛОР упоротым. Об этом для таких как ты даже в Википедии написано: «Modern graphics cards have direct support for 3D LUTs, allowing entire HD images to be processed at 60 fps or faster.»

Modern graphics cards have direct support for 3D LUTs, allowing entire HD images to be processed at 60 fps or faster.

С КАКОЙ ТОЧНОСТЬЮ? Вот с такой?

The 3D lookup texture has 64 points in each dimension, using 16 bit integers.

Сами свои мониторы так характеризуйте. Смешная шутка.

У меня вопрос: когда ты врал - тогда или сейчас?

Так. Ну что, анонимуса еще и формальной логике учить надо? Берем утверждение:

мы НЕ ВСЕГДА можем вывести картинку правильно на ВСЕХ устройствах

Из логики известно, что «не всегда можем» означает «не всегда, но иногда можем».

У меня как раз такая конфигурация,

Как раз это «ИНОГДА» и есть. ПРОТИВОРЕЧИЯ НЕТ НИКАКОГО! Случаи, когда не можем, я тоже перечислил.

Короче, то, что ты сейчас делаешь - это уже совсем тупой троллинг. Пошел в жопу, тролль.

Пошел в жопу, тролль.

Зачем тебе в жопе тролль?

Из логики известно, что «не всегда можем» означает «не всегда, но иногда можем».

Давай, расскажи нам лучше, как это у тебя ГИМП одновременно характеризацию для двух разных мониторов умудряется делать.

как это у тебя ГИМП одновременно характеризацию для двух разных мониторов умудряется делать.

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

Не хочешь в жопу - можешь идти в баню. Мне все равно. Если тебе не нравится, как мы что-то делаем - ну так покажи пример. У тебя калибратор-то есть? Профили чем строить будешь? Что такое «дельта-E», знаешь? Вперед и с песней. Исходники все открытые, бери, исправляй, коммить. Мы практики, нам теоретизирующие анонимусы не нужны. Хочешь сделать линукс лучше - присылай патчи. Хочешь потроллить - это не к нам.

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

Ну вот видишь, что и требовалось доказать - не работает и работать в текущей архитектуре не может.

не работает и работать в текущей архитектуре не может.

Может (могу написать POC). Да, прямо сейчас это не очень удобно, но возможно. Когда наконец будет решен вопрос о введении управления цветом в API Cairo, будет сделан удобный API.

Если интересно, то планы на будущее такие. Во-первых, что мы все про мониторы да про мониторы? Основной потребитель цветокоррекции - это все же принтеры. С точки зрения программ там API хороший и красивый, а вот внутри драйверов там силами Apple (это они сейчас владеют CUPS) получился треш и угар. Они поддержку своего ColorSync добавили так лихо, что всем остальным пришлось ставить костыли (в частности, при печати tiff с командной строки применение ICC вообще не происходит). Эту часть я в ближайшее время переделаю. Потом надо будет сделать, чтобы gutenprint на струйниках калибровался (не характеризовался!) через ICC, а не через свой собственный формат XML. А то на неоригинальных чернилах с СНПЧ совсем грустно все. Работать-то работает, но слишком много странных манипуляций с argyll и текстовым редактором требуется.

Во-вторых. Базовую калибровку через 3d LUT для мониторов я давно собираюсь сделать. Но характеризацию она полностью заменить не сможет. Эта задача у меня в низком приоритете, потому что польза сомнительна: хороший монитор (по крайней мере мой) и без 3d LUT на одной лишь калибровке кривыми дает неплохую DeltaE, а плохой монитор все равно не спасти. (Более того, известно, что на плохом мониторе LUT любого разумного размера хуже, чем просто кривые+матрица). Но рано или поздно сделаю обязательно. Здесь главная сложность - чтобы случайно не применить одну и ту же матрицу дважды, если вдруг какая-то старая программа не в курсе, что матрица уже применена. Сейчас внимательно исследую поведение всех подозрительных программ.

В-третьих. Хотя системное цветовое пространство по умолчанию задает админ (точно так же, как и кодировку), в будущем разумнее всего использовать scRGB, и я буду голосовать именно за scRGB. Прямо сейчас - рано, все-таки на пиксель 12 байт вместо 3 байт при современных разрешениях мониторов - это не шуточки. Как только можно будет точно сказать, что 4-кратное увеличение размера фреймбуферов не создаст тормоза у 50% юзеров, умолчания можно будет сменить. Технически это совершенно не проблема. Но прямо сейчас 4-кратного роста юзеры не простят.

Если что: «хороший и красивый API» - это: «рисуй в любом пространстве, в каком тебе удобно, просто укажи профиль этого пространства». При этом для любого устройства доступно и непосредственно пространство устройства, причем всегда известен и профиль устройства. Все профили всех устройств всех типов доступны через единый API. Через тот же API можно делать любую конвертацию (доступны два уровня API - «простой» и «полный»).

Больше можешь сюда не писать. Я больше не собираюсь читать этот тред и твоих ответов уже не увижу. Если есть, что сказать по делу - welcome на рассылку colord. Патчи и pull request отсылай туда же.

Может (могу написать POC). Да, прямо сейчас это не очень удобно, но возможно. Когда наконец будет решен вопрос о введении управления цветом в API Cairo, будет сделан удобный API.

Если что: «хороший и красивый API» - это: «рисуй в любом пространстве, в каком тебе удобно, просто укажи профиль этого пространства». При этом для любого устройства доступно и непосредственно пространство устройства, причем всегда известен и профиль устройства. Все профили всех устройств всех типов доступны через единый API. Через тот же API можно делать любую конвертацию (доступны два уровня API - «простой» и «полный»)

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

Если интересно, то планы на будущее такие. Во-первых, что мы все про мониторы да про мониторы? Основной потребитель цветокоррекции - это все же принтеры.

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

С точки зрения программ там API хороший и красивый, а вот внутри драйверов там силами Apple (это они сейчас владеют CUPS) получился треш и угар. Они поддержку своего ColorSync добавили так лихо, что всем остальным пришлось ставить костыли (в частности, при печати tiff с командной строки применение ICC вообще не происходит). Эту часть я в ближайшее время переделаю. Потом надо будет сделать, чтобы gutenprint на струйниках калибровался (не характеризовался!) через ICC, а не через свой собственный формат XML. А то на неоригинальных чернилах с СНПЧ совсем грустно все. Работать-то работает, но слишком много странных манипуляций с argyll и текстовым редактором требуется.

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

Часть вторая

Во-вторых. Базовую калибровку через 3d LUT для мониторов я давно собираюсь сделать. Но характеризацию она полностью заменить не сможет. Эта задача у меня в низком приоритете, потому что польза сомнительна: хороший монитор (по крайней мере мой) и без 3d LUT на одной лишь калибровке кривыми дает неплохую DeltaE, а плохой монитор все равно не спасти. (Более того, известно, что на плохом мониторе LUT любого разумного размера хуже, чем просто кривые+матрица). Но рано или поздно сделаю обязательно. Здесь главная сложность - чтобы случайно не применить одну и ту же матрицу дважды, если вдруг какая-то старая программа не в курсе, что матрица уже применена. Сейчас внимательно исследую поведение всех подозрительных программ.

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

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

В-третьих. Хотя системное цветовое пространство по умолчанию задает админ (точно так же, как и кодировку), в будущем разумнее всего использовать scRGB, и я буду голосовать именно за scRGB. Прямо сейчас - рано, все-таки на пиксель 12 байт вместо 3 байт при современных разрешениях мониторов - это не шуточки. Как только можно будет точно сказать, что 4-кратное увеличение размера фреймбуферов не создаст тормоза у 50% юзеров, умолчания можно будет сменить. Технически это совершенно не проблема. Но прямо сейчас 4-кратного роста юзеры не простят.

Не, ты не понимаешь. Совершенно не обязательно вводить некое системное пространство. Нужно лишь принимать от программ изображение в устройствонезависимом формате, пусть это будет общепринятый sRGB - не важно. Важно что система должа иметь возможность также принять данные в каком-либо суперформате и вывести на каждое устройство это изображение в наилучшем возможном качестве. Форматы можно со временем добавлять, в этом нет проблемы. Проблема только в том, что программа не должна быть отвественна за вывод картинки на конкретное устройство, ведь это должно решаться драйвером - как выводить конкретный битмап на конкретное устройство будь то принтер или монитор с каким-нибудь невероятным колорспейсом.

Больше можешь сюда не писать. Я больше не собираюсь читать этот тред и твоих ответов уже не увижу. Если есть, что сказать по делу - welcome на рассылку colord. Патчи и pull request отсылай туда же.

Это твои проблемы. Я в поттерингодемоновых рассылках не участвую и не планирую. Да и ЛОР просматриваю весьма поверхностно, так что то, что я случайно наткнулся на этот тред - вообще-то невероятное стечение обстоятельств: та популярность которой пользуются здесь треды об управлении цветом после изгона адекватов с этого форума практически гарантирует, что подобная тема останется незамеченной на трекере.

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

Подытожим

Я больше не собираюсь читать этот тред и твоих ответов уже не увижу. Если есть, что сказать по делу - welcome на рассылку colord.

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

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

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

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

С другой стороны, у разработчиков присутствует понимание что программа для редактирования изображений, работающая в sRGB, как выше писал про ГИМП AP - в наши дни ничего кроме смеха вызывать не может. Хотя я так и не понял, где именно Yampp собирается «голосовать именно за scRGB» - надеюсь не в стаде разработчиков colord, которого это вообще не должно касаться.