19/01/12 23:26:59.04 KT4qKaj90.net
>>905
まじか
ソースある？見てみたいわ
951:名無しさん＠編集中
19/01/12 23:29:00.76 1J2iIAhQM.net
ソースも何も開発期間考えたら無理に決まってるだろ
AV1の仕様が実用上の最終確定したのいつだと思ってるの？
952:名無しさん＠編集中
19/01/13 00:19:10.60 r3v8oxdG0.net
>>906
ほいよ
URLﾘﾝｸ(www.phoronix.com)
＞There is not any AV1 acceleration yet but it's "coming soon" past Gen11 and Intel is "fully committed" to AV1.
念の為書くけど、この中の「past」は「～以後に」という「after」みたいな使い方なので、Gen 11「以前に」来ると勘違いして読まないように。
「Gen 11では対応しないが、それ以降はすぐに対応予定である」という建前を言ってるだけ。
953:名無しさん＠編集中
19/01/13 00:26:05.19 cHYCdQoL0.net
Haswellあたりは後からGPGPU使ってHEVCに対応とかさせてたのになあ
NVIDIAやAMDはもっとGPUのパワーあるのに後から対応とか全くやらないし
PCも家電と同じように10年使う時代が到来しそうになってきてるんだから頼むよ
954:名無しさん＠編集中
19/01/13 00:44:55.47 dV5twhvB0.net
そんな銭にならんこと、誰がしますかいな
アホなこといいなさんな
955:名無しさん＠編集中
19/01/13 00:49:33.87 jtEOVG3r0.net
NVIDIA、好きじゃなくなってきた
思想よくわからないし
956:名無しさん＠編集中
19/01/13 01:07:29.73 hC0jZP9x0.net
>>904
日本の地デジは同時放送期間を長く取っていたぞ
それ全く同じこと
結局期限決めなきゃ、周波数の空きがないから移行できないだろ
957:名無しさん＠編集中
19/01/13 01:10:33.83 hC0jZP9x0.net
>>901
理屈の上ではそうなるが
30pと60pしかない
958:名無しさん＠編集中
19/01/13 01:14:55.78 hC0jZP9x0.net
>>909
日本中の地上波の送信機を交換するのに、大金と8年くらいかかる
つまりリアルタイムエンコード可能な個体化したエンコーダーと、それを正確に増幅するPA
8年前にできあがっていた規格で、どんなものがある？
H.264までかな
959:名無しさん＠編集中
19/01/13 01:30:29.97 WeIUUXRq0.net
>>908
ソースと丁寧な解説ありがとう
参考になった
960:名無しさん＠編集中
19/01/13 02:59:46.16 vDg3J9sw0.net
H.264で地デジを見たけりゃ南米(ブラジル)に移住するんやなｗ
デジタル地上波がH.264で流れているんやなｗ
961:名無しさん＠編集中
19/01/13 13:04:12.23 hzF+ANxl0.net
>>913
チーン
まぁ大画面でインタレのちらつき見せられたら幻滅やしな
962:名無しさん＠編集中
19/01/13 18:00:55.61 hC0jZP9x0.net
>>917
インターレースは評判悪いが、最近のインタレ解除アルゴリズムが優秀で、59iを59p化するとなかなかきれいだしな
あと、最近のテレビのモーションフローなんかで、30pが120pで表示されるし
XAVC300の60pは600Mbpsだが、30iでいいとなれば150Mbpsで済むことになる(そんな規格はないけど)
HD放送はまさにこれやってるけど、4K8Kはフルの60pだから、処理もストレージもかなり厳しい
963:名無しさん＠編集中
19/01/13 19:10:48.18 hzF+ANxl0.net
>>918
そうは言っても細かい描写とかインターレースで消えてしまう部分の補完は無理があるから、高精細化が進んだHD以降はインターレースは害悪だと思う。
あと59iとか30iって…何？
GOPを1秒にするのはどうだろう
964:名無しさん＠編集中
19/01/13 21:21:20.21 pKYDwAOg0.net
インターレースが汚いって言う知り合いの使ってるモニタ確認させてもらうと
ほとんどがI/P変換機能の無い安物PCモニタとか使って判断してたわ
965:名無しさん＠編集中
19/01/13 21:37:06.80 pOhULN+G0.net
30iって15pってこと？そんな規格ってあるの？
966:名無しさん＠編集中
19/01/13 21:50:59.47 oSDV6/qw0.net
インターレースはエンコードするとき邪魔じゃないか？
動き探索にも邪魔だし、高周波成分マシマシだし…
967:名無しさん＠編集中
19/01/13 21:54:21.08 hC0jZP9x0.net
>>919
インターレースで消えてるのは、ある瞬間の1/59.94秒に出てきて、次の1/59.94秒には消えてるディテールな
海の遠景の小さな波しぶきなんかは、このディテールを含んでる可能性はあるが
そもそも圧縮で消えるな
ごめん、フィールド周波数59.94Hzのインターレース59.94iを59iと略称してる
30iは同じだけど、NLEアプリによっては59.94iを
「29.94fpsフィールドを有効」
と書いてるのもあって、これの省略形が29.97iか30i
968:名無しさん＠編集中
19/01/13 22:00:07.46 hC0jZP9x0.net
>>920
I/P変換は今のテレビにはほぼ入ってるからな
昔の一部ドンキ格安テレビとかPCディスプレイとか除いて
逆に、3840 x 2160 UHD 29.97pを4Kテレビで見ると、60pや120p化されててになめらかで驚く
ハリソンフォードが、「映画を24pから勝手にコマ数増やしてなめらかにして見るな！」と、視聴者に文句言ってたなw
969:名無しさん＠編集中
19/01/13 22:11:33.00 r3v8oxdG0.net
コーデックが進歩した現在だと、インタレみたいな原始的なデータの間引き方をせずに、ビットレートを半分にした方が綺麗だし。こんな物が受け入れられたのはMPEG-2時代まで
970:名無しさん＠編集中
19/01/13 22:27:27.23 r3v8oxdG0.net
最近傍ライン同士が同じブロックに詰め込まれた方が低周波成分の分布が増えて圧縮効率が良くなる。しかも解像度が上がるほどこの恩恵が増えるので、インターレースは消えるべくして消えた
971:名無しさん＠編集中
19/01/13 23:33:14.05 c/wqKywx0.net
>>912
フランスかドイツで第二世代地デジへの移行（第一世代の終了と解釈した）が行われたってtwitterで観た記憶があったからの主張なんだけど、
自分の主張の一番のコア部分は、その時々の主流を柔軟に取り入れたらいいのにってことね
AVアンプスレだとAtomosが最新トレンドなのに日本の地デジはほぼ独自でニッチな仕様の22.2chなんて・・っていう感想が元
972:名無しさん＠編集中
19/01/14 00:46:38.98 7Ua
973:QMeb/0.net
974:名無しさん＠編集中
19/01/14 00:57:30.03 CjQKr4ai0.net
まず今の時期に第2世代地デジをやるなんて普通に失策の可能性もあるんじゃないのか＞ドイツ
NHKの技術センスが壊滅的なのはまた別の話
975:名無しさん＠編集中
19/01/14 01:19:05.83 +/nGJIS00.net
>>923
59.94iは60iでいい気が…
そんな細かい事はまぁいいとして、
圧縮で消えた上でインターレースはキツい。あと文字やテロップも厳しい。
29.94fpsフィールド？
29.97フレームの59.94フィールドって意味だと思うけど…
976:名無しさん＠編集中
19/01/14 01:37:08.09 7UaQMeb/0.net
>>930
29.97fps(フレームパーセカンド)フィールドあり、の意味だろうけど
すごく紛らわしい
先日、Premiereで59.94pのGoPro素材を59.94インターレースで書き出したら、実際には119.88フィールドパーセカンドのものが出来てて、笑うしかなかった
977:名無しさん＠編集中
19/01/14 02:02:16.67 zPROB4EF0.net
>>930
文字は止まってればインターレース関係ないし、テロップは動き補償型インターレース解除なら問題ない
CMの注意書きみたいな小さい文字が動いてると問題だけど、そんな映像普通作らないから
978:名無しさん＠編集中
19/01/14 03:25:09.32 R4/8yja+0.net
NHKには高級取りのくせに無能な技術者がいるようでニュース7や9を見ていると
テロッパーとかはちゃんとした機材を適切に使ってて問題ないのが多いんだけど
ロゴとかがインタレ状態のギザギザシマシマになってるのが載ってて失笑してる
979:名無しさん＠編集中
19/01/14 09:44:35.30 yaQ1XxLJ0.net
>>932
その前提崩しはダメでしょ
980:名無しさん＠編集中
19/01/14 14:53:05.65 zPROB4EF0.net
ん？どの部分が？
981:名無しさん＠編集中
19/01/14 14:55:08.17 7qRYOu8l0.net
今更言うのもなんだが次世代コーデックの話から脱線しすぎじゃない？
982:名無しさん＠編集中
19/01/14 15:03:00.43 +/nGJIS00.net
>>932
ウチのテレビはデインターレースがカスいのかテロップの端がピクピク動くんだわ
983:名無しさん＠編集中
19/01/14 15:05:00.34 QwxIxp1T0.net
TVのエンコード事情の話全然わからないけど面白かった
まぁ確かに脱線してた気もするけど
984:名無しさん＠編集中
19/01/14 16:17:44.50 +/nGJIS00.net
ここコーデックスレだったね忘れてた
985:名無しさん＠編集中
19/01/14 18:36:22.32 rbqjp7hC0.net
ところで現状、AV1の一番速いエンコーダーどれよ
986:名無しさん＠編集中
19/01/14 20:24:41.10 MF228XEv0.net
>>940
libaom(cpu-used8)とrav1e(speed10)で比較してみたけど速度だけならrav1eのほうが1.5倍くらい速かったな
rav1eはまだマルチスレッドにすら対応してないけど
ちなみに画質はx264より悪くなるから実用性は無い
987:名無しさん＠編集中
19/01/14 20:38:43.83 rbqjp7hC0.net
>>941
唯一の利点は一般ユーザーには関係ないライセンス料てか?
結局のところハードウェアエンコーダが出ないとキツいのか・・・。
988:名無しさん＠編集中
19/01/14 20:57:05.35 gWfbxhV90.net
rav1eが実用的になってきた頃にはH.266の規格が完成してたりして
989:名無しさん＠編集中
19/01/15 02:57:06.88 YCwcf1CY0.net
H.266が実用的になるまでAV1より長い時間が必要な気がする
990:名無しさん＠編集中
19/01/15 03:42:20.59 Ex4KBApU0.net
JEM (VVCエンコーダー) でもAV1より2-3倍高速にエンコできるらしいし、技術的にHEVCの延長線上なので、2020年に制定
991:されれば数年で普及すると思うけどね。h264 > 265のが革新的な機能追加が多くて対応が大変だったはずだよ
992:名無しさん＠編集中
19/01/15 07:10:04.23 w58fMsS70.net
次世代映像符号化方式の標準化動向
URLﾘﾝｸ(www.jstage.jst.go.jp)
2016年の資料によると2020年前後らしい
993:名無しさん＠編集中
19/01/15 08:33:57.76 Ex4KBApU0.net
制定は何事もなければ2020年10月予定だよ。
とはいえハードウェアに乗るのはそこから数年掛かるかと。
994:名無しさん＠編集中
19/01/15 09:01:57.59 fl6QRCiFM.net
h265が普及してるとはとても言えない状況でav1/h266なんて回路面積喰いそうなデコーダを2つもミドルやエントリーSOCに載せてくるかな
あとav1の2～3倍ってx265のveryslowより10倍はエンコード重いだろうし最新コーデックはもう個人のCPUでは扱えない感が強くて悲しい
995:名無しさん＠編集中
19/01/15 10:33:43.72 pxlZ+57/0.net
URLﾘﾝｸ(satch.tv)
996:名無しさん＠編集中
19/01/15 13:07:37.23 09ZyehDB0.net
ゲーム配信とかで新コーデック使える日は来るのだろうか
ハードウェアエンコーダーじゃないと辛そうだけど
997:名無しさん＠編集中
19/01/15 16:03:02.41 0bta4PKJ0.net
IBMが量子コンピューターの販売始めたし、コンテンツインフラ提供してる巨大企業が
エンコードはがっつりやってくれるようになって、エンコード負荷軽減自体があまり
研究されなくなっていき、デコード効率重視になっていく近未来が見える気もする
5Gやそれを超えるような広帯域通信が普及すると、いま3DCGでレンダリングプールを
インターネット越しに企業が提供してるように、動画エンコードも素材データ送って
でかいサーバーに任せてしまうということが可能になってくるし
(超広帯域通信が普及しても4K8Kなどの高解像度化や高画質化の余地がたくさんあるから
圧縮技術のニーズがなくなる未来はまだ遠いと思う)
そうすると著作権破ってる奴らははねられてしまうから、自分でコンテンツ生み出してない奴らは
絶望することになってこのスレも過疎るんだろうな
998:名無しさん＠編集中
19/01/15 17:52:49.80 EwLADQYQM.net
ハードウェア再生支援が対応してもソフトウェア側が充分に活用できていなかったり、ソフトウェアによっては初期設定のままだとハードウェア再生支援自体が無効だったりとか、対応がまちまちすぎて困る
例えば、Windows10標準の「映画と
テレビ」は、ハードウェア再生支援自体は使えるのだが、動きが微妙にではあるがなめらかでなくなる瞬間を見かける
高画質な再生をするのに使われるPotPlayerなんかだと、ハードウェア再生支援を使えばなめらかに再生はされるのだが、デフォルト設定は無効になっていて、しかも設定項目がどこにあるかがわかりにくい
（PotPlayerの場合、音声の設定がデフォルトで正規化処理を有効にしているのも問題ではあるが。
正規化処理を有効にしていると、再生するファイルによっては音声にプツプツというようなノイズが混じることがある。）
999:名無しさん＠編集中
19/01/16 00:57:48.96 Xe3wr+RF0.net
最新のCODECって、時間軸は何秒も深く圧縮してる？
つまりハードが出来て最適化されようとも、確実に数秒以上の遅延が起こる？
1000:名無しさん＠編集中
19/01/16 03:38:10.46 rY7xXqeH0.net
してない、というかその辺は変わらない。
1001:名無しさん＠編集中
19/01/16 15:27:22.44 RJTVMrtt0.net
MediaKind-HEVC-and-AV1-white
1002:paper_FINAL.pdf https://www.mediakind.com/pdf/MediaKind-HEVC-and-AV1-whitepaper_FINAL.pdf 👀Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)
1003:名無しさん＠編集中
19/01/16 17:16:28.85 6CPf9YwEM.net
今度こそ規格決まった？
1004:名無しさん＠編集中
19/01/23 22:39:56.93 a3b964BD0.net
地デジの話が終わったら静まり返るの草
1005:名無しさん＠編集中
19/01/24 00:49:00.64 jrUkBa/90.net
x265 3.0 がリリースされ、それに対応した x265guiEx 3.92 もリリースされた。
x265のリリースノートは現時点ではまだ2.9のままなので、3.0の内容については当面は2つ目のリンクから。
URLﾘﾝｸ(x265.readthedocs.io)
URLﾘﾝｸ(bitbucket.org)
詳細は直接見てもらうとして、意識しとくべきなのは以下の３つあたりかな？
・--preset slowerのパラメータ変更があり、従来のveryslowと同じになった。
その上でveryslowにいくつかパラメータ変更が入った。
・--aq-modeのデフォルト値変更。 「1 : uniform AQ」 → 「2 : auto variance」
・--tune animationの追加
あとはDolbyVision対応とか、--hevc-aq （これが以前話に出てた新しいAQ？）の試験実装とかかな。
リリースノートに書かれてない新オプションとして、--[no-]-hrd-concat というのもある。
1006:名無しさん＠編集中
19/01/24 00:52:45.18 jrUkBa/90.net
メモ：
・slower/veryslowの変更
URLﾘﾝｸ(bitbucket.org)
・aq-modeのデフォルト値変更
URLﾘﾝｸ(bitbucket.org)
・--tune animation
URLﾘﾝｸ(bitbucket.org)
1007:名無しさん＠編集中
19/01/24 00:55:19.65 4wyanxbx0.net
Dolby VisionってHDR対応したの？
1008:名無しさん＠編集中
19/01/24 03:48:20.48 LZrqasFT0.net
>>958
どういう影響が出るのだろう
>>960
…
1009:名無しさん＠編集中
19/01/24 04:01:17.35 4mPmJ4Mz0.net
HDR対応に向けた実装開始って感じかと（仕上がるのはまだ先
1010:名無しさん＠編集中
19/01/24 04:03:34.50 LZrqasFT0.net
x265って、いまのところHDRには対応していないんだっけ？
1011:名無しさん＠編集中
19/01/24 10:42:17.03 ASPULKIF0.net
URLﾘﾝｸ(satch.tv)
1012:名無しさん＠編集中
19/01/24 23:59:46.96 gqyytZo80.net
HDR対応と言ってもエンコーダーであるx265のやることは、
・グレーディング済みのHDR映像データを受け取って
・適切にメタデータを付与してエンコードする
ということだけだと思う。
ざっくりとしか理解してないけど、
・単純なPQ方式やHLG方式なら --colormatrix や --transfer の指定だけでも済む。
・HDR10なら、--master-display とか --max-cll とかも使う。
・HDR10+なら、--dhdr10-info でダイナミックメタデータを渡す。
・Dolby Visionなら今回追加された --dolby-vision-profile や --dolby-vision-rpu を使う。
といった感じじゃないだろうか。間違ってたらすまん。
ちなみに、rigaya氏のx265バイナリだと、HDR10+用の --dhdr10-info や --dhdr10-
1013:opt が使えない模様。 ビルドする際にCmakeで ENABLE_HDR10_PLUS を有効にしていないものと思われる。 （個人でHDR10+やDolbyVisionのエンコをする人がいるのかどうかはわからんけど・・・）
1014:名無しさん＠編集中
19/01/25 00:03:45.83 MZi0onY90.net
Dolby Vision 参考ページ
・x265 delivers Dolby Vision streams! - x265
URLﾘﾝｸ(x265.org)
・Dolby Visionの公式ドキュメント類
URLﾘﾝｸ(www.dolby.com)
1015:名無しさん＠編集中
19/01/25 19:16:00.41 inxcMcXoM.net
・SDカードやUSBメモリを、テレビなどに直接つなげる4K対応メディアプレーヤー「400-MEDI023」
URLﾘﾝｸ(www.mdn.co.jp)
リモコンつきのこんなプレーヤーが普及すると、HEVCエンコードした動画を見るのが捗って助かる
1016:名無しさん＠編集中
19/01/25 22:04:00.57 uBCAXbd10.net
でもさ、PCとHDMIで繋げばいいんじゃねえの
1017:名無しさん＠編集中
19/01/26 00:55:16.71 YEK3jCy/0.net
>>967
HDRは多分対応してないとして、
・10bitのファイル（HEVC/H.264/VP9あたり）が再生できるのか
・HEVCなら4K対応とあり、それとは別にHEVCなら60fps対応とあるけど4K60fpsも再生できるのか
（ちなみにVP9だと30fpsとなっている）
といった点がいまいち曖昧だね。
こういう機器ってそういうことが多いからいまいち手を出す気になれない。
1018:名無しさん＠編集中
19/01/26 01:41:09.56 u5w7zrsr0.net
URLﾘﾝｸ(rockchip.wikidot.com)
それSoCはRockchipのRK3229らしいから10bit60fpsにも対応してるかもしれん
1019:名無しさん＠編集中
19/01/26 01:48:24.63 u5w7zrsr0.net
OEM元と思われる中国の奴はそうみたいだったけど
こっちのやつがそうなのかまではわからんけども
1020:家に
19/01/26 05:20:46.15 pZ8bVepO0.net
androidSTBの10bit対応ってH.264の10bitのみ対応とか、H.265の10bitのみ対応とかいろいろあるよね。
FireTV4K(旧箱) + KODIでH.265の10bit再生環境用意したけど、FireTVのアップデートのせいでスムーズに再生しなくなったよ。TV3台あるからFireTV4K 3台用意したのに・・・
結局、未だにRPi3 + LibreELEC でH.264・・・
1021:名無しさん＠編集中
19/01/28 11:43:15.05 xl/SIyN60.net
VVC陣営
URLﾘﾝｸ(www.mc-if.org)
ライセンス等の改善に取り組んでゆくらしい
公式twitter
mediacoding_if@mediacoding_if
1022:名無しさん＠編集中
19/01/28 11:49:50.13 Au8WsqKn0.net
消費者がテクノロジーに対して敬意と対価を払わなさ過ぎ
文句ばっか言いやがってちゃんと金を払えよ
1023:名無しさん＠編集中
19/01/28 11:58:25.93 Wr40TvVoM.net
そういう上から目線いらないから
1024:名無しさん＠編集中
19/01/28 12:55:11.19 Au8WsqKn0.net
無料で使えて当たり前ってスタンスの消費者の方が上から目線過ぎるだろ
仮に対価払っていたとしても消費者と技術提供者は対等な立場であるべき
いまの消費者側が技術提供者に対するリスペクトが無さ過ぎる現状は酷い
1025:名無しさん＠編集中
19/01/28 13:03:08.71 enDStqJ30.net
頭大丈夫か？
1026:名無しさん＠編集中
19/01/28 13:19:35.70 R7g3u1k/0.net
コーデックに関してはコンテンツや再生機器購入時にライセンス料を間接的に払ってるし意味不明なんだが
1027:名無しさん＠編集中
19/01/28 13:44:03.29 oWrit1aj0.net
私的録画補償金ってものがあってぇ…
1028:名無しさん＠編集中
19/01/28 19:10:18.43 K5npPFXq0.net
クリエイ
1029:ターの話と間違えてないか。。
1030:名無しさん＠編集中
19/01/29 01:08:13.23 3jKOmng70.net
権利や金についてはよくわからぬ
1031:名無しさん＠編集中
19/01/29 23:05:26.44 vXH0HeiX0NIKU.net
VVCはイントラ内予測も強化されるが、仮にこれを静止画フォーマットに使っても低ビットレートで綺麗になるだけでSSIM 0.95以上を目指す場合はJPEGと大してファイルサイズが変わらないというこれまで通りの流れになりそうな予感がする
1032:名無しさん＠編集中
19/01/30 00:08:27.70 Rhx7+Jz20.net
小手先の改善だけでは、そろそろ限界だろうな
1033:名無しさん＠編集中
19/01/30 02:04:25.21 jhQlqKup0.net
コーデック自体とは関係ないけど、いつかYCoCgが標準になれば良いのにな
互換のためにYCbCrを続ける事で更なるYCbCrコンテンツを日々生み出し続けて完全に負の連鎖になってる
コーデックの仕様的にサポートはされてるんだから放送業界かあるいはNetflix, YouTube, Hulu級の規模のどこかが使い始めないと永遠に普及しない
1034:名無しさん＠編集中
19/01/30 02:15:29.13 Rhx7+Jz20.net
やり方を変えるだけのメリットを見出してないんだろ、現状
数式みたいにカッチリ変換できないと使い物にならないというわけでもないし
1035:名無しさん＠編集中
19/01/30 02:35:41.34 znWPkEmL0.net
YCoCgって式が1/4単位になって計算コストが下がるだけかと思ってた
ロスレスでビット数増やせば無損失でRGBに変換できるのかな
1036:名無しさん＠編集中
19/01/30 02:43:17.06 jhQlqKup0.net
>>986
そう
>>985
YCbCrだと8ビットカラーの場合RGBとの変換だけで75%の色が失われて、400万色程度しか表現できない
1037:名無しさん＠編集中
19/01/30 02:51:51.18 jhQlqKup0.net
ビット数増やすのも計算途中だけで良い
入力と出力は共に8ビットのままYCoCgとRGBは無損失で相互変換できる
1038:名無しさん＠編集中
19/01/30 09:26:02.43 rMoOkOVi0.net
>>980
>>1
1039:名無しさん＠編集中
19/01/30 14:28:52.96 jFvPulye0.net
ワッチョイの付け方がわからん
誰か代わりにやってくれ
1040:名無しさん＠編集中
19/01/30 15:47:07.98 8vwk+mK10.net
google.co.jp
1041:名無しさん＠編集中
19/01/30 15:53:25.17 NRx6SW0mM.net
メール欄に「watch-owyyy!!!」って書けば付くお
1042:名無しさん＠編集中
19/01/30 16:21:50.21 Amc+t7YI0.net
じゃあスレ立てチャレンジしてみる
1043:名無しさん＠編集中
19/01/30 16:36:16.37 Amc+t7YI0.net
次スレ
次世代ビデオコーデック総合スレPart3 【HEVC/VP9/AV1/VVC等】
ｽﾚﾘﾝｸ(avi板)
一応即落ち防止のため20レスまで保守っとく。
ちなみにこの板はワッチョイはデフォでつくので面倒な指定は不要。
1044:名無しさん＠編集中
19/01/30 19:22:33.45 jFvPulye0.net
>>994
そうだったのか！ありがとう
1045:名無しさん＠編集中
19/01/31 02:04:22.46 EAyJdJqn0.net
>>984-988
> ビット数増やすのも計算途中だけで良い
> 入力と出力は共に8ビットのままYCoCgとRGBは無損失で相互変換できる
色々調べてみたけど、「nビット深度のRGB」をYCoCgで【無損失】で表現するなら、
・「YCoCg」の場合
Y/Co/Cgともに(n+2)ビットの深度が必要。
Coだけは(n+1)ビットの深度でもいいけどCoだけ減らすようなことはしない。
・「YCoCg-R」の場合
Yはnビット、Co/Cgは(n+1)ビットの深度が必要。
という感じで、YCoCgの方が必要なビット数が多くなるのでは？
計算途中だけじゃないと思う。
1046:名無しさん＠編集中
19/01/31 02:09:33.52 KDrCd5Bi0.net
あの、
1047:名無しさん＠編集中
19/01/31 02:10:11.53 KDrCd5Bi0.net
ちょっと聞きたいことがあるんですが
1048:名無しさん＠編集中
19/01/31 02:10:29.78 KDrCd5Bi0.net
質問いいですか？
1049:名無しさん＠編集中
19/01/31 02:34:09.28 EAyJdJqn0.net
今だ！！！1000
1050:get ￣￣￣￣￣∨￣￣￣ (´´ ∧∧ ） (´⌒(´ ⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡ ￣￣ (´⌒(´⌒;; ｽﾞｻﾞｰｰｰｰｰｯ
1051:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 195日 5時間 43分 20秒
1052:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています