- Kullanıcının base16 temasından 256 renk paletinin otomatik oluşturulmasını öneren bir yazı; terminalde renk tutarlılığı ve okunabilirliği iyileştirmenin bir yolunu sunuyor
- Mevcut base16 temaları basit olsa da renk sayısı sınırlı; truecolor ise yapılandırma karmaşıklığı ve uyumluluk sorunları taşıyor
- Varsayılan 256 renk paleti, parlaklık dengesizliği, tema uyumsuzluğu ve hatalı enterpolasyon gibi nedenlerle düşük görsel kalite sunuyor
- LAB renk uzayı enterpolasyonu kullanılarak base16 renklerinden genişletilmiş bir palet üretildiğinde, tutarlı parlaklık ve kontrast korunurken daha zengin renk ifadesi elde edilebiliyor
- Birçok büyük terminalin (ör. Ghostty, iTerm2, SwiftTerm) bunu zaten uyguladığı, standartlaştırılmış otomatik palet üretimi özelliğinin terminal ekosisteminin genel kalitesini artırabileceği belirtiliyor
256 renk paletine genel bakış
- 256 renk paleti, 16 temel renk, 216 renk küpü ve 24 kademeli gri tonlamadan oluşur
- Temel 16 renk; siyah, beyaz, ana renkler ve parlak varyantlarını içerir
- 216 renk küpü, RGB’nin her kanalında 6 seviye (0~5) kullanılarak hesaplanır:
16 + (36 * R) + (6 * G) + B
- Gri tonlama, siyah ile beyaz arasında 24 kademeden oluşur:
232 + S (S, 0~23)
- Bu yapı, 24 bit RGB’nin basitleştirilmiş bir sürümü olarak görülebilir; renk sayısını azaltırken ifade gücünü korur
Mevcut 256 renk paletinin sorunları
- Base16 temalarıyla uyumsuzluk renk çakışmalarına yol açar
- Varsayılan palet, çoğu base16 temasıyla uyumlu değildir
- Hatalı renk enterpolasyonu nedeniyle koyu arka planlarda okunabilirlik düşer
- Varsayılan paletin ilk tonu gerçekte olması gerekenden daha parlak hesaplanır ve kontrast zayıflar
- Eşit olmayan kontrast sorunu vardır
- Tam doygun renkler kullanıldığı için parlaklık dengesi bozulur; aynı seviyede bile mavi, yeşilden daha koyu görünür
Paletin oluşturulma yöntemi
- Çözüm, kullanıcının base16 renklerinden 256 renk paletini otomatik üretmek
- base16’nın 8 temel rengi, 216 renk küpünün 8 köşesine eşlenir
- Arka plan ve ön plan renkleri kullanılarak küp, trilinear interpolation ile oluşturulur
- Renkler arasında algısal parlaklık tutarlılığını korumak için LAB renk uzayı kullanılır
- Gri tonlama, arka plandan ön plana doğru basit bir enterpolasyonla üretilir
- Python örnek kodunda dönüşüm için
rgb_to_lab, lab_to_rgb, lerp_lab işlevleri kullanılır
Uygulama ve benimsenme durumu
- Önerilen kod public domain olarak yayımlandı; serbestçe değiştirilebilir ve kullanılabilir
- Ghostty, iTerm2, SwiftTerm gibi büyük terminallerde uygulama zaten tamamlandı
- kitty, Wezterm, Tabby, Windows Terminal gibi projelerde de uygulama talebi veya geliştirme süreci devam ediyor
- Bazı geliştiriciler OKLAB/OKLCH renk uzayı kullanılmasını önerdi; proje ise Ghostty’nin kararı doğrultusunda standart renk uzayını birleştirmeyi planlıyor
- Python betiğiyle palet doğrudan uygulanabiliyor veya terminal yapılandırma dosyaları otomatik üretilebiliyor
Sonuç ve öneri
- Varsayılan 256 renk paleti, okunabilirliği düşürmesi ve tema uyumsuzluğu nedeniyle program geliştiricileri tarafından kaçınılan bir seçenek haline geldi
- Terminal, base16 tema tabanlı olarak 256 renk paletini otomatik oluşturursa şu avantajlar elde edilir
- Yapılandırma dosyası olmadan da geniş renk aralığı kullanılabilir
- Açık/koyu mod geçişi sırasında geliştirici müdahalesi gerekmez
- Geniş terminal uyumluluğu korunur
- Öneriyi sunan kişi, bu özelliğin varsayılan olarak etkin (opt-out) olması ve uzun vadede standart bir özellik haline gelmesi gerektiğini vurguluyor
1 yorum
Hacker News görüşleri
256 renk paletinin güzel yanı, 16~255 arasındaki renklerin sabit olması
Bu sayede örneğin 146 numaranın her zaman ‘yumuşak bir mor’ olduğundan emin olabiliyorsunuz
Bu, farklı terminal emülatörlerinde tutarlı bir renk deneyimi sunmak isteyen renk teması geliştiricileri için çok faydalı
Eğer 256 renk paleti değişken bir 16 renk paletinden üretilirse, 146 numara beklenen renk olmayabilir
16~255 aralığının da 0~15 gibi kararsız hâle gelmesi bence yanlış bir yön
Bu, görme engelliler, renk görme bozukluğu olanlar veya beyaz arka planı tercih edenler için okunabilirliği düşürüyor
Sonuçta kullanıcıların sadece terminalin varsayılan renklerini değil, her uygulamanın renk ayarlarını da ayrıca yapılandırması gerekiyor
Terminal, güzel bir arayüz için değil verimlilik için kullanılır. Güzel bir şey istiyorsanız web frontend yapın
Biz ‘tutarlı bir deneyim’ istemiyoruz. Renkler ölçülü kullanılmalı ve kullanıcı ayarlarına saygı göstermeli
Arka plan mor olabilir ya da beyaz arka planda mor yazı olabilir
Yani uygulama terminalimdeki renk düzenini bilmiyorsa, o rengi kullanmamalı
Ben varsayılan bir base16 teması kullanıyorum ve üçüncü tarafın yaptığı temayla birebir uyuşmasını beklemiyorum
Terminal düzeyindeki ve uygulama düzeyindeki renk yaklaşımı farkının daha çok felsefi bir mesele olduğunu düşünüyorum
Streamdown adında bir streaming Markdown renderer yaptım
HSV tabanlı olarak yalnızca bir temel renk seçildiğinde, geri kalan her şey bu rengin katlarına göre otomatik ayarlanıyor
Örneğin koyu ögelerin doygunluğu düşürülüyor, semboller ise daha canlı hâle getiriliyor
Ayarlarda HSV’yi biraz değiştirseniz bile genel ton doğal şekilde değiştiği için, renkleri tek tek elden geçirmeniz gerekmiyor
Örnek kod da var
Sadece 16 renkli varsayılan paletin kendisinde de sorun var
‘black’, ‘white’, ‘bright black’, ‘bright white’ aslında açıklık-koyuluk kontrastını ifade etmeli, ama adları renk olarak verilmiş
Ben bunları ‘arka planla neredeyse görünmez renk’, ‘yüksek kontrastlı renk’, ‘görünür ama zayıf renk’, ‘en yüksek kontrastlı renk’ olarak anlıyorum
Keşke renk adları yerine kontrast merkezli tanımlansalardı
Terminalin ön plan/arka plan renkleri 16 renk standardından bağımsız olduğu için iş daha karmaşık
Arka plan bilinmiyorsa siyah ve beyazdan kaçınılmalı. 256 renk kullanılacaksa kullanıcı tarafından yapılandırılabilen bir tema motoru kullanılmalı
Bence bu özellik tüm terminallere eklenmeli
24 bit renge genişletilirse daha da iyi olur. Ancak isteğe bağlı olmalı
Örneğin Solarized temasını hem terminalde hem editörde kullanıyorsanız, renk dönüşümü iki kez uygulanabilir
Uygulamanın ayarları doğrudan ezmesi yerine ortam değişkenleriyle kontrol edilebilirse daha esnek olur
tinted-theming/base24 keşfettim ve kullanıyorum
tinted shell ile renk temaları kolayca değiştirilebiliyor. Oldukça iyi bir geçici çözüm oldu
cargo/rustc tarafında da renk yetersizliği sorunu var
Sadece varsayılan anlam renkleri kullanılırsa geriye magenta, siyah ve beyaz kalıyor; bunlar da temaya bağlı olarak riskli
Doğrudan 24 bit true color modu kullanılırsa palete gerek kalmaz
termstandard/colors ölçütüne göre, modern terminallerin çoğu bunu destekliyor
Hatta fiziksel sınırlar (Heisenberg belirsizlik ilkesi, kuantum gürültüsü vb.) dikkate alındığında 6000 bit/piksel düzeyinde veri gerekebilir
Bu tür düşünceler, Kardashev ölçeği ya da kadim kozmik zaman kavramları gibi, teknolojik ilerlemenin yönünü gösteren ilginç düşünce deneyleri
Her kullanıcı varsayılan renk ayarlarını düzgün yapmış olmuyor
Bazı terminaller tamamen yeşilimsi ya da turuncumsu olabilir
Varsayılan renklerin doygunluğunu tüm palete yansıtmak daha iyi bir yaklaşım olabilir
Ben renk körüyüm ve renk temaları yüzünden çok zorlandım
Bu yüzden AI modeli kullanarak okunabilirliği yüksek renk kombinasyonlarını otomatik üretiyorum
Eskiden sevdiğim temaları temel alıp kontrastı artırınca çok daha rahat okunur hâle geldi
Böyle bir yaklaşımın başkalarına da yardımcı olabileceğini düşünüyorum
Uygulamaların renk kullanımı farklı olduğu için, bazı temalar bazı CLI’larda iyi görünürken başka yerlerde fazla soluk kalıyor
Sonunda her uygulama için renk temasını ayrı ayrı ayarlamak zorunda kalmak can sıkıcı
Bende protanomali (kırmızı zayıflığı) var, bu yüzden ametameric kullanıyorum
Bununla birlikte kullanılırsa daha iyi sonuç verebilir gibi görünüyor