SONYから、α7sIIから「14bit非圧縮raw」に対応するというリリースが出たそうです。

(追記11/10)
昨日よりカカクコムからの流入が激増しています、カカクコム、さすがのメディア力ですね。
最大の関心事である「14bit非圧縮rawで例の現象は改善するのか」ですが、現在の所確認できていません。
14bit非圧縮rawモードの時にバルブやサイレントモードで撮影した作例をご存じ・お持ちの方は本記事にコメントいただけると幸いです。
結論から言って、かなり天体用途には期待が持てそうです。
SONYの圧縮rawアルゴリズムが、天体のような局所的に大きな輝度差を持つ対象に特に不適であると考えられるからです。
次の記事にわかりやすい解説が書かれています。
(If you must die, die well みっちのブログ)
(9/18 みっちさんからいただいた情報を元に大幅に加筆修正しました。みっちさんありがとうございます）
簡単にまとめると、SONYの圧縮Rawは、
4×4=16ピクセルの情報（224bit）を、固定長の128bitに圧縮します。
圧縮のアルゴリズムは以下のようなもので、
ダイナミックレンジは最大で11bit、
最小では、局所的にですが7bitにまで低下します。
・元々の情報である14bit×16ピクセル中の最大輝度と最小輝度の各1画素を11bitで記録
　（輝度11bit×2+位置4bit×2=30bit)
　→14bit->11bitの変換は、独自の圧縮トーンカーブのようなもので変換
・残り14画素を、「最大/最小の輝度差を7bitで表した値」で記録
　（7bit×14=98bit)
このアルゴリズムは、4×4ピクセルの範囲内の、
ピクセルの輝度差が小さいほど有効に機能します。
しかし、輝度差が大きくなるほど、階調は最大7bit相当にまで低下します。
さて、このアルゴリズムを、
星のような局所的な輝度差の大きい対象に使うとどうなるか？
最悪ですよね。
特に、小さな星の最大輝度周辺部がカクカクになることが想像されます。
また、ホットピクセル周辺の階調は消えてしまうでしょう。
まさにこれが「星が腐る」現象の原因ではないでしょうか。
また、ローパスを外してしまうと、星の場合にはピクセル間の輝度差がより極端になり、
さらに悪い結果を生むと想像できます。
というわけで、14bit非圧縮rawは天体撮影においてかなりの期待が持てそうです。
（自分にとっての問題は旧機種のα7sでもこのアップデートが入るかどうかですが）
しかし理解できないのは、たったの12/14、高々１５％の圧縮を何のためにやるのか？ということです。
前にも書きましたが、12bit圧縮モード/14bitモードで、rawファイルのサイズに違いはありません。
ファイルサイズを小さくすることではなく、内部処理のデータ転送や外部記憶書き出しのパフォーマンス向上が狙いなのでしょうか。
それなら、わざわざこんな変な圧縮をせず、ハナから12bitで記録すればいいようにも思いますが・・・

みっちさんのご指摘によると、
「128bit」というハードウェアで処理しやすいビット長にすることが、
このアルゴリズムの狙いではないか、とのことです。
この推測だと、この圧縮の実装はソフトではなくチップ内の処理になるので、
ほんとにファームアップで改善できるのか？という心配が生じますね。
ハードのロジックをソフトでバイパスするのでしょうか？
また、高々「15%」という認識は間違いでした。
この圧縮は128/224 なので半分近くに圧縮されます。
12bitというのは、この圧縮アルゴリズムで最大表現できる階調数、という意味でした。

一つわからないのが、
「SONYの14bitのrawは”常に”不可逆圧縮している」
のか、
「”内部的に12bitで処理される場合（Bモードなど）”のみこのアルゴリズムで圧縮される」
のか、どちらなのでしょう？
常に不可逆圧縮しているのなら、「Bモード」の時だけの問題ではないはずですし、
そうでないなら、なぜ「Bモード」とそれ以外でファイルサイズに違いがないのか？
また、最終結果に出てこない内部処理エンジン内のアルゴリズムならば、
raw画像フォーマットを解析する際には不要なはず。（公開される必要もない）
rawファイルの実サイズが、キヤノンとSONYで画素数比程度の違いしかないところをみると、
最終的には同じ14bit相当のrawフォーマットになっているように見えるのですが・・
ここの認識は明確に確認したいですね。

関連記事

Follow me!