アカウント名:
パスワード:
> 以前から内部でそういう処理をしていた機器はあるはずなので
例えばナナオのL985EX [eizo.co.jp], L685EXやシャープのハイエンドLCDモニタがそうですね. 実際に使ってみると, さすがに細かい部分の発色まできちんと表現されていて, かなり幸せな気分になれます(豚に真珠・猫に小判とも言う).
でも, こういった多ビットリニアデータフォーマットって, モニタ-ドライバ間でキャリブレーションを行ったりする場合には便利だと思いますが, 汎用的な画像データとしてはダイナミックレンジ不足などの理由で中途半端な物だと思います. 現状の8bitリニアデータの後継としては, やはりOpenEXR [srad.jp]あたりにシステムAPI用フォーマットになってほしいと考えています.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
これって (スコア:0)
2 ** 10 ** 3 = 10億7374万1824
ですから。
だとしたら以前から内部でそういう処理をしていた機器はあるはずなので、
リニア表現はAPIとしては捨て (スコア:1)
> 以前から内部でそういう処理をしていた機器はあるはずなので
例えばナナオのL985EX [eizo.co.jp], L685EXやシャープのハイエンドLCDモニタがそうですね. 実際に使ってみると, さすがに細かい部分の発色まできちんと表現されていて, かなり幸せな気分になれます(豚に真珠・猫に小判とも言う).
でも, こういった多ビットリニアデータフォーマットって, モニタ-ドライバ間でキャリブレーションを行ったりする場合には便利だと思いますが, 汎用的な画像データとしてはダイナミックレンジ不足などの理由で中途半端な物だと思います. 現状の8bitリニアデータの後継としては, やはりOpenEXR [srad.jp]あたりにシステムAPI用フォーマットになってほしいと考えています.