なぜxvYCC色空間が静止写真の普及を見せていないのですか?


23

過去15年間、sRGBはコンピューターモニター(および消費者レベルの印刷)の主要な標準でした。広色域LEDバックライトモニターが一般的になるにつれて、それは現在変化しています。通常、写真家はこれらを準標準であるaRGBのような色空間で使用します。たとえば、私のカメラはその空間にJPEGをネイティブに保存できます。

しかし、sRGBに代わるものとしてAV業界で広く推進されている新しい標準があります。これはIEC 61966-2-4 — xvYCC(またはマーケティング目的の場合は「xvColor」)です。この色空間の色域はsRGBより1.8倍大きく、人間の視覚の色範囲の90%をカバーします(現在の共通分母によってカバーされている意外な50%の代わりに)。ソニーのxvYCCのWebサイトで詳細を読んでください。

しかし重要な点は、これは理論的ではないということです。これは、HDMI 1.3規格の一部であり、色ごとに10〜16ビットの色深度の仕様(「ディープカラー」と呼ばれます)を備えています。基本的にプロのニッチなものであるaRGBとは異なり、消費者レベルのギアには幅広いサポートがあります。

それが背景です。問題は、これが広く受け入れられており、今後数年間ですべてのコンピューター(およびテレビ!)ハードウェアでサポートできる可能性が高いことを考えると、なぜこれが基本的にビデオのみとして販売されているのですか?カメラ業界は喜んで参加できるようです。

ソニーはこのアイデアに熱心であり、4年前にそれをサポートするビデオカメラを発売しました。Playstation 3はそれをサポートしています。Sony Alpha dSLRにも入れてみませんか?そして、ソニーだけではありません—キヤノンはそれをサポートするビデオカメラも持っています。

もちろん、RAWを撮影している場合、カメラ内のサポートは重要ではありません。コンバータソフトウェアの人々が参加する必要があります。なぜこれを推進しないのでしょうか。私の理解では、xvYCCはYCbCrの拡張であり、JPEGファイルで既に使用されています。しかし、私が文献を読んでいると、最新のMPEG規格について多くの言及がありますが、静止画像については何も見つかりません。

なぜ私たちはいいもの持てないのですか?

回答:


11

xvYCCは、色データをエンコードする特定の巧妙な方法です。YCCスキームで使用されるRGB空間の色域外の色を表現するために、以前禁止されていた値の組み合わせを使用して、YCC表現を悪用します。つまり、一部のYCCタプルは、負のRGまたはB値を持つ色にデコードします。以前は、これらは単に違法でした。xvYCCではこれらが許可されており、RGBシステムよりも大きな色域を持つディスプレイは、これらを可能な限り最高のものにすることを歓迎します。したがって、フォーマットをあまり変更せずに余分な色域を取得するのは、実際にはほとんど互換性のあるハックです。

スチル写真で使用するのは理にかなっていますか?私は本当にそうは思いません。YCCとの互換性は本当に必要ないので、ProPhoto RGBのような広色域のスペースを使用してみませんか?または、さらに良いことに、余分なビット深度を使用することは静止画に対して高価ではないので、人間の知覚可能な色域全体をカバーできるCIELABのようなものを選択してみませんか?これらすべての想像上の色をエンコードする能力が、かなりの量の色解像度を犠牲にすることのない十分なビットを持っています。

もちろん、カメラのサポートの問題は少し無関係です-もし本当に色を気にするなら、カメラから生の検出器の値を引き出して、それらから始めるべきです。そして、あなたがこれをしても、あなたはまだカメラの知覚可能な色域に閉じ込められているでしょう。また、色表現の精度は、カメラのフィルターが人間の円錐のスペクトル応答をどれだけ近似しているかにも依存します。誤解すると、目と同じように見える色がカメラによって異なって見えます。エンコーディングはそれを修正しません。実際、これは私が持っていた安価なデジタルカメラで起こりました。この場合、そのIR感度により残り火が紫色に見えました。IRを除外しても、連続スペクトルが正常に見える場合、虹や蛍光灯や鉱物(およびおそらくいくつかの染料)などのとがったスペクトルを持つものはこの効果を示します。


20

簡単に始めると、答えは「スチル写真に使用されます!」です。もう少し詳しく説明しますが、その使用は現時点ではかなりニッチです。

xvYCCのルーツ

