Accessible Palette: कलर सिस्टम में HSL का इस्तेमाल बंद करें

 (wildbit.com)
2 पॉइंट द्वारा GN⁺ 2023-08-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Postmark के मौजूदा color palette में हर रंग की महसूस होने वाली brightness असंगत थी और चरणों के बीच contrast ratio का अनुमान लगाना मुश्किल था, इसलिए WCAG द्वारा सुझाए गए contrast को हर बार मैन्युअली जांचना पड़ता था
  • HSL/HSV, RGB का सिर्फ़ एक सरल conversion model है, इसलिए यह इंसानी brightness और saturation perception को नहीं दर्शाता; एकल रंग चुनने में यह उपयोगी हो सकता है, लेकिन color system बनाने के लिए उपयुक्त नहीं है
  • CIELAB और LCh ऐसे perceptually uniform color spaces हैं जिन्हें इस तरह डिज़ाइन किया गया है कि numerical changes, महसूस होने वाले changes के अधिक करीब हों, इसलिए समान brightness level वाले color scales को ज़्यादा consistent बनाया जा सकता है
  • Accessible Palette एक LCh-आधारित ऐप है जो brightness, contrast ratio, Hue correction और मौजूदा brand colors को शामिल करने जैसी settings को adjust करके consistent palette बनाता है
  • WCAG 2.1 contrast ratio और WCAG 3 Working Draft के APCA, दोनों को साथ में जांचना चाहिए ताकि मौजूदा guidelines के compliance और भविष्य में contrast algorithm changes—दोनों से निपटना आसान हो

Postmark color system की समस्या

  • मौजूदा Postmark palette में दो समस्याएं थीं
    • नीला और लाल, पीले और हरे की तुलना में बहुत ज़्यादा गहरे दिखते थे; यानी महसूस होने वाली brightness consistent नहीं थी
    • color variations के बीच contrast ratio का अनुमान लगाना मुश्किल था, इसलिए यह आसानी से पता नहीं चलता था कि color pair WCAG recommendations को पूरा करता है या नहीं
  • हर बार color pair चुनते समय contrast ratio मैन्युअली जांचना पड़ता था, और व्यवहार में ऐसा न करने की संभावना भी काफ़ी थी
  • वजह HSL color model की अपनी सीमाएं और design tools में बेहतर alternatives के लिए पर्याप्त support न होना था

HSL color systems के लिए उपयुक्त क्यों नहीं है

  • RGB एक ऐसा model है जो screen के काम करने के तरीके को दर्शाता है; यह ऐसा intuitive model नहीं है जिससे इंसान आसानी से रंग चुन सके
  • HSL और HSV/HSB, 1970s में बनाए गए ऐसे alternatives हैं जिनका मकसद RGB को इंसानी रंग सोचने के तरीके के करीब दिखाना था
    • HSL का मतलब Hue, Saturation, Lightness है
    • HSV/HSB का मतलब Hue, Saturation, Value या Brightness है
  • उस समय ज़्यादा sophisticated models की computation cost अधिक थी, इसलिए HSL और HSV ने calculation speed के लिए perceptual accuracy का त्याग किया
  • नतीजतन HSL और HSV, RGB के आसान mathematical conversions मात्र हैं और इंसान द्वारा महसूस की जाने वाली brightness या saturation को ठीक से नहीं दर्शाते
  • उदाहरण के लिए, HSL में Saturation 100, Lightness 50 पर सेट किया गया color scale model के हिसाब से समान brightness वाला होता है, लेकिन असल में नीला #00F, पीले #FF0 या cyan #0FF की तुलना में कहीं ज़्यादा गहरा दिखता है
  • HSL में fully saturated colors RGB के maximum value पर map होते हैं और Lightness 50 के Hue circle पर रखे जाते हैं; Lightness 0 और 100 क्रमशः black और white से मेल खाते हैं
    • ज़्यादा bright या dark variations, white या black के साथ “mix” होने के तरीके से बनाए जाते हैं
    • बीच का vertical axis Saturation 0 वाले neutral colors या gray range है

