Neden xvYCC renk alanı hala fotoğraf çekimi için alım yapmıyor?

Son onbeş yıldır, sRGB bilgisayar monitörleri (ve tüketici düzeyinde baskı için) için ana standart olmuştur. Artık, gamut LED arkadan aydınlatmalı monitörler yaygınlaştıkça, bu durum değişiyor. Genellikle fotoğrafçılar bunları yarı standart olan aRGB gibi bir renk alanıyla kullanırlar - örneğin kameram JPEG'leri o alanda doğal olarak kaydedebilir.

Ancak, AV endüstrisinde sRGB’nin yerini almak için yaygın olarak itilen yeni bir standart var. Bu, IEC 61966-2-4 - xvYCC'dir (veya pazarlama amacıyla "xvColor"). Bu renk alanı, insan görüşünün renk aralığının% 90'ını (mevcut ortak paydamızın kapladığı sönmeyen% 50 yerine) kapsayan, sRGB'den 1.8 × daha büyük bir gamı ​​vardır. XyYCC'deki Sony web sitesinde daha fazlasını okuyun .

Önemli olan, bunun teorik olmadığıdır. HDMI 1.3 standardının bir parçası ve her renk için 10 ila 16 bit renk derinliği belirtimi ("Deep Color" olarak adlandırılır). Temel olarak profesyonel bir niş olan aRGB'den farklı olarak, tüketici düzeyinde donanım konusunda geniş destek var.

Bu arkaplan. Soru şudur: bunun yaygın olarak yakalandığı ve önümüzdeki birkaç yıl içinde onu destekleyebilecek bilgisayar (ve TV!) Donanıma sahip olacağımız göz önüne alındığında, bu neden sadece bir video olayı olarak satılıyor ? Kamera endüstrisi uçağa binmekten mutlu olacak gibi görünüyor.

Sony bu fikir için büyük ve dört yıl önce onu destekleyen video kameralar başlattı. Playstation 3 bunu destekliyor, Allah aşkına! Neden onu Sony Alpha dSLR’lere de koymuyorsunuz? Sony de yalnız değil - Canon'un da desteklediği video kameraları var.

Elbette, RAW çekim yapıyorsanız, kamera içi destek önemli değildir. Bu, gemiye binmesi gereken insanların yazılımı - neden bunun için bir baskı yok? Anladığım kadarıyla, xvYCC, zaten JPEG dosyalarında kullanılan bir YCbCr uzantısıdır . Ancak literatürü okuduğumda, güncellenmiş MPEG standartlarından bahsettim, fakat fotoğrafik görüntüler hakkında hiçbir şey bulamadım.

Neden olamaz biz güzel şeyler var mı?

xvYCC, renk verilerini kodlamanın akıllıca bir yoludur: YCC şemasında kullanılan RGB alanının gamutu dışındaki renkleri temsil etmek için önceden yasaklanmış değerlerin kombinasyonlarını kullanarak YCC temsilini kötüye kullanır. Yani, bazı YCC tüpleri negatif RG veya B değerleri olan renklerin kodunu çözer. Önceden bunlar basitçe yasa dışıydı; xvYCC'de bunlara izin verilir ve RGB sisteminden daha büyük gamları olan ekranlar bunları olabildiğince iyi hale getirebilir. Bu yüzden formatı değiştirmeden fazladan biraz gamut almak gerçekten akıllıca bir kesmek.

Durağan fotoğrafçılıkta kullanmak mantıklı mı? Ben öyle düşünmüyorum. YCC ile uyumlu olması gerçekten gerekmiyor, peki neden ProPhoto RGB gibi geniş bir gamı ​​kullanmıyorsunuz? Daha da iyisi, ekstra bit derinliği kullanmak fotoğraflar için pahalı olmadığından, neden tüm insanın algılayabildiği gamı ​​kapsayabilecek CIELAB gibi bir şeyle gitmiyorsunuz? Tüm bu hayali renkleri kodlama kabiliyetinin size kayda değer miktarda renk çözünürlüğü getirmesi için yeterli bitiniz yok.