私が知る限り、xvYCCエンコーディングはYCCエンコーディングの最新の拡張機能であり、長い形式ではY'CbCr(またはわずかに異なるYCbCr)です。YCCエンコーディングはルミナンス/クロミナンスの一部です。カラースペースはすべて、1930年代にCIEによって定式化されたL a b *(略して「ラボ」)カラースペースにほぼ根ざしています。Lab色空間も輝度/色空間であり、色の輝度はL *値でエンコードされ、色の2つの色軸はa *およびb *値でエンコードされます。a *値は緑/マゼンタ軸に沿ったクロミナンスの半分をエンコードし、b *値は青/黄色に沿ったクロミナンスの残りの半分をエンコードします軸。これらの2つの色軸は、人間の目の4色の原色感度を模倣して表すために選択されました。これは、赤/緑と青/黄色の軸のペアに沿っています(ただし、人間の視力は、青い曲線の真ん中にある小さなピークは、実際には人間の目が赤ではなくマゼンタに直接敏感であることを意味しています...したがって、ラボの緑/マゼンタ軸)

YUVエンコーディング

Y'CbCrは、おそらくYUVビデオエンコーディングの形式で最も顕著に認識されます。YUVエンコードは、ビデオ送信用の色をエンコードするために必要なスペースを削減するために特別に設計されました、帯域幅がかなり乏しい商品だった時代に戻ります。R、G、Bのトリプレットはかなりの冗長性で色をエンコードするため、RGBトリプレットとして色情報を送信するのは無駄です。YUVは、Y'CbCr輝度/クロミナンスカラーエンコーディングの低帯域幅形式であり、RGBエンコーディングの無駄な冗長性はありません。YUVは、サブサンプリング形式に応じて、フルRGB信号の2/3から1/4の帯域幅を消費できます(さらに、B&Wもサポートする個別の輝度チャンネルYに完全な詳細画像を保存しました単一のエンコード形式のカラーTV信号として)。YCCは実際には色空間ではないことに注意してください。むしろ、RGBカラー情報をエンコードする方法です。より正確な用語は空間よりも色モデル、および色モデルという用語は、RGBとYUVの両方に適用できます。

元の質問にリンクされているリファレンスから、xvYCCはY'CbCrエンコーディングの拡張形式であり、YUVよりも多くのビットでエンコードされた輝度/色情報を格納しているようです。2〜4ビットのインターリーブセットで輝度とクロミナンスをエンコードする代わりに、xvYCCは最新の10ビット値で色をエンコードします。

静止画での使用

興味深いことに、非常によく似たものを使用するDSLRカメラブランドが1つあります。キヤノンは近年、sRAWと呼ばれる新しいRAWフォーマットをカメラに追加しました。通常のRAW画像には完全なセンサーデータの直接的なベイヤーダンプが含まれていますが、sRAWは実際には真のRAW画像形式ではありません。sRAW形式にはベイヤーデータは含まれず、基になるベイヤーRGBGピクセルデータから補間された処理済みY'CbCrコンテンツが含まれます。TV時代と同様に、sRAWは、よりオリジナルの信号情報を使用して、高精度(14 bpc)でありながらスペースを節約した画像形式で輝度およびクロミナンスデータをエンコードすることを目指しています。sRAW画像は、RAW画像の40〜60%のサイズにできますが、

sRAWの利点は、コンパクトなファイル形式で高い人間の知覚色精度を維持し、ベイヤーセンサーのRGBGピクセルをより有効に活用できることです(オーバーラップサンプリングでは厄介な色モアレが発生するのではなく、sRAWはオーバーラップしないクロミナンスサンプリングを実行します)欠点は、それが真のRAW形式ではなく、色情報が完全なベイヤーセンサーから補間およびダウンサンプリングされることです。カメラの完全なRAW解像度が必要ない場合(つまり、8x10または11x16でのみ印刷する場合)、sRAWはスペースを大幅に節約できる(RAWと比較して最大60%節約できるため) )、RAWよりも高速に保存し、より高いフレームレートを提供し、フル解像度のRAWよりもセンサーによってキャプチャされたカラー情報をより有効に活用します。


非常に興味深く、有益です-ありがとう!しかし、これまでのところ、このニッチな使用が唯一のものであることにはまだ驚いています。
mattdm

