問題タブ [gamma]

IE8で正しく表示できるように、ガンマ情報のない画像を作成しようとしています。次のコードを使用しましたが、結果として元の画像とはまったく異なる歪んだ画像になります。

これが元の画像と上記のコードから生じた歪んだ画像です。

ありがとう！

Lightroom 3.4のトーンカーブツールが特許を取得しているかどうか誰かが知っていますか？同様の機能を画像処理ソフトウェアに実装したいと思います。

色空間。RGB については誰もが知っています。[0.0,1.0] の範囲で正規化された 3 つの値は、赤、緑、青の色成分の強度を意味します。この強度は線形を意味していますね。

ガンマ。私が理解できる限り、ガンマは RGB カラー コンポーネントを別の値にマップする関数です。これをグーグルで調べてみると、線形関数と非線形関数を見てきました...線形関数はRGBコンポーネントをスケーリングするように見えるため、画像の明るさを調整しているようです。非線形関数は、暗い/明るいコンポーネントを「解凍」しているようです。

現在、さまざまな画像形式をテクスチャとして表示する画像ビューアの実装を開始しています。これらの画像のガンマを変更したいので、フラグメント シェーダーを構築し、テクスチャ化されたクワッドを実行する必要があります。わかりましたが、正しいガンマ補正を決定するにはどうすればよいですか?

OpenGL は、浮動小数点コンポーネントを使用して、線形 RGB 色空間を使用して動作します。実際、これらの値から (特別な浮動小数点精度で) ガンマ補正された値を計算できたので、ガンマ補正された値をクランプした後に表示されます。

まず、ガンマ ランプを決定します。どうすればそれを判断できますか？(分析的に、またはルックアップ テーブルを使用して)

次に、OpenGL 拡張 EXT_framebuffer_sRGB について調査することになりました。これは、拡張EXT_texture_sRGBと非常に関連しているようです。

EXT_texture_sRGB は、textel 値を RGB 線形空間に線形化するために使用される新しいテクスチャ形式を導入します。(脚注1) このようにsRGB色空間を意識してリニアRGB色空間として使っています。

代わりに、EXT_framebuffer_sRGB 拡張を使用すると、心配することなく、線形 RGB 値を sRGB フレームバッファーにエンコードできます。

...

待って、この情報は何のために？sRGB フレームバッファを使用して sRGB テクスチャをロードできる場合は、sRGB 変換なしでそのテクスチャを処理します...なぜガンマを補正する必要があるのですか?

sRGB バッファでも、ガンマをすべて同じように修正できますか? それともしない方がいいですか？明るさとコントラスト: ガンマ補正の前または後に適用する必要がありますか?

情報量が多くて、今迷っています。あなたの誰かがこれらすべての概念を私にもっと説明してくれることを願っています! ありがとうございました。

...

別の質問があります。デバイスのガンマが「標準」の 2.2 と異なる場合、異なるガンマ補正を「累積」するにはどうすればよいですか? 明確かどうかわかりません: モニターのガンマ値が 2.2 の画像の RGB 値が既に補正されているが、モニターのガンマ値が 2.8 の場合、ガンマを補正するにはどうすればよいですか?

(1) 以下は、私が言いたいことを強調するための抜粋です。

sRGB カラー スペースは、薄暗いオフィスで想定される一般的な (非線形の) モニター特性に基づいています。これは、国際電気標準会議 (IEC) によって IEC 61966-2-1 として標準化されています。sRGB 色空間は、おおよそ 2.2 ガンマ補正に相当します。

この拡張機能は、何らかの種類の sRGB フレームバッファ形式を提供したり、sRGB テクスチャでレンダリングされた画像が sRGB 色空間をサポートするデバイスに出力したときに「見栄えが良い」ことを保証したりしますか?

Dcraw には、画像の色を処理する次のアルゴリズムが含まれています: https://gist.github.com/1047302。
正式な (名前付きの) 画像処理アルゴリズムですか?

そうでない場合、その背後にある理由を理解するために何を読むべきですか?

