|
|
Untitled.png (8,019 bytes) |
|
|
RGB цвет работает или в Windows 10 со включенной опцией Use Virtual Terminal for rendering в настройках интерфейса Far, или в Conemu с любой ОС и независимо от опции. Если эти условия не выполнены, то доступно только 16 стандартных цветов. Любой RGB цвет будет корректно сохранен, но аппроксимирован к ближайшему из 16 стандартных при выводе на экран. |
|
|
Аргумент об ограничении на 16 цветов понятен и принят. Однако неясно, почему тогда при ручном вводе значения 808080, которое соответствует стандартному тёмно-серому цвету, ФАР не отображает этот стандартный цвет, а вместо него сбивается на ярко-белый. При этом при выборе того же стандарного цвета из палитры он отображается корректно как тёмно-серый и в поле RGB прописывается его корректное значение 808080. То есть помимо закономерного ограничения на 16 стандартных цветов всё же где-то присутствует ошибка интерпретации значений поля ввода значений цветов, ибо одно и то же значение 808080 (соответствующее одному из 16 стандартных цветов) приводит к двум совершенно разным поведениям в зависимости оттого, выбрали ли мы цвет через палитру или же ввели в поле RGB. Untitled-2.png (22,076 bytes) |
|
|
Внутри Far цвет может быть представлен либо как индекс в фиксированной стандартной 16-цветной палитре, доступной в свойствах консоли, либо как RGB. Когда вы в этом диалоге выбираете цвет из палитры, вы выбираете индекс. Это не RGB-цвет и его не надо аппроксимировать, он передается в ОС как есть. Однако, т.к. в поле RGB надо что-то показывать, Far запрашивает у ОС, какой именно RGB-цвет соответствует этому индексу (см. свойства консоли) и отображает полученное значение в информационных целях. Как только вы начинаете вводить что-то в это поле руками, цвет сразу же трактуется как RGB. Если его нельзя вывести как RGB, то он будет аппроксимирован к ближайшему индексу. Это по определению алгоритм с потерей информации и основная его цель - получить более-менее читаемый результат. При такой аппроксимации из 808080 получается индекс 7 (светло-серый), что вполне неплохо и достаточно близко к изначальному темно-серому. Однако, светло-серый уже занят цветом текста (foreground слева), а светло-серый на светло-сером вас вряд ли обрадует, поэтому один из них надо чем-то заменить, в результате чего фон становится белым. Да, этот алгоритм можно улучшать и пытаться иначе угадывать и заменять цвета в случаях, подобных этому, но см. выше - это никогда не было основной целью. Это fallback, который должен просто быть различим. Если кратко: - При отсутствии поддержки RGB просто выбирайте цвет из палитры, результат будет оптимальным. - При наличии - как угодно. |
|
|
Аргументы понятны, однако в них есть фактическая ошибка: 808080 - это не светло-серый, это тёмно-серый, светло-серый - это С0С0С0, в чём можно убедиться прямо на приведённой мною иллюстрации - текст выводится цветом С0С0С0, так что то, что алгоритм "деконфликтизации" цветов после ручного введения цвета фона аппроксимирует 808080 в FFFFFF (да-да именно в белый), вместо замечательно свободного стандартного цвета 808080 (в данном случае подошла бы точная аппроксимация из 808080 прямо в самого себя без потери) - это явно указывает на какой-то глюк. Ещё раз, я прекрасно понимаю, что потеря информации при переходе к 4-битным стандартным цветам математически неизбежна, но приводимый мною пример совсем не про это, а про то, что происходит искажение информации при переходе от цвета, который уже является стандартным 4-битным. 808080 - именно такой цвет, он искажаться не должен из чисто математических соображений. Особенно когда конфликта с цветом текста (С0С0С0) нет и в помине. Повторюсь, в приводимом мною примере нет конфликта между цветом фона и цветом текста, даже после аппроксимации "в лоб". Честное слово, не хочу терять своё и Ваше время на препирания, Conemu решает проблему на корню, просто хотел помочь, указав на нелогичное поведение алгоритма деконфликтизации и аппроксимации. Где-то этот алгоритм путается в самом себе. |
|
|
происходит искажение информации при переходе от цвета, который уже является стандартным 4-битным. 808080 - именно такой цвет, он искажаться не должен из чисто математических соображенийЭто вы знаете, что индекс 8 - это у вас 808080. Алгоритм этого не знает. Для него это обычный цвет, который надо превратить в какой-то индекс в диапазоне 0-15, всё. Чему именно там эти индексы соответствуют - в общем случае неизвестно. Учитывая, что это оттенок серого, то остается вообще 4 варианта: 0, 7, 8, 15. Т.к. 0x80 == 128, что примерно в середине диапазона, то это или 7 или 8. А дальше 128 из чисто математических соображений ближе к 255, чем к 0, поэтому получается 8. Я не отрицаю, что можно сделать иначе. Можно запрашивать у ОС абсолютные значения палитры и брать тот индекс, расстояние до которого минимально в RGB-простанстве, можно делать поправку на яркость и еще много чего, ну или хотя бы проверять цвет на наличие в палитре, как вы написали, и получать более лучший результат, но зачем?
Честное слово, не хочу терять своё и Ваше время на препиранияДа ну, какие препирания. В споре рождается истина, а что может быть лучше, чем отвлечься от суеты и детально обсудить какую-то техническую мелочь, затрагивающую примерно никого, с людьми, которым не пофиг :) Я совсем не против улучшений, но хотелось бы понять, зачем, учитывая написанное выше. "Из соображений абстрактного совершенства" - тоже вполне себе аргумент, но хотелось бы услышать что-то более весомое. |
|
|
А хотя, почему бы и нет. 5765. |
|
|
Up. Лучше / хуже? |
- Anonymous
