OKLCH rengi nedir

(jakub.kr)

11 puan yazan GN⁺ 2025-08-26 | 1 yorum | WhatsApp'ta paylaş

OKLCH, insan görsel algısına uygun modern bir renk modelidir; renkler arasındaki parlaklık, doygunluk ve ton değişimlerinin eşit algılanmasını sağlayan algısal olarak eşit bir renk modeli özelliğine sahiptir
Yapısı Lightness (açıklık/parlaklık), Chroma (doygunluk), Hue (renk tonu) bileşenlerinden oluşur ve mevcut modellere kıyasla tutarlı renk paletleri oluşturmayı mümkün kılar
Aynı açıklık ve doygunluğu koruyup yalnızca Hue değerini değiştirerek eşit bir renk paleti üretilebildiği için UI tasarımında avantaj sağlar
sRGB/HSL'ye kıyasla öngörülebilir ton farkları ve eşit gradyanlar sunar, ancak bazı durumlarda istenmeyen renkler oluşabilir
Display-P3 gibi modern ekranlarda daha geniş renk gösterimi mümkün olur; modern tarayıcılarda CSS Color 4 ile desteklenir ve sRGB fallback işlemi de sunduğu için giderek bir web standardı haline gelmektedir

OKLCH renk modeline giriş

OKLCH, algısal eşitlik (perceptually uniform) amacıyla geliştirilmiş modern bir renk modelidir
Bu model, insanların rengi gerçekte algılama biçimine daha yakın çalıştığı için dijital tasarım ve frontend geliştirmede renklerle çalışmayı çok daha kolay hale getirir

Renk modeli temel kavramı

Renk modeli, renkleri matematiksel olarak tanımlayan ve ifade eden bir sistemdir
Yaygın model örnekleri: RGB, HSL, LCH, OKLCH, LAB, XYZ
Her model, renkleri ifade etme ve işleme kolaylığını belirler

Renk gösterim yöntemleri örnekleri

oklch(0.55 0.18 260)
hsl(220 100% 50%)
rgb(0, 128, 255)
lch(60% 60 260)
lab(50 -10 -50)
color(xyz 0.18 0.19 0.6)
#1E90FF

Gamut (renk uzayı aralığı)

Gamut, ilgili renk modelinin gösterebildiği toplam renk aralığı anlamına gelir
Temel gamut örnekleri: sRGB (web varsayılanı), Display-P3 (modern cihaz desteği)
Renk uzayı; gamut aralığının yanı sıra white point, transfer function gibi çeşitli özelliklere de sahiptir

OKLCH yapısı

OKLCH ve LCH, Lightness, Chroma, Hue olmak üzere üç değerden oluşur
OKLCH, OKLab renk uzayını temel alır

Lightness (açıklık/parlaklık): 0~1 veya 0%~100% olarak ifade edilir, parlaklıkta eşit değişimi garanti eder
Chroma (doygunluk): rengin yoğunluğunu ifade eder, HSL'deki Saturation (doygunluk) ile benzerdir
Hue (renk tonu): rengi 0~360 derecelik açıyla ifade eder

OKLCH'nin avantajları ve kullanım alanları

Tutarlı parlaklık
- OKLCH'de aynı açıklık ve doygunluk değerleriyle yalnızca hue değiştirildiğinde, tüm renkler benzer parlaklıkta algılanır
- Mevcut sRGB veya HSL'de renk türüne göre parlaklık ya da doygunluk tutarsız görünebilir
- Bu nedenle OKLCH ile algısal olarak eşit renk paletleri üretmek kolaydır
Öngörülebilir renk tonu kademeleri
- OKLCH'de parlaklık değiştirildiğinde, hue (renk tonu) veya chroma (doygunluk) değişmeden çeşitli renk kademeleri üretilebilir
- HSL gibi modellerde parlaklık değiştiğinde ton kayması (drift) görülebilir
- OKLCH, yalnızca parlaklığı ayarlayarak tutarlı renk tonu kademeleri oluşturmayı mümkün kılar
Gradyan işleme yöntemi
- sRGB'de kırmızı, yeşil ve mavi değerleri arasında enterpolasyon yapıldığı için orta noktalar kirli görünebilir veya parlaklık değişimi çok sert olabilir
- OKLCH, Lightness, Chroma, Hue eksenleri boyunca enterpolasyon yaparak daha doğal gradyanlar üretmeyi sağlar
- Ancak Hue değeri dairesel bir yapıya sahip olduğu için beklenmeyen renk sapmaları oluşabilir
- Bunu önlemek için OKLab'de doğrusal enterpolasyon (interpolation) uygulanarak daha öngörülebilir sonuçlar elde edilebilir