最近、このブログ投稿に出くわしました。ガンマ補正に関するさらに別の投稿で、 D3DPMISCCAPS_POSTBLENDSRGBCONVERT機能フラグの可用性を教えてくれました。

これにより、DirectX9でブレンドした後の適切なsRGB変換が可能になります。

私が理解していないのはそれをどうするかです。デバイスDirect3D9Exデバイスにこの機能を問い合わせることはできますが、サポートされている場合はどうすれば有効にできますか？ブレンディング前とブレンディング後の変換を選択できますか？はいの場合、どのように？

助けてくれてありがとう！

アップデート：

皆様、ご回答誠にありがとうございました。Jesse Hall が示唆したように、ドライバー (またはハードウェア) の問題のようです。他の構成で同じアプリを試したところ、期待どおりに機能しました。

同じ GPU (ATI 4800 HD) を共有しているがドライバーのバージョンが異なる他のコンピューターでアプリをテストしたところ、それらはすべて同じ誤った動作を示しました (書き込み時の二重ガンマ補正のようです)。これらのコンピューターでは、D3DRS_SRGBWRITEENABLE を false に設定して表示を修正する必要がある場合。これがこのハードウェアの既知のバグかどうかは誰にもわかりませんか?

さらに奇妙なのは、これら 2 つの構成で同じ最終結果が得られることです。

• D3DRS_SRGBWRITEENABLE = FALSE および D3DSAMP_SRGBTEXTURE を TRUE に設定
• D3DRS_SRGBWRITEENABLE = FALSE および D3DSAMP_SRGBTEXTURE を FALSE に設定

ピクセル デバッガーでは、ケース 1 で線形化が適切に適用されていることがわかりますが、(自動) 書き込み時の修正により、ケース 2 と同じ出力が得られます (変換はまったく実行されません)...

// -- 更新の終わり

DirectX9 アプリケーションのガンマ補正を修正するのに問題があります。

サンプラー (D3DSAMP_SRGBTEXTURE) でテクスチャの線形化を有効にし、出力用の sRGB 書き込み (D3DRS_SRGBWRITEENABLE) を有効にすると、ガンマ補正が 2 回適用されているように見えます。

これが私のセットアップです。次のテクスチャ (ここから) を使用して、フルスクリーンのクワッドを描画しました。

結果は、写真の右側で視覚的に明るすぎました。PIX を使用してこれらの灰色のピクセルの 1 つをデバッグしました。すべてが適切に設定されていれば、出力値は 0.73 (=0.5^(1.0/2.2)) になると予想していました。残念ながら、ピクセル シェーダーの出力は 0.871 でした (ガンマ補正が 2 回適用されたように見えますか?)。デバッガーを使用してピクセル シェーダーに足を踏み入れたところ、テクスチャ フェッチで (0.491, 0.491, 0.491) の値が返されました。これは、読み取り時の線形化が正しく機能していることを意味します。

D3DRS_SRGBWRITEENABLE を無効にすると、ピクセル シェーダーの出力は 0.729 になり、より正確に見えます。

この変換はどこから来たのですか (デバッガーでは、ピクセル シェーダーの出力は 0.491 でした)。他にどのようなフラグ/レンダリング ステートを確認する必要がありますか?

ご助力ありがとうございます！

Motorola Photonは、他の人が「ブラッククラッシュ」と呼んでいるものを展示することで有名です。写真を表示すると、画像の暗い部分の細部のほとんどが黒に平らになります。これまで、ほとんどの人がペンタイルディスプレイでそれを非難してきました。しかし、初めてその効果を見たとき、私は別の考えを思いつきました...「うわー、それは、Windows用にエンコードされた写真が1.8のガンマを使用したときにLinuxとMacintoshで見たのと同じ（悪い）方法に見えますWindowsの2.2"の標準の代わりに。私の理論では、モトローラは、モトローラがiPhone以前のAppleパートナーだったときに書き戻された古いライブラリを使用してPhotonのAndroidを構築しました（または、2.2ではなく1.8ガンマを想定した古いオープンソースコードを入手した可能性があります）。

