Комментарии 97
Это не говоря о том, что CIE LUV сама по себе специфическая система, используемая для очень узких научных целей. На практике используется CIE Lab и соответственно CIE LCh(ab).
Я вот прям серьезно копал этот вопрос. Lab используют скорее потому что "так сложилось".
На счёт Luv, ниже выдержка из доклада Ross Ihaka:
Ihaka et al. (2003): The two perceptually based spaces introduced by the
CIE in 1976 are the CIELUV and CIELAB spaces. The CIELUV space is
generally preferred by those who work with emissive colour technologies
(such as computer displays) and the CIELAB space is preferred by those
working with dyes and pigments (such as in the printing and textile
industries),
see https://www.r-project.org/conferences/DSC-2003/Proceedings/Ihaka.pdf
С RGB вы, наверное, то же не сразу запомнили, что зелёный + синий дадут жёлтый. Особенно, если до этого красками рисовали
16-ти цветные палитры на моей памяти не были фиксированный. Вы про RGB с 4 битами на цвет?
бит отвечал за канал, плюс один бит за яркость. и маска.
если палитру не менять.
en.wikipedia.org/wiki/Enhanced_Graphics_Adapter#Color_palette
Причём в RGB для понимания требуется в уме хотя бы примерно вычислить взаимные пропорции каждого компонента, что как-то не очень и быстро.
А вот шкалу HUE, как мне кажется, воспринять гораздо проще — достаточно запомнить пару контрольных точек вроде 0, 90, 180 и 270 градусов. Тем более, последовательность цветов совпадает с последовательностью в спектре / радуге, которую я помню и так.
Пожалуй, попробую перейти на HSL
На самом деле запомнить очень легко: жёлтый это отсутствие синего. (255, 255, 0) — это просто белый минус синий. Ну и частично в rgb действуют правила обычных красок: например, оранжевый между красным и жёлтым. Между (255, 0, 0) и (255, 255, 0) лежит как раз (255, 100, 0).
Но да, для коричневого порой появляется соблазн смешать красный с зелёным).
Вот, ошибся, хотя больше 25 лет с ргб работаю, но уже больше 20 лет забил на попытки запомнить смысл разных чисел в нём, кроме самых простейших типа только один цвет гораздо больше других, или все цвета одинаковы.
Жёлтый и синий дадут зелёный зато.
зелёный + синий дадут жёлтый
Вероятно, вы хотели сказать — зеленый + синий дадут голубой?
Что хотел сказать, то и сказал. Ошибся, что в очередной раз подтверждает, что RGB это ни разу не естественно, а требует изучения и практики.
С другой — нет ничего особо сложного в запоминании сочетаний цветов — мы каждый день запоминаем что-то новое, необходимой для работы или жизнедеятельности: музыканты — ноты и аккорды, врачи — названия препаратов, а дизайнеры вот — цвета)
Я специально еще написал слово «примерно», чтобы подчеркнуть отклонения пиков чувствительности колбочек от «чистых» цветов. Или вы смотрите на мир не трехцветными рецепторами?
то было сделано с опорой именно на физиологию тех самых колбочек
Да
аддитивная модель RGB прекрасно описывает цветовое пространство LMS
Нет. Точнее говоря пространство LMS конечно можно описать через RGB, но это а) нетривиальное соответствие и б) многие цвета LMS будут в этой модели заданы отрицательным R.
Понимаете, в реальности RGB выбрали банально из соображений максимизации цветового охвата. Вот gamut в системе XYZ. Внешняя линия соответствует монохроматическим цветам. Если Вы возьмете любую смесь из N этих монохроматических цветов, то Вы получите точку в виде линейной комбинации этих цветов взятых с положительными коэффициентами, т.е. точку внутри выпуклого многоугольника заданного этими точками. Для трех цветов Вы получите точку внутри треугольника. Для непрерывного спектра (любых реальных источников света) — точку где-то внутри gamut.
Нетрудно увидеть что для трехцветного источника света для максимизации цветового охвата надо брать R, B и какой-то G. И только. У нас нет рецепторов R, G или B. Наши рецепторы ближе к системе XYZ в которой нарисован этот рисунок и они способны воспринимать и распознавать цвета за пределами треугольника RGB.
Вот как выглядит система цветов если ее к RGB привести. Легко видеть что есть куча цветов с «отрицательным красным».
Название цвета словом очень относительно ваше прежнего опыта.
Голубой может часто восприниматься как светло-синий. В научной литературе и школьной программе биологии есть сине-зелёные водоросли, они же цианобактерии — из их названия как раз и следует более точный термин для смеси синего и зелёного — циан. В англоязычной литературе название смеси rgb(Y, X, X) / hsl(180, X, Y) — только одно cyan, то есть Green + Blue = Cyan.
А вот насчет цианобактерий есть тонкость — цвет у них получается, хоть и циановый, но другого оттенка — из-за субтрактивного смешивания зеленого и синего — получается сине-зеленый, который цвета морской волны, а не голубоватый циан аддитивного сложения, если уж строго.
О, кстати об IDE!
Всегда мечтал о плагине к IDE, который позволил бы редактировать цвета подсветки синтаксиса как в графических редакторах — фильтрами.
К примеру, есть у нас цветовая схема, например, Darkula или Monokai, но хочется вот такую же, но чуть более (или менее) контрастную, или сдвинуть всё в тёплые тона немного, или как в фотошопе "кривыми" покрутить и добиться чтобы не было неприятных оттенков в желтой части…
Сейчас приходится лазить по всем пунктам всех синтаксисов и настраивать кучу цветов. Наверняка до такой идеи кто-то додумался уже.
Кто слышал о таком?
Так в том и проблема, что на каждый цвет нажимать приходится. А я хочу сразу все сделать суть ярче или чуть контрастнее. Или только тусклые красные сделать чуть ярче и желтее, а остальные не трогать. Сейчас приходится кучу кликов сделать.
По другому я даже не представляю как IDE должна угадывать что вы там хотите изменить за 1 клик.
Да сколько угодно способов. К примеру, если мне надо всё оформление сделать ярче или темнее, можно покрутить глобальную яркость и все цвета будут изменены осветлением с гамма-коррекцией. Надо контрастность — домножаем все цвета на коэффициент. Фотошоп-то как-то умудряется понимать что вы там регулируете кривыми и меняет цвета многих пикселей. Так можно и в IDE.
Про сколько угодно способов.
- К примеру, можно взять корпус кода, раскрасить, применить фильтр к отрендереному изображению и снять с него цвета. Это будет максимально понятный фотошоперам подход.
- Можно взять все цвета схемы и разместить на матрице по цвету на пиксель. Фильтр применять к матрице как к картинке, потом цвета разбирать обратно.
Проблема с HSL в том что HUE начинаться может с любого оттенка в зависимости от софта. А RGB всегда от 0.
Подумал, как заменить rgba.
hsla оказывается существует.
Ну будьте быдлом. И не важно что вам так удобнее )
«Просто мне кажется что все должны пользоваться тем чем мне удобнее»
Вообще, иначе как саботажем нельзя назвать тот факт, что W3C протащил в свои стандарты HSL вместо HSB. Я свечку не держал, но подозреваю, что это было сделано исключительно в пику «проклятой проприетарщине» — с выстрелом в ногу всем веб-дизайнерам и разработчикам.
А вот появление в будущих спеках Lab и Lch — это в целом очень ожидаемая штука. Но есть нюансы: в зависимости от выбранной точки белого нас могут ожидать несовместимости с разными стандартами и/или погрешности конвертаций.
Чем HSL сильно хуже HSB (между ними разве не линейный переход вообще?)? И зачем вообще Lab / Lch в вебе, правда есть смысл учить браузер его интерпретировать?
Можно ещё посмотреть www.youtube.com/watch?v=nIaczt4F2D4
А уж зачем это в вебе — так затем, чтобы у дизайнеров было больше инструментов. Вот, теперь смогут равномерную воспринимаемую яркость у страницы делать.
Да и не только для дизайнеров. Первый же юзкейс который приходит на ум: вы делаете библиотеку компонентов. И в каждый компонент можно передать значение Hue но только его. При некоторых значениях цвет будет восприниматься слишком ярким, или темным, что вынудит пользователя вашей библиотеки дополнительно запарится чтобы выровнять воспринимаемою яркость у отдельных элементов.
HSB это конус, где значения по осям S и B можно удобно крутить независимо друг от друга.
HSL это двойной конус с изломом боковины. Во-первых, получается, что координаты S и L не независимы — крутя одну, субъективно кажется, что меняется и другая. Во-вторых, плавают эффективные диапазоны. Например, у максимального белого L=100, у максимального красного L=50.
А при L>50 все хроматические цвета выбеляются, ну то есть как бы падает S, хотя численно её никто не трогал.
В результате мысленно представить цвет по трём HSB-координатам не составляет труда. В HSL это намного сложнее. Отчасти благодаря удобству, отчасти поддержке Adobe, но де-факто HSB уже давно победила.
Теперь про CIE Lab. Его специально разрабатывали как perceptually uniform color space. То есть любые цвета с численно равной яркостью должны и визуально восприниматься как равнояркостные. В HSB/HSL это не так: например, синий субъективно всегда гораздо темнее зеленого при равных циферках. И изменение любой координаты на равное количество единиц должно приводить к изменениям субъективно равной величины. На самом деле в Lab это тоже работает не совсем идеально, но намного лучше, чем в любой другой системе.
Добавлю что Lab это уже динозавр в мире прецепционных цветовых моделей, логичнее сразу смотреть в сторону CAM16 или JzAzBz.
А вот про JzAzBz я не знал, обязательно почитаю.
Процитирую Вики:
"They tried to achieve this goal by creating a perceptually uniform color space, i.e. a color space where identical spatial distance between two colors equals identical amount of perceived color difference. Though they succeeded only partially, they thereby created the CIELAB (“Lab*”) color space which had all the necessary features to become the first color appearance model. While CIELAB is a very rudimentary color appearance model, it is one of the most widely used because it has become one of the building blocks of color management with ICC profiles."
По сути, Lab это прародитель цветовых моделей восприятия.
Могу посоветовать книгу Фершильда (второе издание есть в переводе) https://onlinelibrary.wiley.com/doi/book/10.1002/9781118653128
Модель восприятия получает на вход тристимул CIE XYZ плюс условия его просмотра, чтобы с учетом известных феноменов восприятия предсказать, как он будет выглядеть для зрителя. Это иная задача, чем та, которую мы обсуждаем. Нам всего лишь нужно прописать абсолютный цвет в CSS, а не угадывать, как на него повлияет освещение в комнате пользователя.
Книга у меня эта есть, и не только она.
Ну и в браузеры завезли толтолько два цветовых пространства sRGB и P3.
HSL и HSB это модели представления RGB.
А при L>50 все хроматические цвета выбеляются, ну то есть как бы падает S, хотя численно её никто не трогал.
Так цветовая модель отражает техническое ограничение монитора. Белый цвет на мониторе гораздо ярче максимального красного. При попытке задать цвет ярче чем может монитор он выбеляется.
Во-первых, получается, что координаты S и L не независимы — крутя одну, субъективно кажется, что меняется и другая.
Это как раз для HSB больше проблема — изменение S меняет V. HSL как раз по восприятию более однородная — ценою того что она вынуждена отражать реальные возможности монитора и из-за этого устроена сложнее.
Впрочем в отличие от Lab обе системы в любом случае неоднородны. Так что тем кому нужна однородность — берут Lab, те кому удобство — HSB.
Максимальный желтый (L*=98 для sRGB) по своей перцептивной светлоте гораздо ближе к белому (L*=100), чем например к максимальному синему (L*=30) — однако же ведет себя как последний.
Если говорить честно, усложнение HSL по сравнению с HSB не дает никаких реальных плюсов, только минусы.
Да, HSL опирается по сути на идею что все три цвета имеют равную интенсивность, тогда как в реальности зеленый напрочь забивает по яркости синий. Но это все равно ближе к реальности чем идея HSB о том что один пиксель синего цвета светит так же ярко как пиксель белого цвета (тот же синий + красный + зеленый).
А так я повторю то что уже написал — получилось что HSL занимает промежуточную нишу, проигрывая Lab в однородности а HSB — в удобстве.
Есть макет от дизайн-отдела с отдельным артбордом, в котором цветовая палитра, шрифты, базовые компоненты, какие-то правилами по сетке и/или вертикальному ритму, и т.д.
Загнал все возможные цвета в переменные (css или scss, неважно), продолжаешь работать.
Какая разница в каком формате загонять цвета из макета в переменные?
Да, если хранить в переменных весь цвет, тогда не важно в каком он формате. Но гибкость появляется в тот момент, когда в переменных вы храните именно составляющие части цвета а не цвет целиком. Тогда вы можете получать цвет из составных частей "на месте", внутри каждого компонента и изменять их под разные нужды в зависимости от ситуации. Это часто необходимо, когда вы создаёте что-то более чем просто верстку по идеальному макету. Когда у вас есть необходимость получать производные цвета от какого-то одного, но вы не знаете какой он, или хотите иметь возможность легко его изменять. Или когда вы занимаетесь поддержкой проекта, в который постоянно вносятся изменения и часто, без макета с отдельным артбордом на каждую правку.
А потом говорят: сделай кнопоску понасыщенней сам, дизайнерам некогда. Это если вообще есть дизайн-отдел.
В этом примере оттенок кнопки зависит (+130° на цветовом круге) от оттенка контейнера.
фигня же выходит
На вашей картинке ошибка.
Насышенный красный цвет справа hsl(0, 100%, 50%) при сатурации 0% будет иметь цвет hsl(0, 0%, 50%), что является серым, а не черным.
Да там всё неправильно. Надо было не 3 линейки рисовать, а линейку и два квадрата.
А если линейки — надо на первой зафиксировать стрелкой Hue = 0 (красный).
Вторую тогда переименовать в "Brightness".
А третью выкинуть и заменить на нормальную шкалу Saturation от красного к серому (или белому).
Ключевое преимущество HSL именно в возможности указывать характеристики цвета независимо друг от друга. Это открывает перед вами огромные возможности. Вы можете легко делать цвет ярче, темнее, более насыщенным или обесцвечивать. И при этом сохранять его оттенок. Или наоборот — изменять оттенки, не меняя их насыщенность или яркость.
Это не совсем так, если мы потом конвертируем цвет в RGB. Попробуйте зафиксировать компоненту L и прокрутить H. По факту вы получите разную яркость пикселя. Для отображения на мониторе так или иначе произойдёт конвертация в RGB, если мы HSL цвет конвертируем в серый путем простого усреднения, то получим разную яркость пикселя:
Обратите внимание на синий и желтый цвета — они разные по яркости. Цветовая модель, которая может сохранить яркость пикселя в RGB палитре называется HSI (i на конце). Ни HSL, ни HSV, ни HSY при блокировании яркостной компоненты итоговую яркость пикселя в RGB гарантировать не могут.
если мы HSL цвет конвертируем в серый путем простого усреднения, то получим разную яркость пикселяА зачем так делать? Есть же много методов конвертации в greyscale. Среднее арифметическое — самый тупой и некорректный из них. Ни графические редакторы, ни браузеры так не поступают. Имхо, усреднение можно оправдать только в случаях, когда требования по скорости/объему кода экстремальные, а на качество плевать (демосцена например).
Это не лучший вариант преобразования к серому
Хотя L в HSL действительно еще хуже
Но цвета не существует без формы, а формы не существует без окружения. Про это забывают все, кто берется за цветовые генераторы. Все это убивает любую теорию цветовых схем. Они вас начинают ограничивать сразу же по переносу в ваш интерфейс.
Цветовые круги и гуляния по ним давно вшиты в препроцессоры но не получили никакой популярности. Их используют только в каких нибудь генераторах чего нибудь по привычке.
Цвет всегда подбирается индивидуально даже в зависимости от типа антиалиазинга шрифта в браузере.
Увы, задать ручками новую цветовую схему надёжнее и быстрее, чем искать приятный вариант через установку коэфицентов то есть введение новой абстракции через предположение что чувственное восприятие цвета ложиться в мат. логику.
Конечный результат: приятная кнопка. Если вас устраивает результат вашего генератора -ок. Пока цветом заведует вы — все нормально. Но любой советчик цвета со стороны в приказном порядке сломает все.
По мне с цветами вообще нет проблем после добавления колорпикера в браузеры. Цвета подбираются индивидуально, копипастятся в css. Вам даже смотреть не надо что вы копипастите.
По мне с цветами вообще нет проблем после добавления колорпикера в браузеры. Цвета подбираются индивидуально, копипастятся в css. Вам даже смотреть не надо что вы копипастите.
Подбор индивидуальных цветов абсолютно везде — плохо масштабируется. Есть цвета естественным образом зависимые, например, всякого рода тени (чтоб получить естественный эффект). Если градиенты для тени сидеть и кодировать индивидуально подобранными цветами — ну, удачи вам потом изменять пачку из 5 RGB-значений, когда кто-то со стороны захочет чуть другого оттенка.
Мир фронтэнда давно уже сложнее, чем использование захардкоженных цветов ради раскраски кнопочек.
Я могу возразить только мыслью что это чревато бутсрапиризицией интерфейсов, и отбитыми пальцами дизайнера.
Если вы говорите про тень — это упрощение только до какого-то одного фона. И ее нельзя делать зависимой только от цвета элемента. И что делать с ночной темой?
удачи вам потом изменять пачку из 5 RGB-значений, когда кто-то со стороны захочет чуть другого оттенка.
Честно — не вижу проблем, потому что мыслю в ощущениях цвета, которые получаю регуляцией колорпикером до положения устраивает или не устраивает. Какие он значения и в какой системе показывает при этом — мало волнует. Я бы рад посмотреть пример.
Мир фронтэнда давно уже сложнее, чем использование захардкоженных цветов ради раскраски кнопочек.
Но все равно состоит весь и полостью из раскрашивания кнопочек)
Мир фронтэнда давно уже сложнее, чем использование захардкоженных цветовВот именно потому, что мир вообще и человеческое зрение в частности очень сложны, цвета и приходится подбирать вручную.
Один и тот же цвет выглядит по-разному в зависимости от размера и формы объекта, от цвета фона, соседей, наложенных эффектов, общей яркости сцены и тд. Цветовые модели RGB/HSB/HSL нелинейны, цвета смешиваются по-разному, сочетаются по-разному. Нюансов куча.
Поэтому попытки формализовать отношения между цветами какой-то простой формулой (вот эти все функции препроцессоров типа lighten/darken) — не работают. Хотя в теории выглядят заманчиво, согласен. Точнее, это может работать в узких частных случаях. Но в широком случае — типа, взял светлую тему, что-то там инвертировал или перемножил на коэффициент и получил темную — это абсолютная утопия. Поэтому без ручного вмешательства, увы, не обойтись.
Естественное, это не означает, что нужно впадать в другую крайность и хардкодить отдельный цвет для каждой запятой. Конечно, нужны разумные рамки.
Но в широком случае — типа, взял светлую тему, что-то там инвертировал или перемножил на коэффициент и получил темную — это абсолютная утопия. Поэтому без ручного вмешательства, увы, не обойтись.
Да ну нет конечно. Но вот когда надо передать определенные эффекты (тени, блики, тому подобное) — тут как раз нужны больше отношения между цветами, чем ручная работа. И статья абсолютно правильно утверждает, что RGB ну очень неудобен для описания таких отношений.
Например, у меня есть светло-серая кнопка default, ярко-синяя primary, красная danger и зеленая success. Так вот если я попытаюсь наложить на них численно одинаковые блики или тени, результат будет очень так себе. При любом варианте будет так: где-то почти ничего не видно, а где-то уже перебор.
border-bottom:1px dashed rgba(73,51,31,0.3)
Я подбирал цвет пунктира по образцу из 5 букв. Когда же я увидел, как он смотрится на слове из 10 букв — напрягся. Основная масса текста стала забирать на себя бОльшее внимание из-за своей оптической массы. Теперь подчеркивание слишком блеклое.И что делать? Искать золотую середину. Не велика проблема, просто я ее чувствую.
Другая проблема — гарнитура кастомных шрифтов меньше 1rem теряет ощущение однородности цвета из-за субпиксельного сглаживания (основная проблема любых кастомных шрифтов) с гарнитурой больше 1rem. Цвет то один! Что делать то?
Да, можно добавить text-shadow, оттенить немного… или же взять другой более сочный цвет до визуального сходства. И такого хватает.
Понимаете, это чувственная задача. Автор статьи, верятно, не обладает должной чувствительностью для того, чтобы воспинимать массу оттенков и их взаимоотношения. Меня не сильно волнует, например, опера. А для него облегчение задачи масштабирования цвета доминирует перед чьими то духовными и эстеттическими страданиями.
Тем более, что вы на самом деле разбираетесь исключительно со своими собственными возвышенными чуйствами, а не с чьими-то еще — ваши страдания над подчёркиванием и сглаживанием будут выглядеть совершенно иначе на других мониторах, операционных системах, и прочих разных условиях просмотра. Не говоря уж про разных людей. Вы вот страдаете над мелкими шрифтами, а лично я готов вломить каждому любителю поставить шрифт меньше 1rem канделябром, потому что у меня не настолько хорошие глаза, чтоб это потом разбирать.
Гарнитуры не всегда совпадают по размеру и выглядят по разному при 1rem. Например, на экране менее 500px можно отказаться от загрузки кастомных шрифтов и использовать системные. При этом заметно как сильно прыгает интерфейс. Если 1rem это 16px то у какой-то гарнитуры это 18px. Поэтому иногда приходится делать .95
Вы правы. Я не дизайнер. И если уж на то пошло, то и верстальщиком себя не считаю. Тема статьи — показать преимущества одной CSS функции в определённом спектре задач. Если вы работаете над одним сайтом, со статическим контентом, где каждое слово, каждое подчеркивание выверено до субпикселя того, я полагаю, описанные мною техники для вас не важны, или даже вредны. Но есть же и другие задачи. Скажем разработка темы для какой-то CMS. Там вы не можете знать какой контент будет на странице. Или конвеерная разработка. Когда нужно скопировать бОльшую часть из одного проекта, добавить куски другого чутка изменить и выкатить
Здесь скорость, гибкость и простое масштабирование куда важнее. Как бы грустно это не звучало.
Не надо всё в кучу валить. RGB, HSL и ключевые слова — это действительно разные способы представления цвета. А то, что вы назвали HEX — это не новый способ представления, а другая система счисления (шестнадцатиричная) при указании компонент RGB.
Пользуюсь везде RGB (обычно в hex-форме потому что так короче), потому что за долгое время он стал интуитивно понятным, и нужный цвет обычно можно закодировать с 1-2 попыток со скоростью нажатия кнопок на клавиатуре и без просмотра всяких таблиц. Ну и потому что это нативное представление для видеокарт и мониторов.
По сути набор цифр и букв. В любом инструменте, особенно «пипетка» есть поле где выводится это значение, и вам достаточно скопировать и вставить его в свой стиль.
Достаточно yellow, red, blue, green, white и др. :)
Забудьте про RGB и HEX