Tabii ki, kamera desteği sorusu biraz da ilgisizdir - eğer gerçekten renkleri önemsiyorsanız kameradan ham detektör değerlerini çekmeli ve onlardan başlamalısınız. Ve bunu yapsanız bile, hala kameranın algılanabilir gamında sıkışıp kalacaksınız. Ve renk gösteriminin doğruluğu aynı zamanda kameranızın filtrelerinin insan konilerinin spektral tepkisine ne kadar yaklaştığına bağlı olacaktır - yanlış anlama ve gözle aynı görünen renkler kameranıza farklı görünecektir. Hiçbir kodlama sorunu çözmez. Aslında bu, sahip olduğum ucuz bir dijital kamerayla oldu - bu durumda IR hassasiyeti, közlerin mor görünmesine neden oldu. IR'yi ekrandan çıkarsanız bile, gökkuşağı ve flüoresan lambaları veya mineraller (ve bazı boyalar gibi) gibi sivri spektrumları olan şeyler, süreklilik spektrumları iyi göründüğünde bu etkiyi gösterecektir.

Basitçe başlamak için, cevabı "Hala fotoğrafçılık için kullanılır!" Birazdan biraz daha açıklayacağım ve kullanımı şu anda oldukça niş.

XvYCC'nin kökleri

XvYCC kodlaması, söyleyebileceğim kadarıyla, YCC kodlamada veya uzun formunda, Y'CbCr'de (veya biraz farklı olan YCbCr'de) modern bir gelişmedir. 1930'larda CIE tarafından formüle edilen büyük ölçüde L a b * (kısa 'Lab') renk alanından oluşan renk uzayları. Laboratuar renk uzayı, ayrıca bir rengin parlaklığının L * değerinde kodlandığı bir Renk / Krom renk alanıdır, bir rengin iki renklilik ekseni a * ve b * değerlerinde kodlanır . A * değeri yeşil / macenta ekseni boyunca kromlamanın bir yarısını kodlarken , b * değeri mavi / sarı boyunca kromlamanın diğer yarısını kodlareksen. Bu iki renkli eksen, insan gözünün dört renk birincil hassasiyetini taklit etmek ve temsil etmek için seçildi, ayrıca kırmızı / yeşil ve mavi / sarı bir çift eksen boyunca da uzanıyor (gerçek insan görüşü çift-tepe kırmızı bir eğri içermesine rağmen) Mavi eğrinin ortasında meydana gelen daha küçük tepe, bu aslında insan gözünün kırmızıya değil doğrudan macentaya karşı hassas olduğu anlamına geliyor ... yani Lab'deki yeşil / macenta ekseni.)

YUV Kodlaması

Y'CbCr muhtemelen YUV video kodlama biçiminde en belirgin şekilde tanınır. YUV kodlaması, video iletimi için rengi kodlamak için gerekli alan miktarını azaltmak için özel olarak tasarlanmıştır, bant genişliğinin oldukça az bulunan bir mal olduğu günlerde. Renk bilgisini RGB üçlüsü olarak iletmek zahmetlidir, çünkü R, G, B üçlüsü, renkleri fazla miktarda yedeklemeyle kodlar: üç bileşen de parlaklık bilgisinin yanı sıra krominans bilgisi içerir ve parlaklık her üç bileşen arasında ağırlıklandırılır. YUV, RGB kodlamanın israfı fazlalığına sahip olmayan düşük bant genişliğine sahip bir Y'CbCr parlaklık / krominans renk kodlaması biçimidir. YUV, alt örnekleme formatına bağlı olarak tam bir RGB sinyalinin bant genişliğinin 2/3 ila 1 / 4'ü kadar herhangi bir yerde tüketebilir (ve ayrıca, tüm detay görüntüsünü, her iki B&W'yi de rahatça destekleyen ayrı parlaklık kanalı Y'de depoladı. Color TV'nin tek bir kodlama formatı ile sinyal göndermesi gibi.) YCC'nin gerçekten bir renk alanı olmadığı açıkça belirtilmelidir. aksine RGB renk bilgisini kodlamanın bir yoludur. Ben daha doğru bir terim olacağını düşünüyorumrenk uzayından çok renk modeli ve renk modeli terimi RGB ve YUV'ye uygulanabilir.