1
技術的に言えば、JPEGはYCC互換の方法でデータをエンコードする別の画像形式であると考えることができると思います。JPEGのスペース節約の一部は、RGBデータを輝度/クロミナンス形式でエンコードし、その上で非可逆ブロック圧縮によりさらに圧縮されるという事実によるものです。特定のエンコーディングxvYCCは静止写真では一般的ではありませんが、考えてみると、実際には輝度/クロミナンスエンコーディングが最も一般的な形式です。
jrista

7

ほぼ完全に後方に物事があります。これは、まだ写真がビデオに「追いつく」/できないはずのケースではありません。まったく逆に、これはビデオがTIFF(一例)が提供する数十年の機能に(大体)追いついたという問題です。前に(またはそう)。

20年前には16ビット/チャネルのTIFF があまりられなかったの確かですが、その機能はすでに存在しており、16ビット/チャネル(TIFFおよびその他のさまざまな形式)はかなり一般的です。同時に、ほとんどの人が完全に十分な8ビット/チャネルを見つけているように見えることを指摘する義務があります。明らかな例として、JPEG2000は16ビット/チャンネルをサポートし、元のJPEGよりも優れた圧縮をサポートしていますが、元のJPEG仕様の使用に近いものはありません。

ほぼ同時期(実際には少し前)にxvYCCが(ほぼ)TIFFの機能に追いついていたため、openEXRファイル形式が開発されていました。最大32ビット/チャネルをサポートします。まだそれほど広く使用されているわけではありませんが、TIFFに少し似たものになり、最終的には広く使用されるようになると思います。

色空間に関する限り、xvYCCがsRGBよりも広い色域をサポートしている場合、ピクセル/ビット数が多いことは事実です。ただし、ProPhotoRGBは(一例として)はるかに広い色域を提供します-そして(正直なところ)ProPhotoRGBが既に提供しているよりも大きな色空間が必要かどうか(疑問に思う色の約13% ProPhotoRGBの表現は基本的に想像上のものであり、ほとんどの人が認識できる範囲を超えています)。

xvYCCの利点は、特定のレベルの品質を表すために必要な/使用されるデータの量を減らすことです。(特に)HDビデオの場合、帯域幅を最小限に抑えることが非常に重要です。ただし、デジタルスチルカメラの場合、帯域幅ははるかに小さな関心事です。たとえば、特定のサイズのCFカードに2倍の写真を収めることができればいいのですが、特に深刻な問題ではありません。利用可能なCFカードの最大容量を使用する人は比較的少なく、また、CFカードのコストは一般的な写真家の予算のかなりの部分を占めています。

結論:技術的な能力の観点から、xvYCCはまだ利用できないものをほとんど提供しません。

編集:もう1つポイントを追加する必要があります。デジタルカメラが普及する頃には、ほとんどのモニターのCRTに代わってLCDが使用され始めましたが、消費者向けのLCDモニターは、8ビット/チャネルのカラー解像度を超え始めています(または実際に近づいています)。通常のモニターで表示できるのが約6だったとき、10または12ビット/チャネルについて心配するのは困難でした。

また、多くの人が単純に気にしないという細かい部分もあります。彼らにとって、写真の品質は合否基準に該当します。ほとんどの人が本当に求めるのは、写真が合理的に認識できることです。私は人々がゆっくりとより良いものを期待始めているのではないか疑っていますが、何年もWalgreens(または誰)が赤毛の娘を金髪(など)に変えた後、色がまったく正確であるという考えに慣れるにはしばらく時間がかかります。

編集:実際には、JPEG 2000を超えて別のステップがあります:JPEG XR。これは、最大32ビット/チャネル(浮動小数点)HDRをサポートします。また、通常のすべてのEXIF / IPTCタイプのデータ、埋め込みカラープロファイルなどを含むことができるファイル形式も指定します。ここでの質問に関連し、ファイルがxvYCC色空間を使用することを指定する値(11TRANSFER_CHARACTERISTICSケースの誰もが心配で、構文要素、テーブルA.9)。これは(少なくともまだ)広く使用されているようには見えませんが、静止画像用のxvYCC色空間を直接サポートしています。


ありがとう。それは間違いなくそれを見る一つの方法です。これらのファイル形式とより広い色空間が存在することを知っています。私が本当に興味を持っているのは、A / Vの世界で色の深みを増すことが求められているが、消費者レベルの写真ではない理由だと思います。
mattdm