CIELAB और LCh

  • जिस समय HSL और HSV को formalize किया जा रहा था, उसी समय एक बेहतर alternative, CIELAB color space, पहले से मौजूद था
  • International Commission on Illumination, यानी CIE ने 1976 में CIELAB या L*a* b* color space define किया
  • CIELAB एक perceptually uniform color space है जिसे इस तरह डिज़ाइन किया गया है कि numerical changes, लगभग समान महसूस होने वाले color changes से मेल खाएं
    • RGB के विपरीत, इसे दिखाई देने वाले colors की पूरी range को cover करने के लिए डिज़ाइन किया गया है
    • Lightness component L* को इंसानी brightness perception के करीब match किया गया है
  • CIELAB तीन axes से बना है
    • L* value 0 पर black और 100 पर white define करती है
    • a* axis green-red opponent color axis है; negative values green की ओर और positive values red की ओर होती हैं
    • b* axis blue-yellow opponent color axis है; negative values blue की ओर और positive values yellow की ओर होती हैं
  • CIELCh, LCh, या Lch(ab), CIELAB का cylindrical representation है
    • a* और b* की जगह Chroma और Hue angle इस्तेमाल होते हैं
    • Lightness वैसा ही रहता है
  • LCh का Hue angle HSL के Hue जैसा है, लेकिन identical नहीं है
    • HSL/HSV में red, green, blue—तीन additive primary colors—H=0, 120, 240° पर रखे जाते हैं
    • LCh में red, yellow, green, blue को h=0, 90, 180, 270° पर रखा जाता है
  • HCL या LCh(uv) नाम का एक similar color space भी है; LCh(ab) के विपरीत, इसमें Chroma 0 से 100 तक एक uniform scale रखता है

LCh में color scale बनाने का तरीका

  • HSL/HSV के विपरीत, LCh एक cylinder के भीतर fit होता है, लेकिन cylinder को पूरी तरह नहीं भरता
  • Lightness, Chroma और Hue के कुछ combinations ऐसे colors बनाते हैं जो exist नहीं कर सकते
    • उदाहरण के लिए dark और highly saturated yellow मौजूद नहीं होता
  • Lightness scale में black और white के करीब जाते समय इंसान जिन colors को अलग-अलग पहचान सकता है, उनकी संख्या घटती जाती है
  • असली screens visible colors की पूरी range दिखा नहीं सकतीं
    • sRGB gamut सामान्य screens को दर्शाता है और LCh color space का लगभग ⅓ ही शामिल करता है
    • CSS में भी, कम से कम अभी, इसी range तक limitation है
  • HSL में Saturation 100, Lightness 50 वाले color scale को LCh के हिसाब से देखें तो yellow सबसे bright और blue सबसे dark होता है
    • green, blue से लगभग तीन गुना bright और red से करीब दो गुना bright होता है
  • LCh में समान Lightness level पर scale को फिर से बनाया जाए तो हर color की brightness visually consistent रहती है
    • Chroma अलग होने की वजह से कुछ colors दूसरों से ज़्यादा saturated हो सकते हैं
    • notifications और warning colors को default text colors से ज़्यादा saturated रखना चाह सकते हैं, इसलिए color system में यह अंतर उपयोगी हो सकता है
  • Chroma को भी ज़्यादा consistent कर दें तो सीमित sRGB color space के भीतर भी smooth scale बनाया जा सकता है

Design tools की सीमाएं और Accessible Palette

  • अभी Figma, Sketch, Adobe XD CIELAB या LCh को support नहीं करते
  • Figma में LCH color picker और Chromatic plugins हैं, लेकिन flexible color system बनाने के लिए वे पर्याप्त नहीं थे
  • जिस tool की ज़रूरत थी, उसे तीन conditions पूरी करनी थीं
    • color variations बनाते समय brightness consistency बनाए रखना
    • steps के बीच contrast ratio control कर पाना
    • मौजूदा brand colors को स्वीकार करने जितना flexible होना
  • LCh support अच्छी तरह देने वाली Chroma.js library मिलने के बाद, code से नया palette generate करने के लिए एक simple tool बनाया गया
  • internal use और कुछ परिचितों के साथ share करने के बाद, यह tool Accessible Palette app के रूप में public किया गया
  • Accessible Palette ऐसा app है जो color levels में consistent brightness और predictable contrast ratios वाले color systems बनाने में मदद करता है