Orijinal soruya bağlanan referanstan, xvYCC'nin YUV'den daha fazla bit ile kodlanmış parlaklık / renk renk bilgisini depolayan gelişmiş bir Y'CbCr kodlama biçimi olduğu anlaşılmaktadır. 2-4 bit arası serpiştirilmiş kümelerdeki parlaklık ve renklilik kodlamak yerine, xvYCC modern 10 bitlik değerlerde renk kodlar.

Fotoğrafta Kullanım

Şaşırtıcı bir şekilde, çok benzer bir şey kullanan bir DSLR kamera markası var. Canon, son yıllarda kameralarına RAW adı verilen yeni bir RAW formatı ekledi. Normal bir RAW görüntü, tam sensör verilerinden oluşan doğrudan bir bölme dökümü içeriyor olsa da, sRAW aslında gerçek bir RAW görüntü biçimi değildir. SRAW formatı bayer verisi içermez, altta yatan bayer RGBG piksel verisinden enterpolasyonlu işlenmiş Y'CbCr içeriğini içerir. TV günlerine benzer şekilde, sRAW, parlaklık ve krominans verilerini yüksek hassasiyette (14 bpc), ancak yer kazandıran, görüntü formatında kodlamak için daha orijinal sinyal bilgilerini kullanmayı amaçlamaktadır. Bir SRAW görüntü, RAW görüntünün% 40-60'ı arasında herhangi bir yerde olabilir,

SRAW'ın avantajı, kompakt bir dosya biçiminde yüksek insan-algısal renk doğruluğunu korumanız ve bayer sensördeki RGBG piksellerini daha iyi kullanmanızdır (kötü renk hareli üreten üst üste binen örneklemeden ziyade, sRAW üst üste binmemiş krom örneklemesi yapar. ve örtüşen / dağıtılan parlaklık örneklemesi.) Dezavantajı, gerçek bir RAW formatı olmaması ve renk bilgilerinin tam bayer sensöründen enterpolasyonlu ve altörneklenmiş olmasıdır. Kameranın tam RAW çözünürlüğüne ihtiyacınız yoksa (yani, yalnızca 8x10 veya 11x16'da yazdırmayı planlıyorsanız), o zaman yer tasarrufu sağlar (RAW'a kıyasla% 60'a varan oranda tasarruf sağlar) ), daha yüksek kare hızı sağlayarak hammaddeden daha hızlı tasarruf sağlar ve sensör tarafından yakalanan renk bilgisini tam çözünürlüklü RAW'tan daha iyi kullanır.

Neredeyse tamamen geriye doğru olan şeyler var. Bu, fotoğraf çekiminin videoyla "yakalayabileceği / yakalayabileceği" bir durum değil - tam tersine, bu, videonun sonunda TIFF'in (örneğin bir) birkaç on yıl boyunca sağladığı yetenekleri (kabaca) yakalamasından kaynaklanıyor. önce (ya da öylesine).

Kesinlikle vermemekle birlikte bakın 20 yıl önce çok sayıda 16 bit / kanal TIFF, yetenek zaten oradaydı ve (TIFF ve diğer çeşitli biçimlerde) 16 bit / kanal artık oldukça yaygındır. Aynı zamanda, çoğu insanın 8 bit / kanal tamamen yeterli bulduklarını belirtmek zorundayım. Sadece açık bir örnek için, JPEG2000 16 bit / kanalı ve orijinal JPEG'den daha iyi sıkıştırmayı destekler - ancak orijinal JPEG spesifikasyonunun kullanımına bile yakın değildir.

