Twitterに動画投稿できない悩み
もう疲れたので、簡潔にまとめておきます。
同じような悩みの人のヒントくらいになれば。
40秒くらいの普通の動画を普通にアップロードしようとしたのですが、アップロードすると最後の最後で「お前の動画、互換性ないから無理（意訳）」と蹴られてしまう現象に悩み続けました。
実際、半日くらいトラブルシューティングに使いましたよ。
Twitterとしての公式の情報は以下のとおり。
Q：
ブラウザからアップロードできる動画の解像度と縦横比を教えてください。
A：
最小解像度: 32 x 32
最大解像度: 1920 x 1200（および1200 x 1900）
縦横比: 1:2.39～2.39:1の範囲（両方の値を含む）
最大フレームレート: 40fps
最大ビットレート: 25Mbps
以上。
実にシンプルです。
普通に考えれば、それほど問題になることはなさそうですね。
だがしかし、何度動画を作り直してもエラーになってしまう。
フレームレートが悪いのかと思い、オリジナルを保持 ＞ 30fps に変更したもののNG。
元々は29.97でした。
バッファ容量が大きすぎるのかと思い、24000 ＞ 12000 に変更したもののNG。
最大レートを 12000、10000、など変えてみてもNGのまま。
解像度を変更してみたものの、1080p、720p、480p、どれもNG。
メインプロファイルはレベル4.1で問題ないはず。
フレームパッキングは、なし。これも互換性を考える上では問題ないはず。
OpenGDP 有効
キーフレーム間隔 自動
最小GOPサイズ 自動
Bフレーム数 3 から 2 に変更するもNGのまま。
Bフレームモード なし で問題ないはず。
ここで設定をリセット。
その後、いつもどおりにビットレート制御モードを品質へ変更 値は26
最大レートを2400から10000へ変更。
・・・もしやこの設定を変更したら変わるかも？
・・・ということで、結局のところ「ビットレート制御モードをVBRにする」で解決しました。
品質固定は結果だけ見れば無問題でも、ファイルとしては互換性に乏しいらしいです。
実際に設定したのは、
平均レート4500
最大レート10000
実際に作られたファイルは平均6000Kbpsくらいでしたが。
ま、2passではないので、仕方ないですね。
そんなわけで、散々悩んだ挙句、原因は自分が好んで使用していたビットレート制御方式だったようです。
再現性の確認はもう少ししてみますが、とりあえずメモも兼ねて書いておくことにします。
訂正などがあれば、追って修正することになるかと。
それでは皆さん、ごきげんよう。
マイニングではGPUよりもメモリが重要である？ 確認してみた。
マイナー そして マイニング。
この単語が聞かれるようになって久しい。
いや、個人的に知ったのは数ヶ月前なのだが、数年前から存在はしていた。
そんなマイナーな、いやマイナーに関する話。
細かい説明は省略。
自分としても、全てを把握しているわけではないので。
せいぜいが、ビットコインを採掘するにはASICが必要で、汎用機での採掘はコストに見合わないこととか、主戦場は電気代の安い中国であるとか、その他の仮想通貨の採掘が日本での流行りであるとか、RADEONが日本のみならず中国で買い漁られていることもあって世界レベルで流通量不足になっていることとか、まぁそんな程度だ。
それだけ知っていれば十分かもしれないが、それでも人に説明をするには知識が不十分である。
よって省略する。
今回この記事をおこしたのは、マイニングがGPUに求める性能に偏りがあるように思ったことと、自分なりに確認してみた結果をまとめておこうと思ったからだ。
一般的に、マイニングにGPUを使うのは省略した説明に含まれる範疇の情報なのであしからず。
GPUに求める性能が偏っているとはどういうことか。
それは、メモリアクセス性能を極端に要求するアプリケーションであるということだ。
それを示しているのが、Geforce GTX 1070 と1080のハッシュレートを測定したとき、1070の方が上位であるという結果である。
少し調べればベンチマークの結果一覧は出てくるので具体的な値は省略する。
なぜ、シェーダーの数で1.33倍上回る1080が1070の後塵を拝するのか。
その鍵はメモリの種類にある。
1070はGDDR5、1080はGDDR5Xである。
GDDR5とGDDR5Xの違いは何か。
詳しいことは調べれば出てくるが、ひっくるめるて一言で言えば、データーアクセス粒度の違いであると認識している。
1命令で読み出せるデーターの大きさが倍なのだ。
メモリクロックが「8GHz相当」のような表記になっているのは、データー転送時のクロックを示している。
読み出し命令（制御系）のクロックはもっと低い。
「8GHz相当」の場合、GDDR5が2GHzでGDDR5Xが1GHzである。
これが何を意味するか。
見た目上のデーター転送レートが高くとも、GDDR5Xの場合、データー読み書きの命令頻度が落ちるのだ。
そのため、細かい読み書きが苦手なのである。
本来の3Dグラフィックでは問題がないデーターアクセス粒度でも、マイニングで使用するには粒度が大きすぎるようだ。
その結果、1070と1080のハッシュレートが逆転するという現象が発生する。
シェーダーが多くてもメモリに足を引っ張られて性能が出ないということは、メモリアクセス性能が支配的であるということだ。
そのため、RADEONが人気である（性能が出やすい）というのも理解できる。
あれはGDDR5であり、メモリバス幅も比較的広い。
ただしコアクロックはそれほど高くないので、相対的にシェーダーの演算性能はそれほど高くない。
また、RADEONのL2キャッシュは同価格帯のGeforceのそれよりも多いのでハッシュレートが高いという話もある。
もっとも、最近のGeforceは昔よりもL2キャッシュを増やしているし、キャッシュよりレジスタの方が性能のためには重要であるという話もあるので、ここではメモリアクセス性能が重要であることを裏付ける情報である、という点を把握するにとどめたい。
実際のところ、GPUとメモリのクロックがハッシュレートに与える影響はどうなのか？
あまり、こういった視点でのベンチマーク結果は出ていないようなので情報がない。
よって調べてみた。
以下については、大雑把なテストであること、エビデンスをとっているわけではなく目視確認レベルであること、厳密に条件を整えているわけではないこと、などに留意して欲しい。
テスト環境では、Geforce GTX 1060 3GB を使用している。
採掘しているのは、一般的なETH（だったはず）。
コア1620MHz、メモリ8500MHzくらい
ハッシュレート22.0MH/s
コア1780MHz、メモリ8500MHzくらい
ハッシュレート22.2MH/s
コア1620MHz、メモリ8700MHzくらい
ハッシュレート22.5MH/s
頑張ってコアをOCするよりも、メモリを少しOCする方が効果があるようだ。
コアをOCしないことで、不要な消費電力増を避け、ファン騒音の低減が実現できる上に、ハッシュレートは上がるという一石二鳥である。
余談だが、この1060で試したところコア2000MHz程度でも一応は動作するようである。
ファン100％で温度は75度くらいだったと記憶している。
当然電圧もそれなりに上がり、1Vを超えていたはずだ。
普段使用している1620MHz程度では、ファン75％で60度を下回っている。
電圧は0.8V程度で落ち着いている。
ちなみに1620MHzというのはパワーターゲットを60％に設定した結果である。結果としてほぼ定格であるが。
もっとも、メモリの動作温度がどうなっているかは測定していないので不明であるし、メモリの定格は8000MHzとなっているのでOCによる寿命短縮は避けられないはずだ。
今現在、9000MHzあたりまでは問題なく動作することを確認したうえで多少マージンをとっているが、いつかはマージンも無くなるだろう。
もし今回の確認結果を参考にする人がいるとすれば、それを踏まえたうえで使用すべきであることは承知されたし。
ということで、少々マニアックな話題を扱ってみた。
もし何か参考になることがあれば幸いだ。
それでは皆さん、ごきげんよう。
PCの消費電力を計算によって確認してみる。PCというかWSみたいな何か。
SR-2という製品をご存じだろうか。
「それ知ってる！レカロ！」と手を挙げた方は残念賞。
今回は、2010年に発売されたM/Bの話。
何故このM/Bの話なのか。
それは、現在進行形で手元にあり、消費電力の多さから運用頻度が極端に低く、その消費電力の根拠が気になったから、だ。
使わないと勿体ないが大規模すぎて取り回しが面倒で使用頻度激減、という流れで現在に至る。
このM/Bの構成を簡単に記すと、チップセットに5520、ブリッジチップにnF200を2つ、LGA1366を2つ、DDR3が3ch、である。
ここにGeforce9600GTを組み合わせ、SSDを2台、HDDを13台、CPUは低消費電力版の6コアXeonを2つ搭載。
合わせると、12コア24スレッド、メモリが48GBにストレージが36TBとなる。
非常に快適だ。
しかし、何もしなくても約160Wを消費する。
フルロードであれば、定格2.4GHzで280W、3.0GHzで380W、エコとは無縁の暖房器具と化す。
ざっと簡単に考えてみる。
Intel製のチップセットは基本的にそれほど消費電力は多くないはずだ。
nF200は不明。
比較的最近のCPUは消費電力に関しては大人しいと思って良い。
メモリはアクセスしなければそれほど電力を消費しないはずだ。
GPUはそれなりに電力を消費する。現行の1060がアイドル時実測で9W程度なので、プロセスルール的に考えてそれよりは多く消費しているはずだ。
SSDは数W程度。
HDDは7200rpmであることが災いして、1台あたり5W以上消費しているはずなので、70W近いのではないか。
HDDの分を差し引いても、アイドル時に90W程度の消費電力がある。
電源でもロスがあるはずだ。
さて、そう考えていったとき、計算は合うだろうか。
もう少し正確に求めてみよう。
一番怪しく不確定要素なのは、nF200である。
nF200について調べたところ、NVIDIAの780iチップセットで使用されていることが分かった。
780iは680iと同じMCP55系（C55）を採用、OCして駆動、スイッチチップとしてnF200を採用、という構成だ。
よって、780iチップセットについて調べれば何か判明するのでは？と考えた。
M/Bのみ交換し、他は同等の構成でテストした結果があった。
X38のアイドル時 52-68W（ave64W）
nForce780iのアイドル時 114-125W（ave119W）
平均値で比較して、フルロード時46W、アイドル時55Wの差。
別のベンチテストでは、アイドル時、X38が168W、780iが214W、差は46W。
よって、X38との比較では、消費電力は50W程度増加すると断定して問題はない。
X38の情報を調べると、製造は90nm、TDPは26.5W とある。
つまり、780iのTDPは70～80W程度と算出できる。
間を取って75Wと仮定する。
さて、この75Wの何割かはnF200が担っている。
さほど大きくないヒートシンクとはいえ、ファンつきのクーラーを使用しているので、1桁ではない。
仮定するとすれば10W以上、20Wまでは届かない、といったところだと思われるので、15Wと仮定する。
2つ搭載すれば30Wである。
上記より、SR-2の主要構成チップ 5520+nF200+ICH10R の消費電力（TDP）は 27.1+30+4.5=61.6 となる。
M/B上の他のチップも含めて、M/BのTDPは65W程度と見積もることができる。
他のコンポーネントの消費電力も計算しよう。
7200rpmのHDDは、調べたところアイドル時で5.6Wとのこと。
13台搭載すれば72.8W
電源効率は80+程度の750W電源なので、82％と仮定。
GPUは、ローからミドルレンジ程度の構成であれば、アイドルで10Wを少し切る程度に収まっているという情報が2009年に確認できたので、10Wという値を採用。
さて、アイドル時に160W消費していたPCは計算上成り立つのか。
まず、電源のロスを除外。
160*0.82=131.2
HDD分を除外。
131.2-72.8=58.4
GPU分を除外。
58.4-10=48.4
この48.4Wが、CPUとメモリとSSDとM/B分の消費電力となる。
アイドル時、DRAMの消費電力はほぼ0に近い（FB-DIMMなどを除く）という実験結果があった。
しかしDRAMのセルフリフレッシュは8GBでも3ケタmWくらいは消費しているという説明資料があったので、メモリの消費電力は1Wとする。
したがって、48.4-1=47.4
余談だが、メモリの枚数を増やすとアクセス時の消費電力が上がるのはコントローラーのチャンネル数が増えたから。
メモリをOCするとアイドル時の消費電力が目に見えて上がるのは、メモリコントローラーの動作クロックが上がったから。
幾つかのサイトで、目の前の事象だけに注目して短絡的に誤った結論に至っているものがあった。
いとをかし（違
閑話休題。
CPUのアイドル時の消費電力だが、Ivy BridgeのC7ステートの消費電力は最大で2.2Wとなっている。
世代的に近いので、4コア2.2Wという値を参考値とすると、12コアで6.6Wとなる。
Xeonは他にもロジックの規模が大きくなっているので、8W程度と考えておけば良いだろう。
したがって、47.4-8=39.4
SSDはどうか。
使用しているSSDはアイドル時に100mWを下回るようなので、2台で0.2Wとする。
したがって、39.4-0.2=39.2
さて、M/BのTDPは計算上65Wだった。
それがアイドル時は計算上では39.2W。
悪くない結果、納得できる範囲かと思う。
参考メモ
Intel(R) 5520 I/O Hub
65nm
TDP 27.1W
ICH10R
TDP 4.5W
Intel(R) X99 Chipset Product Specifications
32nm
TDP 6.5W
B75
65nm
TDP 6.7W
H87
TDP 4.1W
それでは皆さん、ごきげんよう。
EVと、各種バッテリーの正しい使い方
次期リーフはバッテリーが倍増して48kWhとか60kWhになるらしい。
何かのキーワードで情報検索していたときに、そのような話を見かけた。
たまに90kWhという文字もあったが、あれはバッテリーからの出力が90kWという資料を見間違えただけだろう。
ともあれ、バッテリー容量は大きければ大きいほど良い。
それは、長距離走れるからとか、充電の手間が減るから、という短期的な見方によるものではなく、バッテリーの負荷軽減につながるため寿命そのものを伸ばすことになるからだ。
一応説明しておくと、ある負荷装置があるとして、その装置に一定の電力を流す場合、容量の小さいバッテリーよりも容量の大きいバッテリーの方が、バッテリーが持っている電力量に対する放電電力の比率が小さいため、バッテリーへの負担が少ないということ。
もう少し具体的に言えば、100Wの負荷に対して、100Whのバッテリーを接続した場合、放電は1Cとなる。
しかし500Whのバッテリーを接続した場合、放電は0.2Cとなる。
1Cより0.2Cの方がバッテリーへのダメージは少ない、ということだ。
さらに、急速放電の度合いが低いほど、バッテリーの発熱も少ない。
全体で発生する熱量は等しいかもしれないが、温度上昇の度合いは低いので、温度的な意味でもバッテリーには優しいことになる。
同じことは充電する時にも当てはまる。
10kWhのバッテリーに20kWの充電器を使うと、2Cでの急速充電になる。
しかし40kWhのバッテリーであれば0.5Cの充電となり、バッテリーへの負担は少なくて済む。
もの凄く大雑把な計算なので、その辺のツッコミは勘弁してほしい。
必ずしも急速充電が悪いわけではなく、設計上の想定内で推奨される環境下での使用であれば問題はないものの、充電電流は極端に大電流でない方がいいのは明らかだし、温度も低すぎたり高すぎたりしてはいけない。
細かい話は、リチウムイオンバッテリーの種類によっても変わってくるので、また気が向いたら情報を集めることにしたいが、基本的な原則は変わらない。
バッテリーが無理なく動作できる範囲で、無理なく使ってやること。これが長持ちさせるカギになる。
話をEV以外に向けよう。
現在使われているバッテリーには様々な種類がある。
鉛蓄電池、ニッケルカドミウム、ニッケル水素、リチウムイオン、あたりが一般的だろうか。
それぞれ、適した使い方というのは異なるので、以前の常識が新しいバッテリーに通用することはない。
それを勘違いして「ｘｘした方が良い」と最初から決めつけて、昔からの習慣に倣って使ってしまうと、寿命を縮めかねない。
自分の身の回りでも、意外と知らない人が多い（というよりも気にしていない人が多い）ので、メモがてらまとめてみようと思う。
鉛蓄電池
名前のとおり鉛を使用しているので、非常に重たいバッテリーである。
しかも古くから使われている。
では時代遅れなのか？というと、用途によってはそうでもなかったりする。
重量を気にしなければ、大容量のバッテリーを製造しやすい。
そのわりには安価である。
充電制御が比較的簡単である。
容量が大きいので、相対的に大電流を流すことも一応可能。
そのような特徴を生かして、自動車のバッテリーやUPSに使用されている。
長持ちさせるコツは？
保存するときは満充電にしておくことだ。
使ったら必ず充電する。充電した記憶が怪しかったらとりあえず充電する。
とりあえず満充電にしておけば問題なし。
非常にわかりやすいバッテリーである。
逆に、放電した状態で放置してしまうと電極表面に硫酸鉛が付着してしまい、内部抵抗が増大して出力可能な電流量が低下し、あっという間に寿命を迎える。
バッテリーあがりを起こした時、バッテリーが完全に復活しないのは、これが原因である。
詳しいことを知りたければ「サルフェーション」で検索してほしい。
ニッケルカドミウム
このバッテリーについて回る言葉。それが「メモリー効果」である。
憎きバッテリーの敵である。
これの対策は、使いかけの状態で充電すると徐々に本来の容量を使い切れなくなってしまうので、しっかり放電させてからしっかり充電すること。
今でもこの使い方が染みついている人は多いはず。
長持ちさせるコツは、上に書いたとおり。
保存時は、1.0Vあたりまで放電させてから保管。満充電での保管はNG、だそうだ。
ニッケル水素
ニッカドの後釜的存在。
メモリー効果からは多少解放されたものの、自己放電は増加。
過放電により一気に寿命を迎えるケースがあるため、保存時は満充電した状態にしておくことが望ましい。
なお、エネループはメモリー効果や自己放電についての特性を改善しているが、満充電での保存が推奨されている点は変わりない。
リチウムイオン
現在一般に使用されているバッテリーの中で、最も重量あたりの電力密度が高いバッテリーである。
ただし、充電制御に失敗すると発火する。
製造を少しミスっても発火する。
便利だが危険なバッテリーである。
それゆえ、セル単体で使用されることは皆無に等しく、制御回路とセットにして販売・使用されることがほとんどである。
セル単体だと思っても、実際には小さな回路を挟んでいたりする。
長持ちさせるための使用法、それは 満充電しない＆過放電しない である。
もっと具体的に言えば、残量20～80％くらいの間で使用すること。
これはバッテリーの開発者やEVの開発者、さらにはノートPCの開発者までもが口を揃えて言っていることである。
では保存はどうするか。
これも使い方と同様に、中途半端な充電状態で保存するのがベストである。
自己放電で電圧降下することを考えれば、残量70％くらいで放置しておくのがよいと思われる。
まとめると、鉛蓄電池は使ったらひたすら充電。満充電が正義。過放電は死亡フラグ。
ニッカドは使い切ってから充電。メモリー効果に注意。ただし保管時は使い切った状態で寝かせる。
ニッケル水素はメモリー効果についてはニッカドよりルーズな管理で問題なし。保管時は満充電で。自己放電が多く過放電は死亡フラグ。
リチウムイオンは充電のしすぎと放電のしすぎに注意。中途半端が正義。過放電は即死の可能性あり。
言い忘れたが、どのバッテリーも過充電と過放電がNGなのは共通認識だ。
過充電は発火、過放電は即死、というケースが多いが、そうなった場合の許容度はバッテリーによって異なるので、バッテリーに応じてしっかり考えて使ってほしい。
とはいえ、充電器を介して普通に充電し、正常に動作している機器で使用する分には全く問題ないはずだ。
問題があるとすれば過放電だ。
内部抵抗に起因する自己放電は不可避なので、放置しておけば必ず放電が進む。メンテナンスを怠れば過放電となる。
過放電は即死となるケースが多いのは前述のとおりなので、定期的なメンテナンス（充電）は欠かさないようにしたい。
それでは皆さん、ごきげんよう。
RX100M5のイメージセンサーに積層されたDRAM容量を探る
前略
HFR撮影の記録時間＝積層されたDRAMの容量限界 と考えて、どれくらいの容量が撮像素子に存在しているのか探ってみる。
画質優先と時間優先で、それぞれ解像度と撮影可能秒数が異なる。
詳細はメーカーページを参照のこと。
バッファされるデーターはRAW相当だと考え、速度優先なので読み出し8bitだと仮定して、単純計算。
そうすると、公称値の撮影可能時間が大雑把すぎるので計算結果にブレが出るものの、計算上は12Gbit～14GbitクラスのDRAMが存在することになる。
現在、最先端のDRAMチップ（ただし3Dトランジスタではないプレーナ型）の情報を集めてみると、16年末あたりで20nm（主流は8Gbitチップ）、17年中に18nm（容量変わらず）、といったところ。
ちなみに16Gbitチップが主流になるには、プロセスルールにして12nmくらいまで世代が進まないと難しいとのことで、早くても18年か、遅ければ20年といったところ。
容量増加が異様に遅いのは、プロセスの微細化が極端に難しくなっていることに端を発しているので、早急に解決することはありません。
閑話休題。
メインストリームになるDRAMチップは1チップ50～80mm2と言われている。
計算上は2015年で8Gbitチップが70mm2、2016年で60mm2くらいなので、現在は50台に乗っているはずだ。
そのため、最新のプロセスで製造した場合、現状は大雑把に言って1Gbit＝7mm2くらいだと考えられる。
SONYのCMOSイメージセンサー製造ラインがどれくらいのプロセスルールを使用しているかは不明だが、最新鋭のDRAM製造ラインよりは多少世代が落ちると考えて間違いはないはず。
となると、84mm2～98mm2より大きいサイズ、100mm2は超えてくるくらいでなければ計算が合わないことになる。
ここで撮像素子のサイズを見ると、13.2mmx8.8mmなので116.16mm2になる。
ただし半導体のダイは撮像範囲より大きいので、仮に四方に1㎜ずつ余白があるとすれば、15.2mmx10.8mmで164.16mm2になる。
積層範囲は不明、プロセスルールも不明だが、計算上は問題なさそうなので、DRAM容量については概ね計算どおりということで良いように思う。
あとは撮影時のフレーム数をカウントすれば、正確に容量が算出できそうです。
それでは皆さん、ごきげんよう。
RX100M5のS-log撮影とグレーディング
初代RX100を手放してM5にしました。
で、動画をS-log撮影できるところに興味を持った結果・・・
動画のビット数どうなってたっけ？
グレーディングってなんぞ？
ルックアップテーブル？
カラコレ？
422とか420って何がどうなってたっけ？
カラーモードって色域？
・・・などと、知りたいことや確認したいことが降って湧いたので、一度整理しておこうかと。
脳内整理用のメモです。
M5はXAVCSで撮影可能。
ところでAVCHDとXAVCとXAVCSって何が違うのか。
AVCHD（拡張規格とかは十把一絡げで含む）
28Mbpsまで
1080 60pまで
H.264
XAVC
2012年、F55と同時に発表
300Mbpsまで（規格上は960Mbps）
4k 60pまで
422対応 8bit、10bit、12bit（規格上は444対応）
IntraとLongGOP対応
ラッパーはMXF
H.264
XAVCS
2013年発表
100Mbpsまで
4k 60pまで
420まで 8bit
ラッパーはMP4
H.264
ちなみに、MPEG4 AVC / H.264 って書かれているのを見て、今までずっとAVCと264は選択制の別々のコーデックなのかと思いましたが、同義ってことで良いみたいです。
表記が紛らわしいと思うのは自分だけでしょうかね。
チャンネル4Kの納品フォーマットは、XAVC 3840x2160 59.94p 600Mbps らしい。
動画編集、安かったのでVegas持ってるんですが、どうも「VisionColor」の「LUT Plugin for Sony Vegas」っていうプラグインを入れればグレーディング用のLUT読めるらしいです。
カラーグレーディング、昔はカラーコレクションと呼ばれていたものですが、一応意味的には同義らしい。
厳密には多少違うような話もありますが、気にするほどではないかも。
ちなみに、DaVinici Resolveは無償ダウンロード可能らしい。4K編集、カラーグレーディングにまで対応しているので、とりあえず入手しておいて損はなさそうです。
あと、LUT（ルックアップテーブル）は、Log記録された動画を正常に見えるように補正するためのカーブ（ガンマ）、という認識でよさそう。
444はYとCbとCrが同じ解像度
422はCbとCrの水平方向解像度が半分
420はCbとCrの水平解像度が半分になった上に、YとCb、YとCr、という組み合わせにして垂直方向の解像度も落としている
411はCbとCrの水平解像度が1/4
ということは、4kで420撮影したものを2kに縮小したら、2kの444相当になる・・・のか？
民生用では記録できるフォーマットがなさそうですが。
ちなみにXAVCのカラーモード（色域）は選択した設定がファイルに情報として残るみたいですね。
基本はBT.709のようですが、SONYのS-Gamutとか広色域のカラーモードも選べるとか。
ディスプレイがついてこないし、撮影時にそれだけの色域の情報を拾い切れているのか判断できないけど、今後のために広色域で撮影しておいて損はないのかも。
もっとも、Log記録については、現状のような8bit記録のフォーマットが主流だと、ちょっと調整するとすぐにバンディングノイズが出てしまうので、まだ実用的とは言い難いです。
プロの真似事ができる程度。
せめて10bit記録が搭載されないと、厳しいのではないかな。
そういう意味では、GH5って頑張ってますね。
Intraで422で10bitで4k30pいけますからね。
4k60pにすると8bitになって420のLongになってしまうので、フレームレートは犠牲にしないといけませんが。
60pで8bitになってしまうのは、撮像素子のCMOSの動作速度の制限かな・・・と思ったら、外部出力は60pでも422の10bitが可能みたいなので、LSIの処理能力不足ですね。
ちょっと勿体ないけど、時間が解決してくれるはず。
それでは皆さん、ごきげんよう。