Accessible Palette कैसे काम करता है

  • starting color को adjust करने या मौजूदा design के colors paste करने पर, tool उस color के Chroma और Hue का इस्तेमाल करके कई Lightness steps का scale calculate करता है
  • Lightness पूरी तरह customizable है और light palettes व dark palettes—दोनों के लिए इस्तेमाल की जा सकती है
    • इसे मौजूदा brand colors शामिल करने के लिए बारीकी से adjust किया जा सकता है
    • Postmark में मौजूदा palette में सबसे ज़्यादा इस्तेमाल हुए yellow #FFDE00, blue #007DCC, green #4FC47F को preserve करने की कोशिश की गई
    • इन colors की Lightness values 88.6, 75.2, 50.6 को क्रमशः level 200, 400, 600 की brightness के रूप में इस्तेमाल किया गया
  • Contrast ratio Lightness के हिसाब से बदलता है, और हर level के लिए WCAG 2.1 recommended method तथा WCAG 3.0 Working Draft के नए algorithm—दोनों से calculate किया जाता है
    • by default सभी colors का contrast white background के आधार पर measure किया जाता है
    • चाहें तो किसी color swatch को चुनकर उस color के आधार पर contrast ratio measure किया जा सकता है
  • levels RGB या CIELAB color space का इस्तेमाल करके generate किए जा सकते हैं
    • कुछ cases में results अलग हो सकते हैं, इसलिए experiment करना worth है
    • Postmark color scheme में CIELAB के इस्तेमाल ने light red की purple tint कम की, लेकिन blue में purple tint बढ़ा दी
  • कुछ colors को पूरी range में Hue correction की ज़रूरत हो सकती है
    • bright yellow जैसे-जैसे dark होता है, उसमें green tint आने लगती है
    • इसे orange के थोड़ा और करीब लाने के लिए negative Hue correction इस्तेमाल किया गया
  • app इस्तेमाल के दौरान URL update करता है ताकि changes save हो जाएं
    • इसे team के साथ share किया जा सकता है या बाद के reference के लिए Figma library और CSS color variable file में add किया जा सकता है
  • example palettes में नया Postmark color palette, Google’s Material Design, TailwindCSS पर आधारित palettes शामिल हैं
    • ये examples original को exact replicate नहीं करते, बल्कि original colors और brightness steps से inspired alternatives हैं

Contrast ratio calculation और WCAG

  • Accessible Palette दो contrast ratios इसलिए दिखाता है क्योंकि WCAG 2.1 method में limitations हैं
  • WCAG 2.1 foreground color की luminance को background color की luminance से divide करके contrast ratio calculate करता है
  • यह formula linear response देता है, लेकिन इंसान bright colors के बीच contrast को dark colors के बीच contrast की तुलना में ज़्यादा महसूस करते हैं
  • वास्तविक examples में WCAG 2.1 recommendations पूरी करने वाला sample, “insufficient” contrast ratio दिखाने वाले sample से भी पढ़ने में मुश्किल हो सकता है
  • W3C इस problem को पहचानता है, और Andrew Somers ने 2019 में public discussion शुरू की थी
  • Andrew Somers द्वारा proposed नया working algorithm WCAG 3 Working Draft का हिस्सा बन गया और उन्होंने APCA Contrast Calculator भी बनाया
  • APCA का full form Advanced Perceptual Contrast Algorithm है; यह perceptually ज़्यादा accurate है और font size व weight को भी ध्यान में रखता है
  • Accessible Palette APCA का इस्तेमाल करता है और readable text के minimum recommended level के रूप में score 60 इस्तेमाल करता है
    • यह WCAG 2.1 के मौजूदा 4.5:1 contrast ratio recommendation जैसा benchmark है
  • WCAG 2.1 contrast ratio पूरी तरह useless नहीं है
    • mid-range colors में यह अब भी काफ़ी accurate है
    • लेकिन overall नया algorithm एक बड़ा improvement है
  • WCAG 3 method अभी Working Draft है, इसलिए समय के साथ बदल सकता है
  • मौजूदा guidelines के compliance और भविष्य के changes—दोनों को ध्यान में रखना हो तो color system बनाते समय दोनों guidelines को साथ में consider करना बेहतर है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-08-30