Aynı zaman zarfında (aslında biraz önce) xvYCC, (kabaca) TIFF'in yeteneklerini yakalamak için çalışıyordu, openEXR dosya formatı geliştiriliyordu. 32 bit / kanala kadar destekler. Henüz bu kadar geniş bir kullanım alanı olmasa da, biraz daha TIFF gibi olacağını ve sonunda daha geniş bir kullanıma gireceğini umuyorum.

Renk alanı gittiğinde, xvYCC, sRGB'den daha büyük bir gamı ​​destekliyorsa, daha fazla bit / piksel sayısı olduğu doğrudur. Yine de, ProPhotoRGB (bir örnek için) çok daha geniş bir renk yelpazesi sunar - ve (dürüst olmak gerekirse) ProPhotoRGB’in sağladığından daha büyük bir renk alanına ihtiyaç olup olmadığına bazı sorulara açıktır (kabiliyetli renklerin kabaca% 13’ü ProPhotoRGB’de temsil, temelde hayalidir - çoğu insanın algılayabileceğinin ötesine geçerler).

XvYCC'nin avantajı, belirli bir kalite seviyesini temsil etmek için ihtiyaç duyulan / kullanılan veri miktarını azaltmaktır. HD video için (özellikle), bant genişliğinin en aza indirilmesi son derece önemlidir. Bununla birlikte, dijital fotoğraf makineleri için, bant genişliği çok daha küçük bir endişe kaynağıdır - (örneğin) CF kartın belirli bir boyutuna iki kat daha fazla resim sığabilseydim kesinlikle iyi olurdu, ancak bu özellikle ciddi bir sorun değil. Nispeten az sayıda insan mevcut olan en yüksek CF kart kapasitesini kullanmaktadır ve CF kartların maliyeti tipik bir fotoğrafçının bütçesinin önemli bir bölümünü teşkil etmemektedir.

Alt satır: teknik yetenekler açısından, xvYCC zaten mevcut olmayan çok az şey sağlar.

Düzenleme: Muhtemelen bir nokta daha eklemeliyim. LCD'ler, dijital kameraların yaygın olarak kullanıldığı zamanla ilgili çoğu monitör için CRT'lerin yerini almaya başladı - ancak tüketici sınıfı LCD monitörler ancak şimdi 8 bit / kanal renk çözünürlüğünü aşmaya başladı (veya hatta yaklaşıyor). Tipik bir monitör yalnızca 6 civarında görüntüleyebildiği zaman, 10 veya 12 bit / kanala sahip olmak konusunda çok endişelenmek zordu.

Ayrıca pek çok insanın umursamadığı küçük detaylar da var. Onlar için, fotoğraf kalitesi başarılı / başarısız kriterine düşüyor. İnsanların istediği çoğu kişi, bir resmin makul şekilde tanınabilir olması. İnsanların yavaş yavaş daha iyi bir beklenti beklediklerinden şüpheleniyorum , ancak yıllarca süren Walgreens (veya kim olursa olsun) kızıl saçlı kızlarını sarışına (vb.) Dönüştürdükten sonra, rengin hiç doğru olabileceği fikrine alışmak biraz zaman alıyor.

Düzenleme: Aslında JPEG 2000: JPEG XR ötesinde bir adım daha var . Bu, 32 bit / kanal (kayan nokta) HDR'ye kadar destekler. Ayrıca, tüm olağan EXIF ​​/ IPTC tipi verileri, gömülü renk profilini vb. İçerebilecek bir dosya formatı belirtir. Burada, bir dosyanın xvYCC renk alanını kullanması gerektiğini belirten bir değer içeren bir soru bulunur. 11içinde TRANSFER_CHARACTERISTICSdurumda herkes bakımları sözdizimi elemanı, masa A.9). Bu, geniş kullanımda (en azından henüz) görünmüyor, ancak hareketsiz görüntüler için doğrudan xvYCC renk alanını destekliyor.

Bu yüzden, biraz araştırmadan sonra kendi soruma cevap vermek için:

O xvYCC olmasa da (JPEG kodlama benzer eski düzeni kullanır beri), gerçekten hala beni kurtulmak nedenlerle, orada yok bazı cesaret verici hamle gibi görünen "Biz yapabilirsiniz güzel şeyler var!" cepheye göre, çünkü en azından Microsoft en azından biraz daha geniş renk yelpazesine ve fotoğraf çekiminde daha iyi bit derinliğine önem veriyor.

JPEG XR (eski adıyla Windows Media Photo ve ardından HD Fotoğraf) olarak adlandırılan yeni bir dosya formatı standardını yavaş ama kesin bir şekilde zorluyorlardı . Aynı resim kalitesinde daha iyi sıkıştırma ve (bu tartışmanın noktasına göre) daha yüksek bit derinliği desteği sunan "geleneksel" JPEG'den ileriye doğru ilginç bir hareket.

JPEG 2000 bunu da yapar, ancak büyük olasılıkla kullandığı dalgacık kompresyonunu kapsayan patentlerle veya belki başka bir şeyle ilgili endişeler nedeniyle bir flop olmuştur. Önemli nokta şudur: Microsoft, Internet Explorer 9 da dahil olmak üzere pek çok yazılımıyla JPEG XR'yi destekliyor . 2009 itibariyle resmi bir uluslararası standarttır ve patentlerini uygulamalara karşı düşmanca bir şekilde uygulamamak için Microsoft'un "Topluluk Sözü" kapsamındadır. Yani bu gelecekteki alımı için oldukça iyi.

Ve bununla birlikte, daha-bit kanal başına "olarak fikrini itiyorsun yüksek renk eski 16 bit-için- hala aklımda beri bana komik", (, bütün -kanallannı video kartı modu). Bunun bir parçası olarak, scRGB adlı, muhtemelen gülünç derecede büyük bir "ara" renk boşluğuna sahipler - isterseniz, JPEG XR tarafından desteklenen, burada güzel ve ayrıntılı bir hesap okuyun . Renklerin çoğu insan algısının dışındaki "hayali" alanda olduğu için, son bir renk aralığı olarak özellikle kullanışlı olmayabilir . Ama yine de, gelin, Microsoft edilir edilir , Windows işletim sistemine daha yüksek bit-derinlik standartları entegre ve hala fotoğrafçılık olduğunubunun bir parçası. Biraz eski bir CNET röportajından : "Kameralardaki scRGB desteğinin JPEG XR'ye eşlik etmesini bekliyorum."

Ancak bu 2007’di. Dört buçuk yıl sonra, fantezi geniş gamı ​​yüksek derinlikli renk alanlarını bir arada bırakıp JPEG XR destekli kameralar görmüyoruz. Ama belki de sadece sabırsız oluyorum. Buradaki diğer cevaplara dikkat çektiğiniz gibi, geniş gamı ​​destekleyen ekran donanımı yeni kullanıma sunuluyor, dünyanın en popüler işletim sistemi desteği oldukça yeni ve bunu destekleyen ilk web tarayıcısı bu ay piyasaya sürüldü . Bu durum yakalanır ve umarım sonunda Chrome ve Firefox tarafından yakalanırsa , görüntü işleme programları (RAW dönüştürücüler dahil) destek alır ve kameralardan gelen gerçek doğrudan çıktılar takip eder.

Yoksa her şey patlayacak. Zaman gösterecek. :)

Jon'un çevresine birkaç not ekleyeceğim ...

1. Renk alanı yalnızca JPEG'ler hakkında konuşurken kamera bağlamında anlamlıdır çünkü Ham görüntüler için renk alanı "geliştirme" aşamasında bir seçimdir. Bazı kameralar (bazıları için Pentax yarı profesyonel) JPEG geliştirme için sRGB veya aRGB seçimine izin veriyor, bu yüzden belki de üçüncü (veya ProPhoto için dördüncü) ekleyebilirler. Sonra tekrar, çoğu profesyonel için, amaçlanan çıktı ortamı için görüntüyü istenen renk alanında çeker.