なぜ私はそんなに確信しているのですか？数日前、古いEpic 4G（Samsung Galaxy S）と新しいPhotonの両方を使用して、同じWebページのスクリーンキャプチャを実行しました。予期せぬことに、Epicのスクリーンキャプチャ.pngは正常に見えましたが、Photonのスクリーンキャプチャ.pngは、私のPCで表示した場合、Photonの画面で表示した場合とまったく同じ悪い外観でした。それを見た瞬間、ガンママッピング1.8-vs-2.2のバグの可能性について以前に考えたことを思い出し、モトローラに見せて、これが修正可能な本当のバグであることを納得させるためのデモアプリを書いてみることにしました。

私がやりたい実験の1つは、明るい領域と暗い領域の両方でダイナミックレンジとディテールが高いJPEG画像を取得し、1.8と2.2の差の基本的に2倍の非標準ガンマに再エンコードすることです。意図的に反対の極値（2.6？）に誤ってエンコードした場合、メタデータにあり、2.2であると言うと、フォトンで表示すると正常に見えます（2.2を1.8にクラッシュさせるのと同じエラーがあるため） 2.6を適切な2.2にクラッシュさせます）。

したがって、2つの質問：

1. 2.2ガンマ画像が1.8であるかのようにデコードされた場合に得られるエラーと等しく、反対のガンマはどれですか？2.6？

2. ソース画像をその非標準のガンマに意図的に誤ってエンコードする簡単な方法（無料のPhotoshop / gimpプラグイン、JPEGエンコーディングライブラリなど）はありますか？

アプリケーションの起動時に画面ガンマを調整し、終了時にリセットする機能を追加したいと思います。ガンマを改ざんするべきかどうかは議論の余地がありますが（個人的には役に立たず、有害だと思います）、そういうことができると期待している人もいます。

これも1つの単純なAPI呼び出しなので、すべて簡単ですよね？

MSDNによると、「ガンマランプは256 WORD要素の3つの配列で指定され、DACの独立性を高めるには、各[...]値を各WORDの最上位ビットに格納する必要があります。」。これは、私の理解では、のようなものを意味します。word_value = byte_value<<8これはかなり奇妙に聞こえますが、それは私がそれを読む方法です。

Doom3ソースコードには、値の3つの配列を受け取り、それらを上半分と下半分の両方で同じバイト値を持つ値charの配列に変換する関数が含まれています。言い換えれば、のようなものです。これも同様に奇妙ですが、さらに悪いことに、上記と同じではありません。uint16_tword_value = (byte_value<<8)|byte_value

また、インターネット上のさまざまな趣味のプログラマーサイトにいくつかのコードスニペットがあり（文字と同じであるため、明らかに一方が他方から盗まれています）、線形インデックスに値を掛け、128でバイアスをかけ、いくつかのあいまいな計算を行います。これが何であるかはよくわかりませんが、私にはまったく意味がないように見えます。また、上記の2つと同じではありません。

何が得られますか？推測することなく、明確に定義されている必要があります。提供するデータはどのように見える必要がありますか？最後に、元の値を読み取り、ユーザーがスライダーを微調整できるようにします（オプションで、ユーザーの構成を使用してそのBLOBをディスクに保存します）が、それでも...これらの値を変更するには、次のことを行う必要があります。彼らが何であるか、そして何が期待されているかを知っています。

誰かがこれを以前に行って（そしてテストして！）、どれが正しいか知っていますか？

Y'CbCr 空間の画像でガンマ補正を行う必要があるため、画像の飽和領域と欠乏領域の詳細を引き出すことができます。クロマ サブチャネルを調整する必要があるかどうか疑問に思っています。

ルマチャンネルのピクセルを枯渇させると、調整しないとクロマがにじみ出てしまうことがわかっています。ガンマ補正を行うときも同じことを考慮する必要がありますか? クロマチャンネルを調整する価値はありますか?