Hacker News की टिप्पणियाँ

  • सामान्य display और printing systems में saturated लाल और नीला, हरे की तुलना में असल में ज्यादा गहरे माने जाने चाहिए
    color space के हिसाब से exact formula बदलता है, लेकिन Grayscale = 0.299R + 0.587G + 0.114B अक्सर quote किया जाता है, और इस मामले में सबसे चमकीला pure red करीब 30%, pure blue 11% brightness का होता है, इसलिए ज्यादातर मामलों में bright red लगभग विरोधाभास जैसा है
    ऐसे रंग इस्तेमाल किए जा सकते हैं, लेकिन वे हमेशा गहरे ही दिखेंगे; और अगर सिर्फ contrast rules लागू करें तो accessibility तो पूरी हो सकती है, लेकिन अगर अच्छा दिखने वाला result भी चाहिए, तो लेख में बताई technique कहीं ज्यादा फायदेमंद है
    https://en.wikipedia.org/wiki/Anaglyph_3D जैसी red-cyan stereoscopic images बनाते समय भी पेड़ और घास हरे होते हैं, लेकिन असल में उनमें red component ज्यादा होता है, इसलिए channel balance अच्छा रहता है और 3D effect व color दोनों अच्छे निकलते हैं
    संदर्भ: https://www.dynamsoft.com/blog/insights/image-processing/ima...

    • NTSC broadcast safe range के दौर और लाल रंग से बहुत प्यार करने वाले clients याद आ जाते हैं
      यह समझाना हमेशा मुश्किल था कि सुंदर red artwork TV पर बिल्कुल सुंदर नहीं दिखेगा, और broadcast के लिए हो तो खासकर और भी
      broadcast के लिए न भी हो, तो spec से बाहर red कुछ frames बाद तक बचा हुआ दिख सकता था, और ऐसा फैलता दिख सकता था जैसे गला कट गया हो
    • इसमें कई बातें गलत हैं
      अगर आपने replies पढ़ी हैं, तो जवाब दें; मैं कुछ बातों को और साफ समझाने की कोशिश करूँगा

  • मुझे लंबे समय से यह बात खटकती रही है कि WCAG 2.1 recommended criteria पूरा करने वाला sample असल में “insufficient” contrast ratio वाले sample से पढ़ने में ज्यादा कठिन है
    उत्सुकता है कि “accessibility guidelines” वाला formula उल्टा असर करता है, फिर भी standardize क्यों किया गया

    • contrast accessibility में सबसे ज्यादा इस्तेमाल होने वाले algorithm और guidelines के लिए peer-reviewed evidence नहीं होना थोड़ा अफसोसजनक है
      2.1 के साथ भी ऐसा है और अगले standard के साथ भी, इसलिए इतने प्रभावशाली क्षेत्र में industry को और rigorous research sponsor करनी चाहिए
    • मुझे याद है कि W3C/WCAG के भीतर contrast evaluation formula बदलने की कोशिश हुई थी
      शायद बस ऐसी मांग थी और अभी official रूप से adopt नहीं हुआ हो

  • इस विषय पर मैंने जो सबसे अच्छा लेख देखा है, वह https://www.handprint.com/HP/WCL/color1.html है
    बहुत लंबा लेख है, इसलिए इसके लिए पूरा दिन देने की तैयारी रखनी होगी
    हैरानी हो सकती है, लेकिन ClickHouse में logs को खूबसूरती से color करने में भी इस लेख के कुछ ideas इस्तेमाल किए जा रहे हैं: https://github.com/ClickHouse/ClickHouse/blob/master/base/ba...

    • इन ANSI colors को RGB में convert करने का specific तरीका ढूँढना मुश्किल था, और असल में ये सिर्फ color requests हैं और terminal settings पर निर्भर लगते हैं
      जानना चाहूँगा कि code में set किए गए हर message type के लिए expected RGB values क्या हैं, क्या आप share कर सकते हैं

  • Figma की Config conference में Eugene से मिला था; उन्होंने designers को इसी तरह के बहुत से practical tips दिए, वे बेहद मददगार थे और design व accessibility को लेकर सचमुच गंभीर व्यक्ति लगे
    इस लेख में मैं खास तौर पर APCA की तारीफ करना चाहूँगा, जो WCAG 2 के color contrast algorithm का successor बनने की संभावना रखता है
    Figma के internal accessibility overhaul में भी APCA इस्तेमाल किया गया, और उसकी वजह से final result काफी बेहतर हुआ
    Eugene अच्छे से दिखाते हैं कि WCAG 2 कहाँ fail होता है, और असल में हम भी लगातार ऐसे cases से टकरा रहे थे
    मुख्य सलाह यह है कि colors को सही तरह match करना सचमुच कठिन है
    tools मदद करते हैं, लेकिन किसी point पर आपको अपनी आँखों पर भरोसा करना पड़ता है
    आखिरकार ये tools आँखों के color देखने के तरीके को सिर्फ mathematically approximate करते हैं, और final criterion algorithm नहीं बल्कि इंसानी आँख है
    जहाँ tools या algorithms गलत result देते हैं, वहाँ adjust करना या basics पर लौटना बेहतर है

    • Figma के internal accessibility overhaul में APCA इस्तेमाल करने वाली बात को थोड़ा और विस्तार से समझा सकते हैं?
      जानना चाहता हूँ कि क्या इसका मतलब है कि सिर्फ APCA इस्तेमाल किया गया और WCAG 2 color contrast algorithm जिन चीजों को insufficient contrast दिखाता है, उन्हें ignore किया गया
    • मैं red-green color blind हूँ, और Figma की default accessibility इतनी अच्छी है कि मुझे कभी अलग से accessibility adjustments के बारे में सोचना नहीं पड़ा
      बढ़िया बनाया है

  • HCT को भी पेश करना चाहूँगा
    यह Material You को संभव बनाने के लिए बनाया गया color space है, जो यहाँ बताए गए brightness measurement को आधुनिक color science color space के साथ जोड़ता है
    LAB/LCH 1976 में आया था
    यह design को ज़्यादा intuitive बनाता है; बस इतना जानना काफी है कि T का अंतर 40 हो तो वह button के लिए WCAG मानक पूरा करता है, और 50 हो तो text के लिए

    • दिलचस्प
      जानना चाहूँगा कि HCT की तुलना https://www.hsluv.org/comparison/ से कैसे होती है
      HCT की तरह, यहाँ भी L के अंतर से contrast colors चुनना आसान हो जाता है
      इसी संदर्भ में https://www.myndex.com/APCA/ और इसके standard बन जाने पर अपनाए जाने वाले approach के बारे में भी आपकी सोच जानना चाहूँगा
      दो colors के बीच contrast value इस बात पर निर्भर करती है कि कौन-सा color foreground है और कौन-सा background, इसलिए अब लगता है कि सिर्फ T के अंतर की तुलना करना पर्याप्त नहीं होगा
    • HCT सीखने के लिए अच्छे resources हैं या नहीं, यह जानना चाहूँगा
      मान लीजिए किसी application में लाल, पीला, नीला, नारंगी, हरा, बैंगनी—यानी 3 primary colors और 3 complementary colors के बराबर—6 colors चाहिए
      सटीक colors कौन-से होंगे, यह बहुत मायने नहीं रखता, लेकिन अगर उन 6 को कुछ हद तक पहचानने योग्य रखते हुए brightness, और शायद saturation भी, लगभग समान रखना हो तो क्या करना चाहिए
      पीला बहुत bright होता है और नीला बहुत dark, इसलिए शायद कोई exact answer नहीं होगा और किसी approximation तक पहुँचना पड़ेगा
      क्या ऐसी चीज़ सीखने के लिए कोई tools या tutorials हैं, यह जानना चाहूँगा
    • जानना चाहूँगा कि कोई public specification कहीं मौजूद है या नहीं
      मुझे सिर्फ GitHub पर material-color-utilities का code मिला
      code देखने पर calculations OkLab से कहीं ज़्यादा जटिल लगती हैं, खासकर HCT से RGB की दिशा में

  • लेख में oklab/oklch को छोड़ देने के अलावा, यह दावा भी गलत है कि web/CSS सिर्फ sRGB को support करता है
    CSS color() function कई color spaces को support करता है

    • मैं लेखक हूँ
      यह लेख 2 साल पहले publish हुआ था, और जब मैंने tool पर काम शुरू किया था तब OkLCH specification भी अभी आई नहीं थी
      आज होता तो मैं LCH के बजाय OkLCH चुनता, क्योंकि यह LCH की कुछ समस्याओं को हल करता है
    • CSS Color Module Level 4 अभी भी recommendation draft stage में है
      यहाँ “support” को अधिक सटीक रूप से कहें तो यह “Microsoft Edge(chromium) और Pale Moon(goanna) को छोड़कर support” के करीब है
      https://test.csswg.org/harness/results/css-color-4_dev/group...
    • मैंने oklab और कई LAB-family color spaces को सीधे इस्तेमाल करके देखा है, और Oklab सरल calculations से काट-छाँट कर इस्तेमाल करने के लिए शानदार है
    • Oklch के ऊपर बनाया गया एक color model भी है
      हालांकि यह brightness के बजाय APCA, यानी WCAG 3 के contrast ratio का उपयोग करता है: https://github.com/antiflasher/apcach

  • oklab LCh से बेहतर विकल्प हो सकता है
    https://bottosson.github.io/posts/oklab/

    • यह शुरुआती premise से काफी दूर हटता है
      brightness channel बाकी सभी color spaces के उलट है, और L का LCH या LAB के L से कोई संबंध नहीं है
      इसकी सफलता ने उलटे बौद्धिक गरीबी को और बढ़ाया है
      मूल blog post में सुधारने लायक बहुत कुछ है, और जहाँ से CAM16 UCS का उपयोग करके gradient के आधार पर accuracy का दावा शुरू होता है, वहाँ से तर्क काफी बिगड़ जाता है
    • यह playground LCh और OKLAB सहित 16 color spaces को हैरतअंगेज़ ढंग से visualize करता है: https://color-playground.ardov.me/spaces-3d
    • perfect तो नहीं है, लेकिन कुछ स्थितियों में color interpolation के लिए मैं oklab और oklch का उपयोग करता आया हूँ, और RGB या HSL में interpolate करने की तुलना में results visually काफी ज़्यादा संतोषजनक रहे
    • मैं अपनी site पर OkLab को संतोषजनक रूप से इस्तेमाल कर रहा हूँ, और पहले CIELAB से बनी color palette की तुलना में यह आँखों के लिए बहुत ज़्यादा आरामदेह है

  • अगर CIELAB values perceptual changes पर आधारित हैं, तो accessibility के साथ उनका interaction कैसा होता है, यह जानना चाहूँगा
    क्या हमें इस बात की चिंता करनी चाहिए कि ऐसे perceptual formulas शायद standard vision को आधार बनाकर बनाए गए हैं
    क्या यह color vision deficiency के type के अनुसार बदल सकता है, या फिर यह वैसा मुद्दा नहीं है—यह भी जानना चाहूँगा
    मैं charts को जितना हो सके accessible बनाने की कोशिश करता हूँ, लेकिन color के बारे में कभी कुछ नहीं सीखा, इसलिए बस advice follow करता हूँ और खुद derive नहीं कर सकता
    इसलिए यह पूरी तरह संभव है कि सवाल बेवकूफाना हो

    • मैंने इस क्षेत्र में काम किया है
      contrast non-linearly बदलता है
      simulations काफी आसानी से लागू किए जा सकते हैं, और Machado आदि authors का simulation बस matrix transformation है

  • यह लेख explanation नीचे रखता है, लेकिन WCAG 3 draft standard का पढ़ने में आसान contrast test, APCA Contrast, WCAG 2.1 के contrast ratio की तुलना में कुछ colors के लिए कहीं ज़्यादा fair है
    perceptual contrast के पीछे की color theory पर पढ़ने लायक लेख: https://www.smashingmagazine.com/2022/09/realities-myths-con...
    APCA को संक्षेप में समझाने वाला लेख: https://typefully.com/u/DanHollick/t/sle13GMW2Brp

    • APCA अच्छा काम करता है, लेकिन इसकी license बहुत अजीब और restrictive है
      किसी भी उपयोग से पहले उस हिस्से को ध्यान से देख लेना और यह तय कर लेना बेहतर होगा कि आप सच में इसका इस्तेमाल कर सकते हैं या नहीं

  • कोड कहाँ है
    वेब फॉर्म नहीं, बल्कि किसी भी software में इस्तेमाल किया जा सकने वाला algorithm चाहिए

    • लेखक ने जिस library का ज़िक्र किया था, वह यह है
      मैंने खुद इस्तेमाल करके देखा है और यह अच्छी तरह काम करती है
      https://github.com/gka/chroma.js
    • इस thread में लेखक ने कहा था कि अगर वे अभी यह लेख फिर से लिखते, तो Oklab[1] का इस्तेमाल करते
      Oklab को [2] में पेश किया गया था, और उस लेख का code इस्तेमाल करना वाकई आसान है
      [1]: https://news.ycombinator.com/item?id=37310534
      [2]: https://bottosson.github.io/posts/oklab/