2. İzleyici (ve / veya cihaz) da renk boşluğunun farkında olmalı ve onu kullanabilmelidir. Geniş renk gamı ​​monitörleri daha yaygın hale gelirken, büyük olasılıkla hala büyük bir azınlıktır ve yakalanması biraz zaman alabilir. Heck, hala eski CRT monitörleri, aksi halde iyi bilgisayarlara bağlı olan birkaç kişi biliyorum.

XvYCC renk alanı muhtemelen fotoğrafçılık için bir çekim görmüyor, çünkü eski Standartlarda bir gelişme olan yeni Standartlar geliştirildi ve hiçbir Üretici, bir sonraki “en büyük şey” ile değiştirilmeden önce değer kaybetebilecek bir Standarda yatırım yapmak istemiyor. '. VHS'den Beta'ya kadar öğrendiler.

Yüksek Verimli Görüntü Formatı (HEIF), MPEG-H Bölüm 12, kodek-spesifik görüntü formatlarının türetilebileceği yapısal bir format belirten bir Dosya Formatıdır.

HEIF ayrıca, Yüksek Verimli Video Kodlamasına (HEVC, ISO / IEC 23008-2 | ITU-T Rec. H.265 veya MPEG-H Bölüm 2) uygun görüntülerin ve görüntü dizilerinin kapsüllenmesi için şartname içerir.

Apple’ın WWDC 2017 Keynote Video’unda: https://youtu.be/oaqHdULqet0?t=58m49s .

Apple'ın iPhone 7 ve üstü fotoğraflarını çekiyor ve JPEG veya HEIF formatlarında kaydediyor. HEIF kullanımı, Görüntülenecek Depolama için görüntüye el değmemiş bir çözüm sağlayabilir - kayıpsız veya girdiden çıktıya dönüştürme olmadan tam bir Altyapı sağlayabilir (HEIF sıkıştırılmamış kullanılırken).

Her özelliği tam olarak desteklemiyorlar (MPEG nadiren "tam olarak destekleniyorsa" gibi) veya başkasının yapması için yeterince kolay olmadığı gibi, sadece Görüntüler için tam bir çözümle ilk göründüğü gibi (Video için) HEVC H.264, H.265 ve son yıllarda HikVision'ın H.265 + 'ının bir alt kümesine sahibiz).

HEIF’i destekleyen diğer Kameralar’ı biliyorsanız, lütfen yorum yapın veya düzenleyin, teşekkürler.

Görüntüleri ve Videoları özellikle yüksek bir Dinamik Aralıkta kaydeden kameralar (Sensör renk başına 16 Bit'in üzerindedir) genellikle Verileri işlemez (sıkıştırılmış bir Dosya), ancak bunun yerine Ham Verileri doğrudan verir, örnek: http: // www .jai.com / tr / products / at-200ge - Kamera piksel başına 24 ila 30 Bit veya http://www.jai.com/tr/products/at-140cl çıktı - Kamera piksel başına 24 ila 36 Bit çıkarır. .

Kesin olarak ararsanız veya tam olarak ne istiyorsan onu yapmak için özel bir kamera tedarikçisini ödemeye razıysanız, bir CIE 1931 renkli alan Kamera (ve muhtemelen başka Renk Alanlar) elde etmek mümkündür. Renk Alanınızdan diğer Programlar tarafından kullanılana dönüştürün.

Quest Innovations 'Condor3 CIE 1931 Kamerası için bir Bağlantı: http://www.quest-innovations.com/cameras/C3-CIE-285-USB .

3,4,5 veya 6 Sensörlü Kameralar, Spektrumu daha küçük parçalara bölebilir ve Kanal başına daha fazla Bit sağlayabilir, böylece tam renk ve yoğunluğu daha kesin olarak çözer: http://www.optec.eu/en/telecamere_multicanale/telecamere_multicanale.asp .

3CCD veya 3MOS

4CCD veya 4MOS

5CCD veya 5MOS

Referanslar:

https://developer.apple.com/videos/play/wwdc2017/503/

https://nokiatech.github.io/heif/technical.html

https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format