シグモイドモジュールの実装

darktableの新しいバージョンは、予定通りなら、クリスマスに出るはずです。

 

日本では、darktableをpoor man’s lightroomと考えている人が多いですが、darkatableは、現時点において、画像編集に伴う画像劣化が一番少ないRAW現像ソフトです。これより上はありません。

 

darktableは、RAWデータを編集するときに、RGB色空間を使い、ベースカーブ変換によって劣化していないデータを処理することができます。

 

darktableでは、互換性のために、古いベースカーブモジュールを用いることもできますが、推奨は、ブレンダーからアイデアを借りたS字型のスプライン関数を使うシーン参照ワークフローです。

 

2022年11月現在、ベースカーブを使わないRAW現像ソフトは、darktableしかありません。

 

2022年10月に、windows版のシグモイドモジュールが、pixls.usで公開されました。

 

これは、フィルミックRGBモジュールのS字型スプラインを置き換えるモジュールです。

 

シグモイド モジュールが使う一般化されたスキュー対数ロジスティック関数は、フィルミックRGBモジュールのS字型スプラインでは表現できません。

開発者は、この 2 つの違いは、ベース カーブとフィルミックRGBモジュールのS字型スプラインの違いと同じくらい大きいといっています。

 

現時点で、シグモイドモジュールの扱いは不明ですが、開発者は、フィルミックRGBモジュールの拡張として、統合することを希望しているようです。

 

シグモイドモジュールは随分前から、試作されていましたが、ここにきて、標準モジュールの位置を射程に活動を強化しています。

 

もちろん、今回のクリスマスのバージョンアップには間に合わないと思いますが、その次の改訂に向けた議論が進むと思われます。

 

日本のカメラメーカーは、依然としてJpegの画像を論じていますが、今後、ディスプレイの発色数が、8ビットRGBを超えるのは時間の問題ですから、画像をJpegで保存することは、その画像が、将来使えなくなるリスクになります。

 

Lightroomは、Lab色空間で、ベースカーブモジュールを使っています。ベーブカーブ変換をパイプラインの最初の方で行うと画像劣化が著しくなります。Rawtherapieは、パイプラインのあとの方で、ベーブカーブ変換をしています。Lightroomも恐らく、同じような対応をしていると思われます。いずれにしても、画像劣化を考えると、根本的な対策を回避して、「Lab色空間で、ベースカーブモジュールを使う」処理は早晩なくなると思われます。

 

つまり、現バージョンのLightroomの操作法に熟達しても、数年で、価値のない知識になると思われます。

 

シグモイドモジュールの動向は極めて重要だと考えます。

 

以下に、gitHUBの解説の一部の翻訳を載せます。



<==

 

Log-Logistic / Naka-Rushton 曲線に基づいた新しい表示変換モジュールで、さらに制御できるようにスキューが追加されています。

これは、無限のダイナミック レンジをディスプレイまたは印刷の有限のダイナミック レンジに圧縮するという同じ責任を持って、フィルミックRGBのS字型スプラインの代替として開発されました。

 

どのように?

 

これは、作業プロファイル RGB チャネルまたは RGB 平均に RGB 比率として適用される一般化対数ロジスティック曲線を使用します。

 

これは本質的に、通常の対数ロジスティック曲線に別の累乗関数を適用することを意味します。これにより、分布、またはこの場合はコントラストがシャドウまたはハイライトに向かって歪むことになります。UI パラメーターの効果を相互に直交させるために、いくつかの舞台裏の操作が実行されます。(スキュー = 0 の中間グレーの傾斜は、すべてのスキュー値に対して維持されます)。より詳細な分析と説明については、上記のリンク先の投稿を参照してください。

 

なぜ新しいモジュールなのか?

 

新しい曲線をフィルミックRGBに統合してみませんか:

 

フィルミックRGB は、シーンの白黒ポイントの定義に大きく依存します。シグモイド曲線は 0 から inf まで定義されるため、白黒のシーンなどの概念はなく、中間のグレーへの相対的な露出だけです。したがって、いくつかの機能と UI 要素の両方をやり直したり削除したりせずに、フィルミックRGBの中で動作させるのは難しいでしょう。

 

私は、提案されたシグモイド モジュールを、超構成可能ではなくシンプルで堅牢な状態に保つことで、概念的にフィルミックRGBとは異なるものにしようとしました。ツールの操作を高速化すると信じているため、ディスプレイの変換をさらに進めるためのその道を引き続き探求したいと思います。

 

このモジュールの強みは次のとおりです。

 

堅牢で、RGB 値 [0, inf) に対して常に適切に定義されています。

 

いつも単調。マッピングに使用される曲線は、設計上、常に単調です。

 

非常に滑らかで、曲線はパラメトリックで、ディスプレイの境界に向かって収束します。

 

カーブの形状を完全に制御しながら、2 つのパラメーターのみを使用します。

 

コントラストとスキューは直交しているため、操作が非常に簡単です。

 

将来的には、たとえば、ACES 1000 nits 曲線をそのままモデル化できます。

 

これからの仕事

 

必要

提供されたコードは、C 実装のみを提供します。最適化されたコード パスも実装する必要があります。

 

ドキュメンテーション

 

モジュールが承認された場合に寄付されます。

 

募集

 

仕事用プロファイルを使用するだけでなく、処理プライマリを明示的に選択します。(色相保存を使用しない場合、最終結果に最大の効果があります)。

 

色域のクリッピング/圧縮のシャープネスを調整。モジュールは現在、表示変換を適用する前に、色域クロマを RGB シーン境界にクリップします。シグモイド曲線の概念を色域方向で再利用できる興味深い作業がここで行われます。たとえば、Blender フォーラムでの AgX の議論を参照してください: 

https://blenderartists.org/t/feedback-development-filmic-baby-step-to-a-v2/1361663/1203

 

これらは両方とも機能の拡張であり、下位互換性の問題なしに後で追加できます。というフィードバックに同意します@TurboGitこれらは別々の PR で取り組む方がよいと私に教えてくれました。

 

==>

 

引用

 

新しいモジュール: シグモイド表示変換

New module: Sigmoid display transform

https://github.com/darktable-org/darktable/pull/12642