Renk uzayı desteği

sRGB, modern ekranların gösterebildiği geniş renk uzayının bir kısmını karşılayamaz
OKLCH kullanıldığında Display-P3 gibi geniş renk alanını destekleyen cihazlarda daha canlı renkler göstermek mümkündür
Yalnızca sRGB destekleyen cihazlarda ise olabildiğince benzer renklere eşlenir

Maksimum Chroma (doygunluk) değeri

OKLCH, ekranın gerçekte gösterebildiği aralığın dışındaki renkleri de matematiksel olarak tanımlayabilir
Örneğin oklch(0.7 0.4 40) gibi çok büyük bir chroma değeri gerçekte görüntülenemez ve en yakın renge kırpılır
Maksimum chroma kavramını anlamak ve ton, parlaklık, seçilen renk uzayına (sRGB, Display-P3) göre uygun değerler belirlemek önemlidir

Tarayıcı desteği ve fallback

OKLCH renkleri CSS Color Module Level 4 ile tanıtılmıştır ve modern tarayıcıların çoğunda desteklenir

Eski tarayıcılarda desteklenmeyebileceği için @supports CSS yönergesiyle fallback değerleri tanımlanabilir

@layer base {  
  :root {  
    /* sRGB hex */  
    --color-gray-100: #fcfcfc;  
    --color-gray-200: #fafafa;  
    --color-gray-300: #f4f4f4;  

    @supports (color: oklch(0 0 0)) {  
      /* OKLCH */  
      --color-gray-100: oklch(0.991 0 0);  
      --color-gray-200: oklch(0.982 0 0);  
      --color-gray-300: oklch(0.955 0 0);  
    }  
  }  
}

Desteklenen tarayıcılarda OKLCH, desteklenmeyenlerde ise sRGB (hex) renkleri uygulanır

oklch.fyi aracı

oklch.fyi, OKLCH renk paleti oluşturma ve CSS değişkeni dönüştürme gibi OKLCH ile ilgili işlevler sunan bir web aracıdır
Tasarım sistemleri ve tema geliştirme gibi alanlarda OKLCH renklerini kullanmayı kolaylaştırır

1 yorum

GN⁺ 2025-08-26

Hacker News görüşü

