darktableは、オーレリアン・ピエール氏が、2018年に、開発者になってから、劇的な変化を遂げました。
それまでは、ベースカーブをつかった市販のRAW現像ソフトの簡易版でしたが、ピエール氏が、フイルミックRGBモジュールを導入して、ベースカーブを否定したことで、独自のRAW現像ソフトになりました。
しかし、このことは、後方互換性の否定になります。
現在のdarktableでも、後方互換性の維持のために、ベースカーブモジュールが搭載されていますが、それは、非推奨になっています。
darktable以外のRAW現像ソフトは、ベースカーブモジュールに依存しています。
平均的な人間の目のダイナミック レンジは 22 ～ 24 EV と推定されていますが、一般のディスプレイはおよそ 10 EV に達し、8 ビットの JPEG ファイルは OETF(Opto-Electronic Transfer Function) により最大 12.67 EV までエンコードできますが、紙のプリントのダイナミック レンジは 5 ～ 7 EV と低くなっています。これは、ハイエンドの DSLR が現在ほぼ 15 EV に達していることで急速に問題になっています。
OETFの説明は以下にあります。
カメラのダイナミック レンジは、平均的な人間の目のダイナミック レンジに近づいています。
紙のプリントのダイナミック レンジは 5 ～ 7 EV なでの、写真は、印刷するものではなく、ディスプレイで見るものと考えるばきです。
写真を印刷する場合には、プリンタのドット（ピクセル）あたりのダイナミックレンジの低さをディザ処理で補っているために、高解像度のデータが必要になります。
ディスプレイであれば、1000ｘ1000ピクセルでも十分な表現になります。
問題は、現在のディスプレイが、10 EVのダイナミック レンジである点です。
これは、8ビットのJpegをエンコードした最大 12.67 EVより狭いです。
ピエール氏は、ディスプレイのダイナミックレンジが広くなれば、ベースカーブでは無理があると考えました。
しかし、ベースカーブを否定すれば、ベースカーブの開発者の中には、不満を持つ人ができる可能性が高いです。
結局、ピエール氏は、darktableの開発チームを離脱しています。
以下には、その顛末の一部が書かれています。
例えば、次のように内紛の事情が書かれています。
＜
さらに、Darktable の (非常に) 古いコードは (まあ、大部分は) クリーンで堅牢ですが、ここ数年で最悪の状況に陥っただけです。git Blame では、本当にひどい行に常に同じ 3 人の名前が表示されるため、習慣的に、誰が書いたかがわかると、対応する行を自動的に削除してしまうことがあります。
＞
ソフトウェア開発に伴うコンフリクトの情報は、あまり、外部に流れることはないので、上記の記事は、貴重な情報であると思います。
筆者は、最初、ピエール氏の記事は、フリーウェア開発に伴う現場のコンフリクトの事例であるとかんがえました。
しかし、COCOAのバクや、マイナンバーカードのバグをみると、日本の官庁のソフトウェア開発は、Darktable の開発以上の問題を抱えていると考えるようになりました。
富士通サービシーズが1999年ごろからポストオフィス（イギリスの国有企業である郵便局会社）に提供していた勘定系システムの「ホライゾン」のバグ問題も、ソフトウェア開発に伴う現場のコンフリクトの処理問題として、共通する側面があります。
COCOA、マイナンバーカード、ホライゾンでは、ピエール氏のように、袂を分かつ技術者は出ませんでした。
されに、拡げると、福島原発でも、袂を分かつ技術者は出ませんでした。
物事には、トレードオフがあります。
日本では、コンフリクトをつぶして、袂を分かつ技術者が出なければ、問題がないと考える人が多いです。
しかし、そのツケは、先になって発生します。
COCOA、マイナンバーカード、ホライゾンも、コンフリクトをつぶしていたので、問題が発生することは、トレードオフを考えれば、当然予測できたと言えます。
ピエール氏は、darktableの無駄で、混乱したコードを改善したAnselを現在開発しています。
ピエール氏は、darktableが行き詰って、Anselが、生き残る方に賭けています。
darktableは、ピエール氏が開発シームから抜けて、新機能のバージョンアップの速度が落ちたようにも感じられます。