1
@mattdm:プッシュが行われた理由は、以前はなかったからだと思います。広角/高色深度は少なくとも10年間静止画撮影に利用でき、デジタルカメラがAdobe RGBをサポートしている限り(sRGBよりも広い色域を持ちますが、ラボの色域)数年。キヤノンのsRAWは、少なくとも数年間、エントリーおよび中間レベルのDSLRで利用できます。私はジェリーに同意します...ビデオは「追いつく」ドメインです。
jrista

4

それで、いくつかの研究の後に少し自分の質問に答えるために:

それがxvYCC規格ではありませんが、(JPEGエンコードは似た古い方式を採用していますので)本当にまだ私を逃れるの理由から、そこ「我々は上のいくつかの心強い動きのように見えることができます素敵なものを持っています!」少なくともMicrosoftは、より広い色域と静止画のより良いビット深度を少なくとも少しは気にかけているようだからです。

彼らは、ゆっくりと、しかし確実に、JPEG XR(以前のWindows Media Photo、その後HD Photoと呼ばれる)と呼ばれる新しいファイル形式標準を求めてきました。これは、「従来の」JPEGからの興味深い動きであり、同じ画質でより良い圧縮を提供し、(この議論のポイントまで)より高いビット深度をサポートします。

JPEG 2000もこれを行いますが、おそらくそれが使用するウェーブレット圧縮をカバーする特許に関する懸念、または何か他のもののために、それは主にフロップです。重要なポイントは次のとおりです。Microsoftは現在、JPEG XRを推進しており、Internet Explorer 9を含む多くのソフトウェアに搭載されています。2009年の時点で、これは公式の真の国際標準であり、Microsoftの「コミュニティの約束」でカバーされており、実装に対して敵対的な方法で特許を強制しません。したがって、これは将来の取り込みにかなり適しています。

そして、それに伴って、彼らはより多くのビットあたりのチャネル「などのアイデアプッシュしている高色古い16ビット-FOR-まだだ私の心の中で以来、私には面白いです」、(、すべての -channelsをビデオカードモード)。その一環として、おそらく途方もなく大きなscRGBと呼ばれる「中間」色空間があります。詳細については、こちらをご覧ください。JPEGXRでサポートされています。色のほとんどは人間の知覚の外側の「想像上の」領域にあるため、最終的な色空間としては特に有用ではないかもしれません。しかし、とにかく、ポイントは、Microsoft より高いビット深度の標準をWindowsオペレーティングシステムに統合していることであり、それでも写真その一部。少し古いCNETインタビューから:「カメラのscRGBサポートがJPEG XRに付随することを絶対に期待しています。」

しかし、それは2007年でした。4年半後、JPEG XRをサポートするカメラはもちろん、派手な広色域の高深度カラースペースはまだありません。しかし、たぶん私はただ焦ります。ここで他の回答が指摘しているように、広い色域をサポートするディスプレイハードウェアが利用可能になりつつあり、世界で最も人気のあるOSでのサポートはごく最近であり、それをサポートする最初のWebブラウザーが今月リリースされました。それが普及し、できれば最終的にChromeFirefoxで取り上げられると、画像処理プログラム(RAWコンバーターを含む)がサポートされ、カメラからの実際の直接出力が続きます。

または全体が失敗します。時間がたてば分かる。:)


2
JPEG XRの優れた機能は、計算が安価であるため、たとえば、カメラ内エンコードに実装できることです。JPEG 2000は高価です。これは確かに要因ですが、おそらく計算能力の前進はそれほど大きなものではありません。
PeterT

3

ジョンの周りにいくつかのメモを追加します...

  1. Raw画像の場合、色空間は「開発」段階で選択されるため、色空間はカメラコンテキストでJPEGについてのみ意味を持ちます。一部のカメラ(特定の場合はPentaxセミプロ)では、JPEG開発にsRGBまたはaRGBを選択できるため、おそらく3番目(またはProPhotoの場合は4番目)を追加できます。繰り返しになりますが、ほとんどの専門家は、目的の出力メディアに適した色空間で画像を取り込みます。

  2. 視聴者(および/またはデバイス)も色空間を認識し、処理できる必要があります。広色域のモニターがより一般的になりつつありますが、それでもまだ非常に少数派であり、追いつくにはしばらく時間がかかります。ちなみに、古いCRTモニターを別の方法で適切なコンピューターに接続している人はかなりいます。


