टर्मिनल को 256-रंग पैलेट अपने-आप जनरेट करना चाहिए

 (gist.github.com/jake-stewart)
1 पॉइंट द्वारा GN⁺ 2026-02-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह लेख सुझाव देता है कि 256-रंग पैलेट को उपयोगकर्ता की base16 थीम से अपने-आप जनरेट किया जाए, ताकि टर्मिनल में रंगों की एकरूपता और पठनीयता बेहतर हो सके
  • मौजूदा base16 थीम सरल हैं, लेकिन उनमें रंगों की संख्या सीमित होती है, जबकि truecolor में कॉन्फ़िगरेशन की जटिलता और compatibility की समस्याएँ होती हैं
  • डिफ़ॉल्ट 256-रंग पैलेट में brightness असंतुलन, थीम mismatch, और गलत interpolation जैसी समस्याओं के कारण दृश्य गुणवत्ता कम होती है
  • LAB color space interpolation का उपयोग करके base16 रंगों से विस्तारित पैलेट बनाया जाए, तो एकसमान brightness और contrast बनाए रखते हुए अधिक समृद्ध रंग अभिव्यक्ति संभव है
  • कई प्रमुख टर्मिनल (जैसे Ghostty, iTerm2, SwiftTerm) इसे पहले ही लागू कर रहे हैं, और मानकीकृत auto-palette generation feature पूरे टर्मिनल ecosystem की गुणवत्ता सुधार सकता है

256-रंग पैलेट का अवलोकन

  • 256-रंग पैलेट 16 बेसिक रंगों, 216-रंग cube, और 24-स्तरीय grayscale से मिलकर बना होता है
    • बेसिक 16 रंगों में काला, सफेद, primary colors और उनके bright variants शामिल हैं
    • 216-रंग cube की गणना RGB के हर channel में 6 स्तर (0~5) का उपयोग करके की जाती है: 16 + (36 * R) + (6 * G) + B
    • grayscale काला और सफेद के बीच 24 स्तरों से बनता है: 232 + S (जहाँ S, 0~23 है)
  • यह संरचना 24-bit RGB का सरल संस्करण है, जो रंगों की संख्या कम रखते हुए भी पर्याप्त अभिव्यक्ति देती है

मौजूदा 256-रंग पैलेट की समस्याएँ

  • Base16 थीम के साथ असंगति के कारण रंग टकराव होते हैं
    • डिफ़ॉल्ट पैलेट अधिकांश base16 थीम के साथ मेल नहीं खाता
  • गलत रंग interpolation के कारण डार्क बैकग्राउंड पर पठनीयता घटती है
    • डिफ़ॉल्ट पैलेट की पहली shade वास्तविकता से अधिक उजली गणना होती है, जिससे contrast कमज़ोर पड़ता है
  • असमान contrast की समस्या
    • पूरी saturation वाले रंग उपयोग होने से brightness balance बिगड़ता है, और एक ही स्तर पर भी नीला, हरे से अधिक गहरा दिखाई देता है

पैलेट जनरेशन का तरीका

  • समाधान यह है कि उपयोगकर्ता के base16 रंगों से 256-रंग पैलेट अपने-आप जनरेट किया जाए
    • base16 के 8 बेसिक रंगों को 216-रंग cube के 8 कोनों पर map किया जाए
    • background color और foreground color का उपयोग करके trilinear interpolation से cube बनाया जाए
    • LAB color space का उपयोग करके रंगों के बीच दृश्य brightness consistency बनाए रखी जाए
  • grayscale को background से foreground तक simple interpolation से बनाया जाता है
  • Python उदाहरण कोड में rgb_to_lab, lab_to_rgb, lerp_lab फ़ंक्शनों का उपयोग करके conversion किया जाता है

इम्प्लीमेंटेशन और अपनाने की स्थिति

  • प्रस्तावित कोड public domain में जारी किया गया है, इसलिए इसे स्वतंत्र रूप से संशोधित और उपयोग किया जा सकता है
  • Ghostty, iTerm2, SwiftTerm जैसे प्रमुख टर्मिनल में यह पहले ही लागू किया जा चुका है
  • kitty, Wezterm, Tabby, Windows Terminal आदि में भी इसे लागू करने के अनुरोध या विकास जारी हैं
  • कुछ डेवलपर्स ने OKLAB/OKLCH color space के उपयोग का सुझाव दिया है, और प्रोजेक्ट Ghostty के निर्णय के अनुसार standard color space को एकरूप करने की योजना रखता है
  • Python script के ज़रिए सीधे पैलेट लागू किया जा सकता है, या टर्मिनल config files अपने-आप जनरेट की जा सकती हैं

