View Issue Details

IDProjectCategoryView StatusLast Update
0003852Far ManagerSettingspublic2021-04-08 21:21
Reporternyq Assigned ToDrKnS  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Platformx64OSWindows 
Product Version3.0 
Fixed in Version3.0 
Summary0003852: Неверно интерпретируются кустомные цвета в настройках цветов
DescriptionПри попытке ввода кустомного цвета фона в настройках цветов некоторые цветовые комбинации интерпретируются неверно, к примеру при вводе значения RGB 505050 вместо тёмно-серого фона получается ярко-белый, соответствующий на деле значению FFFFFF.
Steps To Reproduce[list=0]
  • Идём в F9->Options->Colors->Panel->Normal text
  • Вводим в секции Background кустомное значение 505050
  • Получаем неожиданно ярко-белый цвет фона
  • [/list]
    Additional InformationЧто характерно, проблема с кустомным вводом возникает даже для цветов, которые ФАР точно умеет отображать верно. Вот как убедиться в этом:
    [list=0]
  • Идём в F9->Options->Colors->Panel->Normal text
  • Выбираем в секции Background стандартный тёмно-серый цвет
  • В поле кустомного ввода появляется верное значение 808080, цвет фона также соответствует ожиданиям - всё прекрасно работает
  • Временно меняем цвет на любой другой стандартный, например на синий
  • Вводим то же самое значение 808080, но уже руками, в поле кустомного ввода
  • И получаем жутко яркий белый цвет
  • [/list]

    Также характерно, что глюк проявляется только в некотором диапазоне приближения к идеально серому. К примеру, искажение цвета до белого сохраняется в диапазоне от 804080 до 80BF80, а вот при переходе к значениям 803980 (снизу) или 80С080 (сверху) цвет "отлипает" и начинает показываться нормально.
    TagsNo tags attached.
    Build5765

    Activities

    nyq

    2021-03-18 01:09

    reporter  

    Untitled.png (8,019 bytes)   
    Untitled.png (8,019 bytes)   

    DrKnS

    2021-03-18 14:52

    administrator   bugnote:0017030

    Last edited: 2021-03-18 14:52

    View 2 revisions

    RGB цвет работает или в Windows 10 со включенной опцией Use Virtual Terminal for rendering в настройках интерфейса Far, или в Conemu с любой ОС и независимо от опции.

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

    nyq

    2021-03-19 13:32

    reporter   bugnote:0017031

    Аргумент об ограничении на 16 цветов понятен и принят. Однако неясно, почему тогда при ручном вводе значения 808080, которое соответствует стандартному тёмно-серому цвету, ФАР не отображает этот стандартный цвет, а вместо него сбивается на ярко-белый. При этом при выборе того же стандарного цвета из палитры он отображается корректно как тёмно-серый и в поле RGB прописывается его корректное значение 808080. То есть помимо закономерного ограничения на 16 стандартных цветов всё же где-то присутствует ошибка интерпретации значений поля ввода значений цветов, ибо одно и то же значение 808080 (соответствующее одному из 16 стандартных цветов) приводит к двум совершенно разным поведениям в зависимости оттого, выбрали ли мы цвет через палитру или же ввели в поле RGB.
    Untitled-2.png (22,076 bytes)   
    Untitled-2.png (22,076 bytes)   

    DrKnS

    2021-03-19 15:19

    administrator   bugnote:0017032

    Внутри Far цвет может быть представлен либо как индекс в фиксированной стандартной 16-цветной палитре, доступной в свойствах консоли, либо как RGB.

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

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

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

    Если кратко:
    - При отсутствии поддержки RGB просто выбирайте цвет из палитры, результат будет оптимальным.
    - При наличии - как угодно.

    nyq

    2021-03-20 14:57

    reporter   bugnote:0017033

    Аргументы понятны, однако в них есть фактическая ошибка: 808080 - это не светло-серый, это тёмно-серый, светло-серый - это С0С0С0, в чём можно убедиться прямо на приведённой мною иллюстрации - текст выводится цветом С0С0С0, так что то, что алгоритм "деконфликтизации" цветов после ручного введения цвета фона аппроксимирует 808080 в FFFFFF (да-да именно в белый), вместо замечательно свободного стандартного цвета 808080 (в данном случае подошла бы точная аппроксимация из 808080 прямо в самого себя без потери) - это явно указывает на какой-то глюк.

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

    Честное слово, не хочу терять своё и Ваше время на препирания, Conemu решает проблему на корню, просто хотел помочь, указав на нелогичное поведение алгоритма деконфликтизации и аппроксимации. Где-то этот алгоритм путается в самом себе.

    DrKnS

    2021-03-20 19:20

    administrator   bugnote:0017034

    происходит искажение информации при переходе от цвета, который уже является стандартным 4-битным. 808080 - именно такой цвет, он искажаться не должен из чисто математических соображений
    Это вы знаете, что индекс 8 - это у вас 808080. Алгоритм этого не знает.
    Для него это обычный цвет, который надо превратить в какой-то индекс в диапазоне 0-15, всё. Чему именно там эти индексы соответствуют - в общем случае неизвестно.
    Учитывая, что это оттенок серого, то остается вообще 4 варианта: 0, 7, 8, 15.
    Т.к. 0x80 == 128, что примерно в середине диапазона, то это или 7 или 8.
    А дальше 128 из чисто математических соображений ближе к 255, чем к 0, поэтому получается 8.

    Я не отрицаю, что можно сделать иначе. Можно запрашивать у ОС абсолютные значения палитры и брать тот индекс, расстояние до которого минимально в RGB-простанстве, можно делать поправку на яркость и еще много чего, ну или хотя бы проверять цвет на наличие в палитре, как вы написали, и получать более лучший результат, но зачем?
    • Все эти операции не бесплатны, скорость работы критична, поэтому придется городить какой-то кеш и периодически его инвалидировать, т.к. пользователь может изменить палитру в любой момент, а ОС не предоставляет никаких нотификаций для этого события.
    • Это не нормальный режим работы. Я не могу представить ситуацию "у пользователя нет поддержки truecolor, но он все равно вводит truecolor-цвета и постоянно работает с тем, что ему там фар наподставлял". Этот режим нужен для одного случая: у пользователя была поддержка truecolor, но по каким-то причинам прямо сейчас ее нет, и ему либо надо включить ее обратно, либо добраться до настроек цвета и установить там все по умолчанию". Кривые цвета тут не помеха, лишь бы читалось.
    Честное слово, не хочу терять своё и Ваше время на препирания
    Да ну, какие препирания. В споре рождается истина, а что может быть лучше, чем отвлечься от суеты и детально обсудить какую-то техническую мелочь, затрагивающую примерно никого, с людьми, которым не пофиг :)
    Я совсем не против улучшений, но хотелось бы понять, зачем, учитывая написанное выше.
    "Из соображений абстрактного совершенства" - тоже вполне себе аргумент, но хотелось бы услышать что-то более весомое.

    DrKnS

    2021-03-21 03:48

    administrator   bugnote:0017035

    А хотя, почему бы и нет. 5765.

    DrKnS

    2021-04-02 22:51

    administrator   bugnote:0017042

    Up.
    Лучше / хуже?

    Issue History

    Date Modified Username Field Change
    2021-03-18 01:09 nyq New Issue
    2021-03-18 01:09 nyq File Added: Untitled.png
    2021-03-18 14:52 DrKnS Note Added: 0017030
    2021-03-18 14:52 DrKnS Note Edited: 0017030 View Revisions
    2021-03-19 13:32 nyq Note Added: 0017031
    2021-03-19 13:32 nyq File Added: Untitled-2.png
    2021-03-19 15:19 DrKnS Note Added: 0017032
    2021-03-20 14:57 nyq Note Added: 0017033
    2021-03-20 19:20 DrKnS Note Added: 0017034
    2021-03-21 03:48 DrKnS Note Added: 0017035
    2021-03-21 03:48 DrKnS Assigned To => DrKnS
    2021-03-21 03:48 DrKnS Status new => assigned
    2021-03-21 03:48 DrKnS Status assigned => feedback
    2021-04-02 22:51 DrKnS Note Added: 0017042
    2021-04-08 21:21 DrKnS Status feedback => closed
    2021-04-08 21:21 DrKnS Resolution open => fixed
    2021-04-08 21:21 DrKnS Fixed in Version => 3.0
    2021-04-08 21:21 DrKnS Build => 5765