“Better Gradients” özelliği konusunda şüpheliyim. OKLCH kutupsal bir uzaydır ve bu uzayda Hue açı görevi görür. Farklı iki noktadaki renkler enterpole edilirken, yol çemberin kenarı boyunca ilerler. Örneğin linear-gradient(in oklch, #f0f, #0f0) kodunu kullanırsanız, yeşilden mora geçerken gözle görülür biçimde renk gamının dışına çıkarsınız. Çemberde diğer yönden dönerseniz linear-gradient(in oklch longer hue, #f0f, #0f0) örneğinde olduğu gibi camgöbeği veya aqua üzerinden geçersiniz. Bu yollar, algısal tabanlı bir renk uzayının sRGB ya da insanın algılayabildiği renk alanının sınırları, yani gamutun uçlarıyla uğraşırken ne kadar kullanışsız olabildiğini gösteriyor. Gerçekten de değerler çok az değişse bile renk aralığın dışına çıkıyor. Bunu çözmek için çeşitli algoritmalar var ama algısal eşitlikten ödün veriliyor. Örneğin gradyandaki kırmızı olağan dışı derecede koyulaşıyor. Daha iyi gradyanlar istiyorsanız ve algısal eşitlik önemliyse, aslında varsayılanın Oklab enterpolasyonu olması gerekir. Oklab, çemberi kesen düz bir yol üzerinden enterpolasyon yapar ve gerekirse griden de geçer (linear-gradient(in oklab, #f0f, #0f0)). Bu yöntem, sık görülen sRGB enterpolasyonundaki kararma etkisini de ortadan kaldırır ve magenta ile lime arasında doğal bir gradyan oluşturur. Bu arada Tailwind v4 beta sürümünde sRGB yerine Oklch kullanmıştı, ama final sürümde daha güvenli varsayılan olarak Oklab’ı seçti
- Tarayıcıda renkleri sRGB içinde enterpole etme yönteminin aslında bir bug gibi olduğunu düşünüyorum. sRGB logaritmik ölçekli bir kodlamadır; bu yüzden aslında spesifikasyona göre renk enterpolasyonu doğrudan sRGB’de yapılmamalı, lineer RGB’ye dönüştürülüp öyle enterpole edilmelidir
- Bu yazı düzeltildi, dolayısıyla yorumumu görmezden gelebilirsiniz. Yine de Oklab enterpolasyonunun varsayılan olması gerektiğine katılıyorum. Yazıda da “daha iyi gradyanlar” konusunda, OKLCH’nin hue değerinin dairesel olduğu ve bu yüzden beklenmedik yollar izleyebileceği söyleniyor. Bu sorunu önlemek için birçok araç OKLAB kullanıyor ve Oklab düz bir yol üzerinden tutarlı sonuçlar veriyor
- Aslında CIE LAB da aynı işi görüyor ve zaten bir standart olarak mevcut (CIE LAB Vikipedi)
  W3C inceleme materyali
- Çok faydalı bir açıklama duyduğum için teşekkür ederim. Bu yazıyı yazan kişi benim. Daha açık anlatabilmek için içeriği düzelteceğim
- Spektrumun zıt taraflarındaki iki renkle gradyan oluşturmak biraz uç bir örnek. Nasıl görünmesi gerektiğine dair doğru bir cevap da yok ve pratikte tasarımda böyle gradyanlara ihtiyaç duyulmasının nadir olduğunu düşünüyorum. Genelde tasarımda gradyan kullanırken ara renkleri zaten elle seçersiniz
OKLCH konusunda sezgi geliştirmemde oklch.com yardımcı oldu. Ancak hue değerinin HSL’deki hue ile aynı olmadığına ve hue ile lightness’e göre chroma’nın üst sınırının değiştiğine dikkat etmek gerekir. Bu bir bug değil; insan gözünü ve ekranların özelliklerini yansıtıyor. HSL’de üst sınır hep sabittir, ama renk anlamı tutarlı değildir. CSS’te OKLCH’nin güzel yanı, formül şeklinde manipüle edilebilmesidir. Örneğin oklch(from var(--accent) calc(l + .1) c h) gibi kullanılabilir. Ama formülleri gerçekten iyi kullanmak için renk teorisi bilmek ya da test yapmak gerekir. Mesela gölgede sadece lightness’i değiştirmenin yeterli olduğunu sanıyordum, ama aslında hue’nun da değişmesi gerekiyor. OKLCH gradyanları her durumda en iyisi değil. Benzer hue değerleri kullanıldığında renkler daha eşit görünse de, ışığın gerçek hayatta karışırken fiziksel olarak nasıl değiştiğini de hesaba katmak istiyorsanız XYZ renk uzayına ihtiyaç vardır. Bununla ilgili MDN color-mix belgesi faydalı olabilir. Bu arada “ok”, gerçekten sadece OK kelimesinden geliyor. Anlamı, önceki LCH’nin sorunlu olmasından, yani “OK olmamasından” türetilmiş
- CSS’te OKLCH’de formül kullanılabilmesini güzel bulduğunu söylemişsin ama aslında göreli renk manipülasyonu tüm CSS renk uzaylarında kullanılabiliyor. Örneğin background-color: rgb(from var(--base-color) calc(r - 76.5) g calc(b + 76.5)); şeklinde de kullanılabilir
- OKLCH ve göreli renkler sayesinde stil sayfasında hardcode edilen renk sayısını epey azaltabildim
  Örnek CSS değişkenleri
Bazı eleştiriler zaten dile getirilmiş olsa da, OKLCH’yi ve CSS’te nasıl uygulandığını tanıtma açısından bunun oldukça iyi bir yazı olduğunu düşünüyorum. Ek bir soru olarak, son dönemde blog yazılarında tarih belirtmeme trendini merak ediyorum. Özellikle “OKLCH yeni bir renk modelidir” ifadesinin ileride çok hızlı biçimde eskimiş görüneceğini düşünüyorum. Ana sitede yalnızca “Ağustos 2025” yazıyor; bu da sanki tarih bilerek verilmemiş gibi hissettiriyor
İlgili site
- Bunu tam açıklayamam ama tarihsiz yazıların ciddi bir sorun olduğunu düşünüyorum. Bunun güncel bir trend olup olmadığını bilmiyorum ama tarih olmayınca eski bir yazıyı yeni sanmak çok kolay oluyor. Bazen yorumlarda kalan zaman damgalarından yazının yılını tahmin etmeye çalışıyorum, ama artık yorum desteği bile olmayan bloglar çok olduğundan geri dönme isteğim kalmıyor. (OP’nin ana sayfasında “detaylara takıntılı değilim” yazıyor ama tasarım estetiğine odaklanıp işlevselliği kaçırmış olması ironik.)
- Yazıda tarih yoksa, ben HTTP ile HTML dokümanını alırken Last-Modified başlığına bakmaya çalışıyorum. Ama yazarların tarih konusunu umursamaması çok yaygın. “Blog” kelimesinden de anlaşılacağı gibi bu aslında bir [web]-log’dur ve zaman damgası temel bir unsurdur; ama bunu anlamıyor gibiler. Bu arada Last-Modified değeri, ilgili kaynağın (HTML) en son ne zaman değiştirildiğini gösterir. Sunucu cache yapılandırması yapmıyor ve backend her istekte yeniden render ediyorsa, tarihin sürekli güncellenmesi gibi bir durum ortaya çıkar
  Bu soruna örnek
- Bunun büyük kısmı, eski içeriğin arama motorlarında sıralama kaybetmesini önlemeye yönelik SEO amacı taşıyor. Gerçekten can sıkıcı bir numara
- Sebep Google ve SEO
OKLCH renklerinin HSL’ye kıyasla daha tutarlı mavi verdiği söylenmiş ama pratikte OKLCH’de parlaklık artışı yeşile doğru ciddi bir kaymaya neden oluyor. Algısal yoğunluğu sabit tutabilmesi kesin bir avantaj, ama burada öne sürülen etkinin abartıldığını hissediyorum
- Bunun nedenini bu rengin Hue grafiğinde görebilirsiniz
  OKLCH renk grafiği
  Parlaklığı artırdığınızda, o rengin Hue bandı sınırını aşıyorsunuz; ekranda üretilebilen parlak mavi tonlarının sınırı nedeniyle renk Cyan’a kayıyor. OKLCH, gradyanlarda parlaklık ayarlanırken Hue sabitliği değil Saturation sabitliği sağlıyor. Bunun iyi bir şey olup olmadığı estetik tercihe bağlı, ama uzun zamandır Hue sabit ve desaturated web renkleri kullandığımız için “hangi uzlaşma noktasını seçeceğinize karar verebilmek” taze hissettiriyor
  İlgili Hacker News tartışması
  Son dönemde bilim dünyasında daha derin mavi LED’ler de geliştirildiği için, 10-20 yıl sonra Display P3’ün yerini alacak teknolojiler geldiğinde bu Cyan kayması olmadan daha doğru mavi gradyanlar gösterebileceğimizi umuyorum. O zamana kadar tasarım açısından iyi görünen şey doğru cevaptır.
  Ayrıca gelecekteki renk uzayı tasarımlarında, Hue ve Saturation’ı kesin bir ikilik olarak seçmek yerine, ekranın sınırına kadar Saturation’ı sabit tutup sınır noktasında kademeli olarak Hue sabitliğine geçmek mümkün olabilir mi diye düşünüyorum. Ancak bu, renk profili (IDCv4) kısıtları nedeniyle çok zor. Yine de deneysel bir DisplayCAL hedefi olarak eğlenceli olabilir
- Benim ekranımda örnekte hiçbir green shift görünmüyor. Acaba ekran kalibrasyonunda bir sorun olabilir mi diye merak ediyorum
- Katılıyorum. Renk tamamen maviden siyan/camgöbeğine dönüyor. Eğer OKLCH gerçekten doğru uygulanmışsa, ben bunu asla kullanmak istemem. Hue hesabında ciddi bir sorun varmış gibi görünüyor. HSL/HSV’de algısal lightness sorunlu olabilir ama hue’nun kendisi her zaman sabittir, düzeltme gerektirmez
- Renk bilimi konusunda uzman değilim, dolayısıyla bu öznel bir görüş olabilir; ama OKLCH renklerinin en sağ ucu en kötü ihtimalle blue-green ya da sadece light blue gibi görünüyor. Buna karşılık HSL’nin en parlak iki rengi blue gibi görünmüyor; sağdan ikinci renk daha çok light purple, en sağdaki ise neredeyse gri. Başlıkta HSL’nin koyu tarafının grayish olduğu söylenmiş ama pratikte hem OKLCH hem de HSL’de en soldaki, yani en koyu tonlar mavi hissi veriyor. macOS Digital Color Meter ile bakınca, en sağdaki OKLCH ve HSL renklerinde green değeri neredeyse aynı (226 ve 227; sRGB’de 228 ve 227)
Bu konuda daha iyi bir yazı önereyim
Evil Martians’ın OKLCH in CSS: Why quit RGB, HSL yazısı
Deneyebileceğiniz OKLCH dönüştürme aracı
Önceki Hacker News tartışması (6 ay önce, 30 yorum)
OKLCH, OKLab’ı (algısal olarak eşit bir renk uzayı) temel alır ve Lightness, Chroma ve Hue’yu kontrol etmeye yönelik bir modeldir. “OK” adı, yaratıcısının “fena çalışmıyor” demesinden geliyor
- Ben OKLCH’deki “OK”nin aslında “Ottossons kulör”ün (İsveççede Ottosson’un rengi) kısaltması olduğunu tahmin ediyorum. Gerçi yaratıcısı alçakgönüllülükle gerçekten OK demiş de olabilir
Renk ve metin/logo çalışırken kontrastı ve okunabilirliği de mutlaka hesaba katmak gerektiğini düşünüyorum
APCA Contrast
- Yukarıdaki site en yeni kontrast algoritmasını (APCA, henüz yayımlanmamış WCAG 3 standardının resmî algoritması) kullanmak için iyi, ama şu anda pek çok sektörde ölçüt hâlâ WCAG 2 olduğu için yasal gereklilikleri de göz önünde bulundurmak gerekir.
  Kontrast kontrolü (WCAG 2)
  Bunun dışında da çeşitli araçlar var
Aklımda OKLCH adı doğal olarak "Oklachroma" diye çözülmüştü
OKLab renk uzayını tanıtan ilk blog yazısı var; tarihsel açıdan ilginç
OKLab orijinal yazısı
OKLCH renk uzayına dönüştürme formülünün neden dokümante edilmediğini merak ediyorum. Google’da arayınca yalnızca bir Gist bulabildim[0], Oklab için ise bir Vikipedi sayfası var[1]
Gist dönüştürme formülü örneği
Oklab Vikipedi
- Dönüşümün asıl kritik kısmı Oklab ile sRGB arasındaki matriste. OKLab-OKLCH dönüşümünün kendisi sadece bir koordinat dönüşümü ve bu zaten Vikipedi’de yer alıyor
- OKLCH ile OKLab aynı renk uzayıdır. Sadece gösterim biçimleri farklıdır: dik koordinatlar (OKLab) ve kutupsal koordinatlar (OKLCH)