coJlHe4Hblu_noH4uk

Хорошая идея.

Ну вот в этом и косяк, 99%. Там же 8 бит/цвет. Т.е. полная цепочка идет как Lab -> XYZ -> RGB -> (round) TColor-> XYZ -> Lab -> LCh, так? Но тогда почему L при этом из Lab'а не копируется напрямую в LCh? Гляну. @StranikS_Scan, может это всё переписать через real? Работы немного, простой Pascal код без объектов я накидать могу на всё. И еще в чем проблема использования RGB в качестве промежуточного цвета: Наш RGB это sRGB обычно, так вот при преобразовании в него и обратно отсекается огромная часть значений, которые могут быть представлены в Lab. Вообще, внутри любого нормального цветового редактора цепочка преобразований выглядит так: ..............................HSL..................................... ................................⇅....................................... CMYK ⇆ CMY ⇆ RGB ⇆ XYZ ⇆ Lab ⇆ LCh ................................⇅....................................... ..............................HSB.................................... С учетом того, что "промежуточный" формат записи цвета должен быть как можно ближе к центру этого графа преобразований и как можно меньше должен "резать" цвета, то кандидат тут один - XYZ вместо TColor.

Значит у них какой-то косяк, какой - не пойму. Фишка вот в чем. L в LCh должна СТРОГО совпадать с L в Lab. C - это длина вектора (а;b), в нашем случае нормализованная. (тогда почему при L=0, a=-128, b=-128 насыщенность не максимальна?) h - угол того же вектора от какой-то там точки отсчета. Можешь код свой скинуть? Посчитал через procedure LabToLCH(l, a, b: real; var lum, c, h: real); begin h := ArcTan2(b, a); if h > 0 then h := (h/PI) * 180 else h := 360 - (ABS(h)/PI) * 180; lum := l; c := SQRT(a*a + b*b); end; Только C смасштабировал.

Очень привык к Adobe, поэтому про колесико вспомнил сразу. Теперь про LCh (не LCH как в XCPad, а LCh именно, знаю, что занудство, но так правильно) - Слева Lab, по центру то, что выдает XCPad, справа то, что должно быть. LCh.zip

Может помочь и это (Photoshop) - сразу увидите мир глазами дальтоника.

@seriych,понял. Завтра еще почитаю, отпишусь.

Сам напросился. Как самый настоящий поц из серии "дедываивали" одним из первых танков я качал ИС-7!!! Играл на xwn8~30. Сейчас я играю раза в два лучше. Значит ли это, что мои показатели на ИС-4 будут схожими с показателями на ИС-7? Это скорее мелочь и редкость, но все же, не выйдет ли чего плохого?

Да вроде бы, но лучше проверить через вот эту штуку на крайних и нулевых значениях a и b в Lab. Если некогда, потестирую, отпишусь. Как назвать: L - CIE Lightness, % (по аналогии с твоим вариантом, хотя я бы использовал безразмерную величину). C - Chroma, % (в оригинале так, но понятнее будет Saturation или CIE Saturation) h - hue, deg, он же цветовой тон. По диапазонам: L [0; 100]; C - если принять, что a и b в Lab - [-128; 127], то от 0 до корень(128*128+128*128)=181.019, можно отмасштабировать к процентам от 0 до 100. От 0 до 360, как и в XCPad. И еще. У твоих полей ввода можно добавить обработку событий скроллинга мыши? Чтобы гонять значения вверх-вниз колесом. Если долго, то не надо. UPD. Несовпадение HUE в LCh и HS** - это нормально) 'оффтоп'

@StranikS_Scan, псевдокод, примерно так (Lab уже посчитан) (через Math.Atan2, чтоб без проверок на деление на 0): var h = Math.Atan2(Lab_Color.B, Lab_Color.A); // convert from radians to degrees if (h > 0) { h = (h / Math.PI) * 180.0; } else { h = 360 - (Math.Abs(h) / Math.PI) * 180.0; } if (h < 0) { h += 360.0; } else if (h >= 360) { h -= 360.0; } LCh_Color.L = Lab_Color.L; LCh_Color.C = Math.Sqrt(Lab_Color.A * Lab_Color.A + Lab_Color.B * Lab_Color.B); LCh_Color.H = h; И объясню зачем. Если HSB/HSV просто удобно делят цвет на "интуитивные" тон, насыщенность и яркость, то LCh делает это с учетом особенностей цветовосприятия. Приведу пример. СИНИЙ и ЖЕЛТЫЙ цвета в HSB будут иметь одинаковую насыщенность и яркость, лишь разный цветовой тон, но это же не так, желтый гораздо ярче, а синий - насыщеннее. Ели же идти не от HSB/HSV в поиске одинаково выглядящих по яркости и насыщенности оттенков, а от LCh, то ПЕРВЫЙ ЦВЕТ и ВТОРОЙ ЦВЕТ будут смотреться идентично, за исключением цветового тона. UPD. Вдруг пригодится: раз, два.

@StranikS_Scan, сможешь в колор селектор прикрутить Lch - это Lab в цилиндрических координатах?

@seriych, а автоматически нельзя менять значения цветов в скриптом при чтении? По определенным правилам. Просто интересно.

Имел ввиду приблуду типа трейнера, вклинивающуюся в DirectDraw. Читаем значения HP из памяти клиента, конфиг, состояние ушей - выводим полоски на экран.

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

@sirmax, но в обычном режиме перерисовки нет как таковой. Плюс замечал, устанавливая уши @XSerzHX, что если включать их, то лагает, а если Ctrl-Tab'нуться на свои, лагов гораздо меньше. Если этот факт интересен, могу логи фрапса и реплей загрузить.

А alt-уши с полосками ХП будут вызывать лаг только при отображении, когда их не видно, все будет нормально?

@sirmax, был бы мануал для идиотов чайников, типа меня, посвященный компиляции мода, было бы проще. Где все разжевано. Или хотя бы видос. Желательно под окна. Не тебе одному такая мысль приходила)

@sech_92, в таком случае, кстати, можно без html обойтись, если скомбинировать.

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

Согласен. Будут гадить. ЦА же)

А если именно полоски хп рисовать в панель счета по задаваемым смещениям?

Проблема касается только ушей, или же любого flash-модуля? В равной степени?

@sech_92, а как это будет выглядеть в ангаре в случае включения глобальной замены? Вопрос в том, реализуемо ли?

, зачем, если везде, где указывается никнейм (я про уши) есть уже HTML?Настраивать цвет никнеймов в кланчате по кпд? Или в ангаре? Тогда это @sirmax вспотеет от работы, сколько всего менять. А тут просто, макрос и глобальная замена, как это уже реализовано в XVM, только таблица не в сорцах, а в отдельном конфиг-файле.

Тяжелые при перерисовке вообще, или именно при использовании картинок?

, интересный вариант использования.Если у кого еще интересные идеи будут, делитесь)