निष्कर्ष और प्रस्ताव

  • डिफ़ॉल्ट 256-रंग पैलेट में पठनीयता की कमी और थीम असंगति होने के कारण प्रोग्राम डेवलपर्स इसे पसंद नहीं करते
  • अगर टर्मिनल base16 थीम के आधार पर 256-रंग पैलेट अपने-आप जनरेट करे, तो ये फायदे मिल सकते हैं
    • config file के बिना भी विस्तृत रंग रेंज का उपयोग संभव
    • light/dark mode switching के समय डेवलपर के हस्तक्षेप की ज़रूरत नहीं
    • व्यापक टर्मिनल compatibility बनी रहती है
  • प्रस्ताव रखने वाले का ज़ोर है कि यह feature डिफ़ॉल्ट रूप से सक्षम (opt-out) होना चाहिए, और लंबे समय में मानक feature बन जाना चाहिए

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

1 टिप्पणियां

 
GN⁺ 2026-02-19
Hacker News की राय

  • 256-रंग पैलेट की अच्छी बात यह है कि 16–255 रंग स्थिर होते हैं
    इसलिए, उदाहरण के लिए, आप भरोसा कर सकते हैं कि 146 हमेशा ‘हल्का बैंगनी’ होगा
    यह उन color theme डेवलपर्स के लिए बहुत उपयोगी है जो अलग-अलग terminal emulator में एकसमान रंग अनुभव देना चाहते हैं
    अगर 256-रंग पैलेट किसी बदलने योग्य 16-रंग पैलेट से बनाया जाए, तो 146 अपेक्षित रंग न भी हो सकता है
    16–255 रेंज का 0–15 की तरह अस्थिर हो जाना मुझे गलत दिशा लगता है

    • सिर्फ 16 रंगों का उपयोग करना सीमित है, लेकिन CLI/TUI डेवलपर्स के लिए उस दायरे से बाहर मनमाने color theme बनाना असुविधाजनक है
      इससे दृष्टिबाधित, color blindness वाले, या सफेद background पसंद करने वाले लोगों के लिए पठनीयता घटती है
      आखिरकार, उपयोगकर्ता को terminal के default colors के साथ-साथ हर app की color settings भी अलग से करनी पड़ती हैं
      terminal सुंदर UI के लिए नहीं, बल्कि दक्षता के लिए उपयोग होता है। अगर सुंदरता चाहिए, तो web frontend बना लें
    • terminal के रंगों का उपयोग style नहीं, अर्थ (semantic) के आधार पर होना चाहिए
      हमें ‘एकसमान अनुभव’ नहीं चाहिए। रंगों का उपयोग संयम से, और उपयोगकर्ता की settings का सम्मान करते हुए होना चाहिए
    • अगर आपको पता भी हो कि 146 ‘हल्का बैंगनी’ है, तब भी background color जाने बिना उसका मतलब नहीं है
      background खुद बैंगनी हो सकता है, या सफेद background पर बैंगनी text हो सकता है
      यानी, अगर app को मेरे terminal की color configuration नहीं पता, तो उसे वह रंग इस्तेमाल नहीं करना चाहिए
    • यह feature वास्तव में color theme डेवलपर्स के लिए नहीं, बल्कि अपने palette खुद बनाने वाले users के लिए ज्यादा उपयुक्त है
      मैं default base16 theme इस्तेमाल करता हूँ, और तीसरे पक्ष द्वारा बनाए गए theme से उसके मेल खाने की अपेक्षा नहीं रखता
      terminal-स्तर और app-स्तर के color approach का अंतर मुझे दार्शनिक मुद्दे के ज्यादा करीब लगता है
    • iTerm2 जैसे terminal पहले से Minimum Contrast feature देते हैं, लेकिन इससे कभी-कभी रंग बहुत ज्यादा बिगड़ जाते हैं

  • मैंने Streamdown नाम का एक streaming Markdown renderer बनाया है
    HSV के आधार पर अगर आप सिर्फ एक base color तय करें, तो बाकी अपने-आप उसी रंग के गुणकों के रूप में समायोजित हो जाते हैं
    उदाहरण के लिए, गहरे elements की saturation कम की जा सकती है, और symbols को अधिक जीवंत बनाया जा सकता है
    settings में HSV को थोड़ा-सा बदलने पर पूरा tone स्वाभाविक रूप से बदल जाता है, इसलिए हर रंग को अलग-अलग ठीक करने की जरूरत नहीं पड़ती
    उदाहरण code भी है

  • सिर्फ 16-रंग default palette में भी समस्या है
    ‘black’, ‘white’, ‘bright black’, ‘bright white’ वास्तव में lightness contrast का अर्थ देने चाहिए, लेकिन इनके नाम रंगों पर आधारित हैं
    मैं इन्हें ‘background में लगभग न दिखने वाला रंग’, ‘उच्च contrast वाला रंग’, ‘दिखे लेकिन हल्का रंग’, और ‘सबसे अधिक contrast वाला रंग’ के रूप में समझता हूँ
    काश इन्हें रंग-नामों से नहीं, बल्कि contrast-केंद्रित तरीके से परिभाषित किया गया होता

    • सही तरीका यह है कि terminal colors को बदले बिना program में अलग रंग इस्तेमाल करने की setting दी जाए
      terminal के foreground और background color, 16-रंग standard से स्वतंत्र होते हैं, इसलिए बात और जटिल हो जाती है
    • अगर color settings नहीं दे सकते, तो bold·reverse·standout जैसी properties ही उपयोग करना बेहतर है
      और जब background पता न हो, तो काला और सफेद टालना चाहिए। 256 colors का उपयोग करते समय user-configurable theme engine होना चाहिए

  • मुझे लगता है कि यह feature हर terminal में जोड़ा जाना चाहिए
    24-bit color तक बढ़ाया जाए तो और अच्छा होगा। बस, इसे option के रूप में दिया जाना चाहिए
    उदाहरण के लिए, अगर terminal और editor दोनों में Solarized theme इस्तेमाल हो रही हो, तो color transformation दो बार लागू हो सकती है

    • 16-रंग palette से LUT (lookup table) बनाकर 24-bit color space में map करना भी संभव है
      अगर app सीधे settings override न करे और इसे environment variable से control किया जा सके, तो यह अधिक लचीला होगा

  • मैंने tinted-theming/base24 खोजा और अब उसका उपयोग कर रहा हूँ
    tinted shell की मदद से color theme आसानी से बदली जा सकती है। यह काफी अच्छा अस्थायी समाधान निकला

  • cargo/rustc में भी रंगों की कमी की समस्या है
    अगर सिर्फ default semantic colors उपयोग करें, तो आखिर में magenta, black, और white ही बचते हैं, और ये theme के हिसाब से जोखिम भरे हो सकते हैं

    • red और green को छोड़कर, मेरा मानना है कि CLI tools को रंगों पर बहुत निर्भर नहीं होना चाहिए, बल्कि text markers का समर्थन करना चाहिए

  • सीधे 24-bit true color mode उपयोग करें, तो palette की जरूरत ही नहीं रहती
    termstandard/colors के अनुसार, अधिकांश आधुनिक terminal इसे support करते हैं

    • लेकिन मूल लेख में true color के खिलाफ स्पष्ट आपत्ति भी थी
    • urxvt अब भी पूरा true color support नहीं करता
    • क्योंकि आप हर रंग को पूरी तरह नियंत्रित नहीं कर सकते, इसलिए अंततः कुछ धारणाएँ करनी पड़ती हैं। यही मुख्य बात है
    • इस चर्चा का सार true color नहीं, बल्कि 256-रंग आधारित user-configurable theme अपनाना है
    • तकनीक आगे बढ़े तो 48-bit या उससे अधिक के perceptual color standard भी संभव हो सकते हैं
      यहाँ तक कि भौतिक सीमाओं (Heisenberg uncertainty principle, quantum noise आदि) को देखें, तो शायद 6000-bit/pixel स्तर के data की जरूरत पड़े
      ऐसी कल्पनाएँ Kardashev scale या प्राचीन ब्रह्मांडीय समय की अवधारणाओं की तरह, तकनीकी प्रगति की दिशा दिखाने वाला रोचक thought experiment हैं

  • सभी users default color settings ठीक से सेट करके नहीं रखते
    कुछ terminal पूरी तरह हरेपन या नारंगीपन की ओर झुके हो सकते हैं
    default colors की saturation को पूरे palette पर लागू करने का तरीका शायद कुछ हद तक बेहतर हो सकता है

  • मैं color blind हूँ, इसलिए color theme के साथ मुझे बहुत दिक्कत हुई है
    इसलिए मैं AI model की मदद से उच्च पठनीयता वाले color combinations अपने-आप बनाता हूँ
    मेरे पसंदीदा मूल theme के आधार पर contrast बढ़ाने से चीजें काफी आसानी से दिखने लगीं
    मुझे लगता है, यह तरीका दूसरे लोगों के लिए भी उपयोगी हो सकता है

    • मैं color blind नहीं हूँ, लेकिन मुझे भी मिलती-जुलती समस्या होती है
      हर app रंगों का अलग तरह से उपयोग करता है, इसलिए कुछ theme कुछ CLI में अच्छी दिखती हैं, लेकिन कहीं और बहुत फीकी लगती हैं
      आखिरकार, हर app के लिए अलग color theme समायोजित करनी पड़ती है, जो असुविधाजनक है

  • मुझे protanomaly (लाल रंग की कमजोरी) है, इसलिए मैं ametameric इस्तेमाल कर रहा हूँ
    मुझे लगता है कि इस feature के साथ मिलाकर इस्तेमाल करने पर और बेहतर नतीजे मिल सकते हैं