xvYCCは「色空間」ではなく、せいぜいRGB色情報のエンコード形式であるという点を強調したいと思います。より広い色域をサポートするのは、色空間ではなく、より多くの情報を使用して色情報を保存し、人間が輝度と色を知覚する方法により近い形式で保存するためです。
jrista

@ jrista、IEC規格では特に「ビデオアプリケーションの拡張色域YCC色空間-xvYCC」と呼ばれていますが、これは実際には色空間であることを強く示唆しています。YCCを読んで、あなたがこれからどこから来ているのかを見て、標準を読むために100ドルを払うことを望んでいませんが、私の現在の仮定は、それが指定する拡張された方法の両方を指定することですYCCの色情報実際のより広いRGB色空間。
-mattdm

1
仕様をより深く読む必要があります。私はまだxvが何を表しているのか正確には定かではないので、おそらくそれは実際にはある種の広い色域の色空間を指します。ただし、YCCは、より多くのビットを使用していても、「色域」ではなく、単に「色域」encodingです。RGBは色空間であると言っているようなものですが、色データをエンコードする方法ではありません。A color spaceは、一連のプライマリカラーマッピング、ガンマキー、白と黒のポイント、およびいくつかの曲線を介して、各色の輝度とクロミナンスの値を定義します。
jrista

1
「xv」は「拡張値」であると推測していますが、それは単に「かっこいい」という意味かもしれません。
mattdm

1

xvYCC色空間は、おそらく古い標準を改善する新しい標準が開発されており、「次の最大のものに置き換わる前に減価する可能性のある標準に投資することを望んでいないため、スチル写真の普及は見られないでしょう」 '。彼らはVHS対ベータから学んだ。

高効率画像形式(HEIF)、MPEG-Hパート12は、コーデック固有の画像形式を派生できる構造形式を指定するファイル形式です。

HEIFには、高効率ビデオコーディング(HEVC、ISO / IEC 23008-2 | ITU-T Rec。H.265またはMPEG-Hパート2)に準拠した画像および画像シーケンスをカプセル化するための仕様も含まれています。

AppleのWWDC 2017 Keynote Video:https : //youtu.be/oaqHdULqet0? t=58m49sで言及されています

AppleのiPhone 7以降は、撮影されたものを取り、JPEGまたはHEIF形式で保存します。HEIFを使用すると、元のカメラからストレージからディスプレイへのソリューションを提供できます-損失や入力から出力への変換のない完全なインフラストラクチャ(HEIF非圧縮を使用する場合)。

MPEGがすべての機能を完全にサポートしているわけではなく(MPEGが「完全にサポートされていることはめったにない」など)、他の人がそれを行うのが簡単ではないなど、画像の完全なソリューション(ビデオ用)で最初に見えるように見えるだけですHEVC H.264、H.265、最近ではHikVisionのH.265 +のサブセットが何年もありました)。

HEIFをサポートする他のカメラを知っている場合は、コメントまたは編集してください、ありがとう。

特に高いダイナミックレンジ(センサーは色ごとに16ビット以上)で画像とビデオを記録するカメラは、多くの場合、データを処理せず(圧縮ファイルを作成)、代わりにRawデータを直接出力します。例:http:// www .jai.com / en / products / at-200ge-カメラが24〜30ビット/ピクセルを出力するか、http://www.jai.com/en/products/at-140cl-カメラが24〜36ビット/ピクセルを出力する。

CIE 1931カラースペースカメラ(およびおそらく他のカラースペース)を入手することは可能です。無限に検索したり、専門のカメラサプライヤに支払いを行って希望どおりのものを作成したりする場合は、おそらくソフトウェアを自分で書いてくださいカラースペースから他のプログラムで使用されるカラースペースに変換します。

以下は、Quest InnovationsのCondor3 CIE 1931カメラへのリンクです:http ://www.quest-innovations.com/cameras/C3-CIE-285-USB

3、4、5、または6センサーのカメラは、スペクトルをより小さな部分に分割し、チャネルごとにより多くのビットを提供し、正確な色と強度をより正確に解決できます。http//www.optec.eu/en/telecamere_multicanale/telecamere_multicanale.asp


3チャンネルカメラのプリズム 3CCDまたは3MOS

4チャンネルカメラのプリズム 4CCDまたは4MOS

5チャンネルカメラのプリズム 5CCDまたは5MOS


参照:

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.