IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ テンセント・アメリカ・エルエルシーの特許一覧

特表2022-525897ニューラルネットワークモデルの圧縮/解凍のための方法および装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-05-20
(54)【発明の名称】ニューラルネットワークモデルの圧縮/解凍のための方法および装置
(51)【国際特許分類】
   H04N 19/70 20140101AFI20220513BHJP
   H04N 19/96 20140101ALI20220513BHJP
   G06N 3/02 20060101ALN20220513BHJP
【FI】
H04N19/70
H04N19/96
G06N3/02
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2021555874
(86)(22)【出願日】2020-11-12
(85)【翻訳文提出日】2021-09-15
(86)【国際出願番号】 US2020060253
(87)【国際公開番号】W WO2021101790
(87)【国際公開日】2021-05-27
(31)【優先権主張番号】62/939,054
(32)【優先日】2019-11-22
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】62/939,057
(32)【優先日】2019-11-22
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】62/958,697
(32)【優先日】2020-01-08
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】17/081,642
(32)【優先日】2020-10-27
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ワン,ウエイ
(72)【発明者】
【氏名】ジアン,ウエイ
(72)【発明者】
【氏名】リィウ,シャン
【テーマコード(参考)】
5C159
【Fターム(参考)】
5C159LC09
5C159ME01
5C159RC12
5C159UA02
5C159UA05
(57)【要約】
【課題】
本開示の態様は、ニューラルネットワークモデルの圧縮/解凍のための方法および装置を提供する。いくつかの実施例において、ニューラルネットワークモデル解凍のための装置は、受信回路および処理回路を含む。処理回路は、ニューラルネットワークの表現に対応するビットストリームから、ニューラルネットワーク内で複数ブロックに適用される少なくともシンタックス要素をデコーディングする。次いで、処理回路は、ビットストリームから、シンタックス要素に基づいてブロック内の重み係数を再構成する。
【特許請求の範囲】
【請求項1】
ニューラルネットワークのデコーディングのための方法であって、
プロセッサによって、ニューラルネットワークの表現に対応するビットストリームから、前記ニューラルネットワーク内で複数ブロックに適用される少なくともシンタックス要素をデコーディングするステップと、
前記プロセッサによって、前記ビットストリームから、前記シンタックス要素に基づいて、前記複数ブロックの重み係数を再構成するステップと、
を含む、方法。
【請求項2】
前記方法は、さらに、
ニューラルネットワーク表現(NNR)ヘッダから、カーネルサイズに基づいて。コーディングツリーユニット(CTU)サイズを変更するか否かを示すフラグをデコーディングするステップと、
前記フラグによって示される前記カーネルサイズに基づく前記CTUサイズの変更をイネーブルすることに応じて、前記カーネルサイズに基づいて、前記CTUサイズを更新するステップと、
前記更新されたCTUサイズに基づいて、重みテンソルをCTUへと分割するステップと、
ビットストリームから、前記CTUの前記重み係数を再構成するステップと、
を含む、請求項1に記載の方法。
【請求項3】
前記方法は、さらに、
前記ビットストリーム内のニューラルネットワーク表現(NNR)ヘッダから、コーディングツリーユニット(CTU)サイズを示すインデックスをデコーディングするステップと、
前記インデックスによって示される前記CTUサイズに基づいて、重みテンソルをCTUへと分割するステップと、
前記ビットストリームから、前記CTUの前記重み係数を再構成するステップと、
を含む、請求項1に記載の方法。
【請求項4】
前記方法は、さらに、
前記ビットストリームから、CTU内のパーティションを示す1つ以上の分割フラグをデコーディングするステップと、
前記1つ以上の分割フラグに基づいて、前記CTUをコーディングユニット(CU)へと分割するステップと、
を含む、請求項1に記載の方法。
【請求項5】
前記方法は、さらに、
少なくとも前記シンタックス要素に基づいて、レイヤ内の量子化重み係数についてビット深度を決定するステップと、
前記ビット深度に基づいて、前記量子化重み係数についてメモリ空間を割り当てるステップと、
前記割り当てられたメモリ空間を使用して、前記ビットストリームから、前記レイヤ内の量子化重み係数をデコーディングするステップと、
を含む、請求項1に記載の方法。
【請求項6】
前記方法は、さらに
ニューラルネットワーク表現(NNR)ヘッダから、グローバルビット深度をデコーディングするステップと、
レイヤに対するレイヤヘッダから、前記グローバルビット深度からの前記レイヤのサブレイヤ内の量子化重み係数についてビット深度の差異をデコーディングするステップと、
前記グローバルビット深度と、前記グローバルビット深度からの前記ビット深度の差異との組み合わせに基づいて、前記サブレイヤ内の前記量子化重み係数について前記ビット深度を決定するステップと、
を含む、請求項5に記載の方法。
【請求項7】
前記方法は、さらに
レイヤヘッダから、レイヤ内の前記複数ブロックのスキャン順序を示すフラグをデコーディングするステップと、
前記スキャン順序に従って、前記ビットストリームから、前記複数ブロックをデコーディングするステップと、
を含む、請求項1記載の方法。
【請求項8】
前記方法は、さらに、
レイヤヘッダから、レイヤ内の次元の数、前記レイヤの形状、前記レイヤ内のコーディングユニットのスキャン順序、前記レイヤ内の飽和最大値、および、前記レイヤ内の量子化ステップサイズ、のうち少なくとも1つをデコーディングするステップと、
を含む、請求項1記載の方法。
【請求項9】
前記方法は、さらに、
バイアスサブレイヤおよび別のサブレイヤを含むレイヤに応じて、前記レイヤの前記別のサブレイヤをデコーディングする前に、前記ビットストリームから、前記レイヤの前記バイアスサブレイヤをデコーディングするステップと、
を含む、請求項1記載の方法。
【請求項10】
前記方法は、さらに、
前記ビットストリーム内のヘッダ部分からのパラメータをデコーディングするステップであり、前記パラメータは、前記ヘッダ部分の合計サイズを示している、ステップと、
前記パラメータに基づいて、前記ビットストリーム内の前記ヘッダ部分の背後にある部分にアクセスするステップと、
を含む、請求項1に記載の方法。
【請求項11】
ニューラルネットワークのデコーディングのための装置であって、処理回路を含み、
前記処理回路は、請求項1乃至10いずれか一項に記載の方法を実行するように構成されている、
装置。
【請求項12】
コンピュータ実行可能命令を保管しているコンピュータで読取り可能な記憶媒体であって、命令が実行されると、請求項1乃至10いずれか一項に記載の方法を前記コンピュータに実施させる、
コンピュータで読取り可能な記憶媒体。
【請求項13】
エンコーダにおけるニューラルネットワークのエンコーディングのための方法であって、
プロセッサによって、ニューラルネットワークの表現に対応するビットストリームへと、前記ニューラルネットワーク内で複数ブロックに適用する少なくともシンタックス要素をエンコーディングするステップと、
前記プロセッサによって、前記ビットストリームに対して、前記シンタックス要素に基づいて、前記複数ブロックの重み係数を構成するステップと、
を含む、方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、概してニューラルネットワークモデルの圧縮/解凍(compression/decompression)に関連する実施形態を説明する。
【0002】
本願は、2019年11月22日に出願された米国仮出願第62/939057号である“QUANTIZATION FOR NEURAL NETWORK MODEL COMPRESSION”、2019年11月22日に出願された米国仮出願第62/939054号である“ADAPTIVE BLOCK PARTITION FOR NEURAL NETWORK MODEL COMPRESSION”、および、2020年1月8日に出願された米国仮出願第62/958697号である“HIGH LEVEL SYNTAX FOR NEURAL NETWORK MODEL COMPRESSION”について優先権を主張する、2020年10月27日に出願された米国特許出願第17/081642号である“METHOD AND APPARATUS FOR NEURAL NETWORK MODEL COMPRESSION/DECOMPRESSION”について優先権の利益を主張する。先の出願の全ての開示は、その全体が参照により本明細書に組み込まれている。
【背景技術】
【0003】
ここにおいて提供される背景説明は、本開示のコンテキストを一般的に提示するためのものである。ここで名前が挙がっている発明者の研究は、その研究がこの背景技術セクションにおいて説明される範囲において、並びに、そうでなければ出願時には先行技術として適格でないかもしれない説明の態様において、本開示に対する先行技術として明示的に、また暗示的にも認められるものではない。
【0004】
コンピュータビジョン、画像認識、および音声認識の分野における種々のアプリケーションは、性能改善を達成するためにニューラルネットワーク(neural network)に依存している。ニューラルネットワークは、接続されたノード(ニューロンとしても参照されるもの)の集合(collection)に基づくものであり、生物学的に脳内のニューロンをゆるやかにモデル化する。ニューロンは複数の層(layer)へと編成され得る。1つの層のニューロンは、直前の層および直後の層のニューロンを結合する。生物学上の脳のシナプスのように、2つのニューロン間の結合は、一方のニューロンから他方のニューロンへ信号を伝送することができる。信号を受信するニューロンは、次いで、信号を処理し、他の結合されたニューロンへ信号を送ることができる。いくつかの実施例においては、ニューロンの出力を見つけるために、ニューロンへの入力からの結合の重みによってニューロンへの入力が重み付けされ(weighted)、そして、重み付けされた入力は、加重和を生成するために加算される。加重和に対してバイアスが加えられてよい。さらに、加重和は、出力を生成するために、アクティベーション機能(activation function)を通過する。
【発明の概要】
【0005】
本開示の態様は、ニューラルネットワークモデルの圧縮/解凍のための方法および装置を提供する。いくつかの実施例において、ニューラルネットワークモデル解凍のための装置は、受信回路および処理回路を含んでいる。処理回路は、ニューラルネットワークの表現に対応するビットストリームから、ニューラルネットワーク内の複数のブロックに適用される少なくともシンタックス要素(syntax element)をデコードする。次に、処理回路は、ビットストリームから、シンタックス要素に基づいてブロック内の重み係数を再構成する。
【0006】
いくつかの実施例において、処理回路は、ニューラルネットワーク表現ヘッダから、コーディングツリーユニットのサイズを示しているインデックスをデコーディングする。次いでに、処理回路は、インデックスによって示されるものであるCTUサイズに基づいて重みテンソル(weight sensor)をCTUへと分割し、そして、ビットストリームから、CTUの重み係数を再構成する。
【0007】
いくつかの実施形態において、処理回路は、ニューラルネットワーク表現(NNR)ヘッダから、カーネルサイズに基づいてコーディングツリーユニット(CTU)サイズを変更するか否かを示すフラグをデコーディングする。次いで、処理回路は、フラグによって示されるカーネルサイズに基づくCTUサイズの変更をイネーブルすることに応じて、カーネルサイズに基づいてCTUサイズを更新し、更新されたCTUサイズに基づいて重みテンソルをCTUへと分割し、そして、ビットストリームから、CTUの重み係数を再構成する。
【0008】
いくつかの実施例において、処理回路は、ビットストリームから、CTU内のパーティションを示す1つ以上の分割フラグをデコーディング、そして、次いで、1つ以上の分割フラグに基づいて、CTUをコーディングユニット(CU)へと分割する。
【0009】
いくつかの実施形態において、処理回路は、少なくともシンタックス要素に基づいて、レイヤ内の量子化重み係数についてビット深度を決定する。次に、処理回路は、ビット深度に基づいて量子化重み係数についてメモリ空間を割り当て、そして、割り当てられたメモリ空間を使用して、ビットストリームから、レイヤ内の量子化重み係数をデコーディングする。いくつかの実施例において、処理回路は、ニューラルネットワーク表現(NNR)ヘッダから、グローバルビット深度をデコーディングし、そして、レイヤに対するレイヤヘッダから、グローバルビット深度からのビット深度の差異(difference)を復号する。次いで、処理回路は、グローバルビット深度と、グローバルビット深度からのビット深度の差異との組み合わせに基づいて、レイヤ内の量子化された量子化重み係数についてビット深度を決定する。
【0010】
いくつかの実施例において、処理回路は、レイヤヘッダから、レイヤ内の複数のブロックのスキャン順序を示すフラグをデコーディングし、そして、スキャン順序に従って、ビットストリームからブロックをデコーディングする。
【0011】
一つの実施例において、処理回路は、レイヤヘッダから、レイヤ内の次元の数、レイヤの形状、レイヤ内のコーディングユニットのスキャン順序、レイヤ内の飽和最大値、および、レイヤ内の量子化ステップサイズ、のうち少なくとも1つをデコーディングする。
【0012】
いくつかの実施例において、処理回路は、バイアスサブレイヤおよび他のサブレイヤを含むレイヤに応じて、レイヤの別のサブレイヤをデコーディングする前に、ビットストリームから、レイヤのバイアスサブレイヤをデコーディングする。
【0013】
いくつかの実施例において、処理回路は、ビットストリーム内のヘッダ部分からのパラメータをデコードし、本パラメータは、ヘッダ部分の合計サイズを示しており、そして、パラメータに基づいて、ビットストリーム内のヘッダ部分の背後にある部分にアクセスする。
【0014】
本開示の態様は、また、命令を保管しているコンピュータで読取り可能な媒体を提供も提供する。命令は、ニューラルネットワークモデル解凍のためにコンピュータによって実行されると、コンピュータに、ニューラルネットワークモデル解凍のための方法を実行させる。
【図面の簡単な説明】
【0015】
開示される技術的事項のさらなる特徴、性質、および種々の利点が、以下の詳細な説明および添付の図面からより明らかになるだろう。
図1図1は、本開示の一つの実施形態に従った、電子機器130のブロック図を示している。
図2図2は、重みテンソル(weight tensor)の量子化を実行するための一つの実施例を示している。
図3図3は、本開示のいくつかの実施形態に従った、8ビット表現へのクリッピングおよびマッピング係数の一つの実施例を示している。
図4図4は、本開示のいくつかの実施形態に従った、量子化重み係数の絶対値をデコードするための一つの実施例を示している。
図5A図5Aは、本開示のいくつかの実施形態に従った、シンタックステーブルの実施例を示している。
図5B図5Bは、本開示のいくつかの実施形態に従った、シンタックステーブルの実施例を示している。
図6図6は、マトリクス乗算ライブラリ内のルーチンを説明している図を示している。
図7図7は、本開示のいくつかの実施形態に従った、テンソル分割を説明している図を示している。
図8A図8Aは、本開示のいくつかの実施形態に従った、シンタックスの実施例を示している。
図8B図8Bは、本開示のいくつかの実施形態に従った、シンタックスの実施例を示している。
図8C図8Cは、本開示のいくつかの実施形態に従った、シンタックスの実施例を示している。
図9A図9Aは、本開示のいくつかの実施形態に従った、分割およびスキャン順序の実施例を示している。
図9B図9Bは、本開示のいくつかの実施形態に従った、分割およびスキャン順序の実施例を示している。
図10A図10Aは、本開示のいくつかの実施形態に従った、分割のための例示的なシンタックステーブルを示している。
図10B図10Bは、本開示のいくつかの実施形態に従った、分割のための例示的なシンタックステーブルを示している。
図11図11は、本開示の一つの実施形態に従った、一つの例示的なシンタックステーブルを示している。
図12図12は、本開示の一つの実施形態に従った、別の例示的なシンタックステーブルを示している。
図13図13は、本開示の一つの実施形態に従った、一つの例示的なシンタックスを示している。
図14図14は、本開示のいくつかの実施形態に従った、プロセスの実施例を概説するフローチャートを示している。
図15図15は、一つの実施形態に従った、コンピュータシステムの概略図である。
【発明を実施するための形態】
【0016】
本開示の態様は、ニューラルネットワークモデルの圧縮/解凍のための種々の技術を提供する。本技術は、ニューラルネットワークモデルの圧縮/解凍における量子化技術、パーティション技術、およびシンタックス要素を含んでいる。
【0017】
人工ニューラルネットワークは、マルチメディア解析、および、処理、メディアコーディング、データ解析、および他の多くの分野における広範なタスクについて採用され得る。人工ニューラルネットワークの使用の成功は、過去よりも、ずっと大規模で、かつ、複雑なニューラルネットワーク(ディープニューラルネットワーク、DNN)の処理の実現可能性、および、大規模な訓練(training)データセットの利用可能性に基づいている。その結果、訓練されたニューラルネットワークは、多数のパラメータおよび重みを含むことができ、非常に大きなサイズ(例えば、数百MB)を結果として生じている。多くのアプリケーションは、特定の訓練されたネットワークインスタンスの展開を必要とし、潜在的には、より多くのデバイスへの展開であり、それらは、処理能力およびメモリ(例えば、モバイル機器またはスマートカメラ)の観点で、そして、また、通信帯域幅の点でも、制限を有し得るものである。
【0018】
図1は、本開示の一つの実施形態に従った、電子機器130のブロック図を示している。電子機器130は、ニューラルネットワークに基づいてアプリケーションを実行するように構成されている。いくつかの実施形態において、電子機器130は、ニューラルネットワークの表現としても参照される、圧縮ニューラルネットワークモデルを保管している。電子機器130は、圧縮ニューラルネットワークモデルを復元するために、圧縮ニューラルネットワークモデルを解凍することができ、そして、ニューラルネットワークモデルに基づくアプリケーションを実行することができる。
【0019】
いくつかの実施形態においては、圧縮ニューラルネットワークモデルが、アプリケーションサーバ110といった、サーバから提供される。電子機器130は、圧縮ニューラルネットワークモデルを復元するために圧縮ニューラルネットワークモデルを解凍することができ、そして、ニューラルネットワークモデルに基づくアプリケーションを実行することができる。
【0020】
図1の実施例において、アプリケーションサーバ110は、一緒に結合された、処理回路120、メモリ115、およびインターフェイス回路111を含んでいる。いくつかの実施例において、ニューラルネットワークは、適切に生成され、訓練され、または、更新される。ニューラルネットワークは、ソースニューラルネットワークモデルとしてメモリ115内に保管され得る。処理回路120は、ニューラルネットワークモデル・コーデック121を含んでいる。ニューラルネットワークモデル・コーデック121は、ソースニューラルネットワークモデルを圧縮し、かつ、ニューラルネットワークの表現である圧縮ニューラルネットワークモデルを生成することができる、エンコーダを含んでいる。いくつかの実施例において、圧縮ニューラルネットワークモデルは、ビットストリームの形態(form)である。圧縮ニューラルネットワークモデルは、メモリ115内に保管され得る。アプリケーションサーバ110は、インターフェイス回路111を介して、ビットストリームの形態で、圧縮ニューラルネットワークモデルを、電子機器130といった、他のデバイスに提供することができる。
【0021】
電子機器130は、スマートフォン、カメラ、タブレットコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ、ゲーミングヘッドセット、等といった、任意の適切な装置であり得ることに留意する。
【0022】
図1の実施例において、電子機器130は、一緒に結合された、処理回路140、キャッシュメモリ150、メインメモリ160、およびインターフェイス回路131を含んでいる。いくつかの実施例において、圧縮ニューラルネットワークモデルは、例えばビットストリームの形態で、インターフェイス回路131を介して電子機器130によって受信される。圧縮ニューラルネットワークモデルは、メインメモリ160内に保管されている。
【0023】
処理回路140は、中央処理装置(CPU)、グラフィックス処理装置(GPU)、等といった、任意の適切な処理ハードウェアを含んでいる。処理回路140は、ニューラルネットワークに基づいてアプリケーションを実行するための適切なコンポーネントを含み、そして、ニューラルネットワークモデル・コーデック141として構成された適切なコンポーネントを含んでいる。ニューラルネットワークモデル・コーデック141は、圧縮ニューラルネットワークモデルをデコードすることができるデコーダを含んでいる。一つの実施形態において、処理回路140は、単一チップ上に配置された1つ以上のプロセッサを有する単一チップを含んでいる。別の実施例において、処理回路140は、複数のチップを含み、そして、各チップは、1つ以上のプロセッサを含み得る。
【0024】
いくつかの実施形態において、メインメモリ160は、比較的に大きな記憶スペースを有しており、ソフトウェアコード、メディアデータ(例えば、ビデオ、オーディオ、画像、等)、圧縮ニューラルネットワークモデル、等といった、様々な情報を保管することができる。キャッシュメモリ150は、比較的に小さな記憶スペースを有しているが、メインメモリ160と比較して、はるかに速いアクセス速度を有する。いくつかの実施例において、メインメモリ160は、ハードディスクドライブ、ソリッドステートドライブ、等を含み、そして、キャッシュメモリ150は、スタティックランダムアクセスメモリ(SRAM)、等を含み得る。一つの実施形態において、キャッシュメモリ150は、例えば、プロセッサチップ上に配置されるオンチップメモリであり得る。別の実施例において、キャッシュメモリ150は、プロセッサチップから分離された1つ以上のメモリチップ上に配置されたオフチップ(off chip)メモリであり得る。一般的に、オンチップメモリは、オフチップメモリよりも速いアクセス速度を有している。
【0025】
いくつかの実施形態において、処理回路140が、ニューラルネットワークモデルを使用するアプリケーションを実行する場合、ニューラルネットワークモデル・コーデック141は、圧縮ニューラルネットワークモデルを復元するために圧縮ニューラルネットワークモデルを解凍することができる。いくつかの実施例において、キャッシュメモリ150は十分に大きく、従って、復元されたニューラルネットワークモデルは、キャッシュメモリ150内にバッファされ得る。次いで、処理回路140は、復元されたニューラルネットワークモデルをアプリケーションで使用するために、キャッシュメモリ150にアクセスすることができる。別の実施例において、キャッシュメモリ150は、限られたメモリスペース(例えば、オンチップメモリ)を有しており、圧縮ニューラルネットワークモデルは、層毎に、またはブロック毎に解凍され、そして、キャッシュメモリ150は、復元されたニューラルネットワークモデルを、層毎またはブロック毎にバッファすることができる。
【0026】
ニューラルネットワークモデル・コーデック121およびニューラルネットワークモデル・コーデック141は、任意の適切な技術によって実装され得ることに留意する。いくつかの実施形態において、エンコーダ及び/又はデコーダは、集積回路によって実装され得る。いくつかの実施形態において、エンコーダおよびデコーダは、非一時的なコンピュータで読取り可能な媒体に保管されたプログラムを実行する1つ以上のプロセッサとして実装され得る。ニューラルネットワークモデル・コーデック121およびニューラルネットワークモデル・コーデック141は、以下に説明されるエンコーディング(encoding)およびデコーディング(decoding)機能に従って、実装され得る。
【0027】
視覚的な分析および理解のためのビデオ符号化技術は、標準化され得る。一つの実施例において、視覚的検索のためのコンパクト記述子(compact descriptors for visual search、CDVS)標準は、静止画像から画像類似性マッチングのための特徴表現を抽出する技術を含み得る。別の実施例において、視覚的分析のためのコンパクト記述子(CDVS)標準は、ビデオセグメントについて、グローバルおよびローカル、ハンドデザイン(hand-design)およびDNNベースの特徴記述子を抽出する技術を含み得る。
【0028】
本開示は、保管および計算の両方を節約するために、ディープニューラルネットワーク(DNN)モデルといった、ニューラルネットワークモデルをエンコーディングおよびデコーディングするために使用され得るニューラルネットワーク表現(neural network representation、NNR)のための技術を提供する。ディープニューラルネットワーク(DNN)は、セマンティック分類、ターゲット検出/認識、ターゲット追跡、ビデオ品質向上、等といった、広範囲のビデオアプリケーションにおいて使用され得る。
【0029】
(人工)ニューラルネットワークは、一般的に、入力層と出力層との間に複数の層を含んでいる。いくつかの実施例において、ニューラルネットワークにおける層は、層の入力を層の出力へと変えるための数学的操作に対応している。数学的操作は、線形関係または非線形関係であり得る。ニューラルネットワークは、各出力の確率を計算している層を通じて移動することができる。各数学的操作それ自体は、層と見なされ、そして、複雑なDNNは、多くの層を有し得る。いくつかの実施例において、層の数学的操作は、重み係数およびバイアスを有する重みテンソル(weight sensor)によって表され得る。
【0030】
スキャン順序(scan order)技法、量子化技法、エントロピー符号化技法、等といった、種々の技法は、ニューラルネットワークモデルのエンコーディング/デコーディングにおいて使用され得る。
【0031】
スキャン順序技法のいくつかの実施例において、重みテンソルの次元(dimension)は、2より大きく(畳み込みレイヤにおいては4、といったもの)、そして、重みテンソルは、2次元テンソルへと再形成され得る。一つの実施例において、重みテンソルの次元が2以下の場合(完全に結合された層またはバイアス層といったもの)、再成形は実行されない。
【0032】
重みテンソルを符号化するために、重みテンソルにおける重み係数が、所定の順序に従ってスキャンされる。いくつかの実施例において、重みテンソルにおける重み係数は、各行(row)については左から右へ、かつ、複数の行については最上行から最下行へ、行優先(row-first)の方法でスキャンされ得る。
【0033】
図2は、重み係数をスキャンし、そして、重みテンソルの量子化を実行するためのシンタックスの実施例を示している。
【0034】
関連するいくつかの実施例において、重みテンソルの次元が2より大きい場合、重みテンソルは2次元重みテンソルへ再成形される。2次元重みテンソル内の重み係数は、各行については左から右へ、かつ、複数の行については最上行から最下行へ、行優先の方法でスキャンされ得る。
【0035】
重み係数を量子化するために、いくつかの実施例においては、固定ステップサイズ量子化が適用され得る。いくつかの実施例において、ニューラルネットワークの層における重み係数の分布は、ガウス分布に従っており、大きな値を有する重み係数のパーセンテージは非常に小さいが、重み係数の最大値は非常に大きくあり得る。いくつかの実施形態において、エンコーダは、層における量子化重み係数についてビット深度(bitdepthとして示されるもの)を決定することができる。ビット深度は、7ビットといった、量子化重み係数の絶対値を表すために使用されるビット数である。次いで、エンコーダは、ビット深度について最適飽和最大値を決定するために、カルバック-ライブラー(Kullback-Leibler)発散手段(divergence measure)に基づくといった、最適化アルゴリズムを使用することができる。重み係数が、飽和最大値に基づいて定義される範囲の外である場合、重み係数は、飽和最大値へクリップされる。次いで、層の重み係数は、[-(2bitdepth-1),2bitdepth-1]の範囲で、整数に対して一様に量子化され得る。例えば、最近傍(整数)量子化が、各重み係数に対して均一な方法で適用され得る。具体的に、重み係数は、範囲内で最も近い整数へ量子化される。最も近い整数(量子化重み係数、量子化重みレベル、等としても、また、参照されるもの)が、適切にコード化され得る。
【0036】
図3は、本開示のいくつかの実施形態に従った、7ビット絶対値表現へのクリッピングおよびマッピング係数の一つの実施例を示している。いくつかの実施例において、エンコーダは、量子化重み係数に対して合計8ビット表現を使用することを決定し、従って、量子化重み係数の絶対値について7ビットを使用することができ、そして、ビット深度は7である。次いで、エンコーダは、最適化アルゴリズムに基づいて、最適な飽和最大値T(layer_sat_maxwとしても示されるもの)を決定する。重み係数が[-|T|,|T|]の範囲から外れた場合、重み係数は、どちらが近いかに応じて、よって-|T|又は|T|にクリップされる。例えば、2つの重み係数(301)および(302)が[-|T|,|T|]の範囲外であり、かつ、-|T|により近く、従って、2つの重み係数(301)および(302)-|T|にクリップされる。次いで、重み係数は、[-127,127]の範囲の整数へ一様に量子化される。例えば、2つの重み係数(301)および(302)は、-127に量子化される。
【0037】
一つの実施形態において、飽和最大値Tは、32ビット浮動小数点の数によって表され得る。そして、エンコーダは、レイヤヘッダ(layer header)内といった、ビットストリーム内に飽和最大値Tを含むことができる。別の実施形態において、飽和最大値Tは、Nビット分数精度(fractional accuracy)を維持しながら、整数へ変換され得る。例えば、飽和最大値Tの整数(int_layer_sat_maxw)は、int_layer_sat_maxw = int(ceil(layer_sat_maxw × (2N)))で計算され得る。一つの実施例において、エンコーダは、レイヤヘッダ内といった、ビットストリーム内にint_layer_sat_maxwを含み、そして、デコーダは、例えば、rec_layer_sat_maxw = (float)int_layer_sat_maxw / (2N)を使用して、飽和最大値(rec_layer_sat_maxw)を再構成することができる。
【0038】
別の実施形態においては、ステップサイズ(stepsizeで示されるもの)が、適切に決定され、そして、飽和最大値の代わりにビットストリーム内に含まれている。例えば、ステップサイズは、stepsize = layer_sat_maxw / (2bitdepth-1)と計算される。一つの実施例において、ステップサイズは、32ビット浮動小数点の数として定義され、そして、ビットストリームで符号化される。従って、デコーダが、ビットストリーム、ステップサイズ、および、重み係数に対応する整数からデコードする場合に、デコーダは、整数とステップサイズの乗算として、重み係数を再構成することができる。
【0039】
量子化重み係数を符号化するために、エントロピー符号化技法が使用され得る。いくつかの実施形態において、量子化重み係数の絶対値は、固定長シーケンスが後に続き得る単項(unary)シーケンスを含むシーケンスで符号化される。
【0040】
いくつかの実施例において、レイヤ内の重み係数の分布は、一般的に、ガウス分布に従い、そして、大きな値を有する重み係数のパーセンテージは非常に小さいが、重み係数の最大値が非常に大きくあり得る。いくつかの実施形態において、非常に小さい値は、単項コーディングを使用して符号化され得る。そして、より大きな値は、ゴロム(Golomb)コーディングに基づいて符号化され得る。例えば、maxNumNoRemとして参照される整数パラメータは、ゴロムコーディングが使用されない場合の最大数を示すために使用される。量子化重み係数がmaxNumNoRemより大きくない(例えば、等しいか小さい)場合、量子化重み係数は単項コーディングによって符号化され得る。量子化重み係数がmaxNumNoRemより大きい場合、maxNumNoRemに等しい量子化重み係数の一部が単項コーディングによって符号化され、そして、量子化重み係数のリマインダ(reminder)がゴロムコーディングによって符号化される。従って、単項シーケンスは、単項コーディングの第1部分と、指数ゴロム剰余ビット(exponential Golomb remainder bits)のコーディングのためのビットに係る第2部分とを含む。
【0041】
いくつかの実施形態において、量子化重み係数は、以下の2つのステップによって符号化され得る。
【0042】
第1ステップでは、量子化重み係数のために、バイナリシンタックス要素sig_flagが符号化される。バイナリシンタックス要素sig_flagは、量子化重み係数がゼロに等しいか否かを指定する。sig_flagが1に等しい場合(量子化重み係数がゼロに等しくないことを示している)、バイナリシンタックス要素sign_flagは、さらに符号化される。バイナリシンタックス要素sign_flagは、量子化重み係数が正か負かを示している。
【0043】
第2ステップでは、量子化重み係数の絶対値が、固定長シーケンスが後に続き得る単項シーケンスを含むシーケンスへとコード化され得る。量子化重み係数の絶対値がmaxNumNoRemに等しいか、より小さい場合、シーケンスは、量子化重み係数の絶対値の単項コーディングを含む。量子化重み係数の絶対値がmaxNumNoRemより大きい場合、単項シーケンスは、単項コーディングを使用してmaxNumNoRemを符号化するための第1部分、および、指数ゴロム剰余ビットの符号化のための第2部分を含み得る。そして、固定長シーケンスは、固定長剰余を符号化するためのものである。
【0044】
いくつかの実施例においては、まず単項コーディングが適用される。例えば、jといった、変数はゼロで初期化され、そして、別の変数Xはj+1に設定される。シンタックス要素abs_level_greater_Xがエンコードされる。一つの実施例において、量子化重みレベルの絶対値が変数Xよりも大きい場合、abs_level_greater_Xが1に設定され、単項エンコーディングが継続する。そうでなければ、abs_level_greater_Xがゼロに設定され、そして、単項エンコーディングが行われる(done)。abs_level_greater_Xが1に等しく、かつ、変数jがmaxNumNoRemよりも小さい場合、変数jは1だけ増加され、そして、変数Xも1だけ増加される。次いで、さらなるシンタックス要素abs_level_greater_Xがエンコードされる。プロセスは、abs_level_greater_Xがゼロに等しいか、または、変数jがmaxNumNoRemに等しいまで続く。変数jがmaxNumNoRemに等しい場合、エンコードされたビットは単項シーケンスの第1部分である。
【0045】
abs_level_greater_Xが1に等しく、かつ、jがmaxNumNoRemに等しい場合、コーディングは、ゴロムコーディングを用いて継続する。具体的に、変数jはゼロにリセットされ、そして、Xは1<<jに設定される。単項コーディングリマインダは、量子化重み係数の絶対値からmaxNumNoRemを引いた値の絶対値として計算され得る。シンタックス要素abs_level_grrater_thanXがエンコードされる。一つの実施例において、単項コーディング・リマンダが変数Xより大きい場合、abs_level_greater_Xは1に設定され、そうでなければ、abs_level_greater_Xはゼロに設定される。abs_level_greater_Xが1に等しい場合、変数jは1だけ増加され、そして、1<<jがXに加算され、そして、さらにabs_level_greater_Xがエンコードされる。このプロシージャはabs_level_greater_Xがゼロに等しくなるまで続けられ、従って、単項シーケンスの第2部分が符号化される。abs_level_greater_Xがゼロに等しい場合、単項コーディングリマインダは値(X,X-1,...X-(1<<j)+1)のうち1つであり得る。長さjのコードは、(X,X-1,...X-(1<<j)+1)における1つの値を指すインデックスをコード化するために採用され得る。コードは、固定長剰余として参照され得る。
【0046】
図4は、本開示のいくつかの実施形態に従った、量子化重み係数の絶対値をデコードするための一つの実施例を示している。図4の実施例において、QuantWeight[i]はアレイ内のi番目の位置での量子化重み係数を示し、sig_flagは量子化重み係数QuantWeight[i]が非ゼロであるか否かを指定し(例えば、ゼロであるsig_flagは、QuantWeight[i]がゼロであることを示す)、sig_flagは量子化重み係数QuantWeight[i]が正であるか負であるかを指定し(例えば、1であるsig_flagはQuantWeight[i]が負であることを示す)、abs_level_greater_x[j]はQuantWeight[i]の絶対レベルがj+1より大きい(例えば、単項シーケンスの第1部分)か否かを示し、abs_level_greater_x2[j]は指数ゴロム剰余の単項部分(例えば、単項シーケンスの第2部分)を構成し、abs_remainderは固定長剰余を示している。
【0047】
本開示の一つの態様に従って、コンテキストモデリングアプローチは、3つのフラグであるsig_flag、sign_flag、およびabs_level_geater_Xのコーディングにおいて使用され得る。従って、同様の統計的な挙動を有するフラグは、同じコンテキストモデルに関連付けることができ、そうして、(コンテキストモデルの内部の)確率推定器(probability estimator)は、基礎となる(underlying)統計に適応し得る。
【0048】
一つの実施例において、コンテキストモデリングアプローチは、左側へ隣接する量子化重み係数がゼロか、ゼロより小さいか、または、大きいかに応じて、sig_flagに対して3つのコンテキストモデルを使用する。
【0049】
別の実施例において、コンテキストモデルアプローチは、左側へ隣接する量子化重み係数がゼロか、ゼロより小さいか、または、大きいかに応じて、sign_flagに対して3つの他のコンテキストモデルを使用する。
【0050】
別の実施例において、abs_level_greater_Xフラグそれぞれについて、コンテキストモデリングアプローチは、1つまたは2つの別々のコンテキストモデルを使用する。一つの実施例においては、X<=maxNumNoRemの場合、sign_flagに応じて2つのコンテキストモデルが使用される。X>maxNumNoRemの場合、一つの実施例においては、1つのコンテキストモデルのみが使用される。
【0051】
本開示のいくつかの態様は、量子化のためのさらなる技法を提供する。いくつかの実施例において、ステップサイズは、32ビット浮動小数点の数として定義され、そして、デコーダは、レイヤの量子化重み係数のデコーディングが完了する前に、レイヤ内の量子化重み係数の最大ビット深度の情報を有していない。いくつかの実施例において、デコーダは、32ビットといった、最大可能ビット深度を有する量子化重み係数のためにメモリを割り当てる必要があり得る。レイヤの最大ビット深度が32ビットよりもはるかに小さい場合には、メモリ使用が浪費され得るし、そして、推論演算の速度が低減され得る。
【0052】
本開示の態様は、ビットストリームにおいてビット深度情報を提供する技法を提供する。従って、デコーダは、レイヤの量子化重み係数のデコーディングが終了する前に、ビット深度情報を認識する。デコーダは、ビット深度情報に基づいて、量子化重み係数を保管するためにメモリ空間を割り当てることができる。従って、メモリ空間がより効率的に利用され得る。
【0053】
一つの実施形態において、量子化重み係数のビット深度は、レイヤヘッダ内に含まれている。ビット深度は、可変長符号化または固定長符号化のいずれかを使用して符号化され得る。
【0054】
図5Aは、本開示の一つの実施形態に従った、レイヤヘッダ内のシンタックステーブル(510)の一つの実施例を示している。シンタックステーブル(510)は、レイヤにおいて重み係数の量子化および非量子化のために使用されるレイヤ内のステップサイズ(layer_stepsize)およびビット深度(layer_bitdepth)を含んでいる。いくつかの実施例においては、ビット深度に基づいて、デコーダは、デコードされた量子化重み係数を保管するためのメモリ空間を割り当てることができる。さらに、量子化重み係数がデコードされた後で、デコーダは、ステップサイズおよび量子化重み係数に基づいて、重み係数を再構成することができる。ステップサイズおよび量子化重み係数の乗算、といったものである。
【0055】
別の実施形態において、量子化重み係数のビット深度および飽和最大値は、レイヤヘッダ内に含まれ得る。
【0056】
図5Bは、本開示の一つの実施形態に従った、レイヤヘッダ内のシンタックステーブル(520)の別の実施例を示している。シンタックステーブル(520)は、レイヤにおいて重み係数の量子化および非量子化に使用できるレイヤ内のビット深度(layer_bitdepth)および飽和最大値(layer_sat_maxw)を含んでいる。いくつかの実施例においては、ビット深度に基づいて、デコーダは、デコードされた量子化重み係数を保管するためのメモリ空間を割り当てることができる。さらに、ビット深度および飽和最大値に基づいて、デコーダは、ステップサイズを決定することができる。次いで、量子化重み係数がデコードされた後で、デコーダは、ステップサイズおよび量子化重み係数に基づいて、重み係数を再構成することができる。ステップサイズおよび量子化重み係数の乗算、といったものである。
【0057】
飽和最大値は、浮動小数点数または整数で表され得ることに留意する。飽和最大値が整数として表される場合、飽和最大値は、可変長コーディングまたは固定長コーディング方法のいずれかを使用して符号化され得る。
【0058】
本開示のいくつかの態様に従って、オンチップ(on-chip)メモリは、オフチップ(off-chip)メモリと比較して比較的高いアクセス速度を有することができ、そして、オンチップメモリは、マトリクス乗算(multiplication)における使用のために好ましい。しかしながら、オンチップメモリは比較的に小さい。いくつかの実施形態においては、ブロックマトリクス乗算が使用され得る。マトリクスは、ブロックベースの乗算のためにブロックへと分割され得る。いくつかの実施例においては、2つのブロックの乗算のために、2つのブロックおよび結果をキャッシュするためにオンチップメモリ内の十分なスペースが割り当てられる場合に、2つのブロックの乗算は、オンチップメモリへのアクセスに基づいて実行され得る。本開示の態様は、重みテンソルをブロックへと分割し、そして、ビットストリームにおいて分割情報を提供するための技法を提供する。従って、デコーダは、ビットストリームから分割情報を決定し、そして、ブロック毎に重み係数をデコードすることができる。
【0059】
例えば、ディープラーニングシステムのための推論演算(operation)は、マトリクス乗算を集中的に使用する。いくつかの実施形態において、マトリクス乗算は、一般マトリクス乗算(GEMM)ライブラリを使用して実行され得る。GEMMライブラリは、マトリクスを分割すること、および、分割されたマトリクス乗算を実行することのために様々なルーチンを含んでいる。いくつかの実施例においては、マトリクス乗算における左側(left-hand-side、lhs)マトリクスおよび右側(right-hand-side、rhs)マトリクスのサイズに応じて、2つのGEMMルーチン(GEPP/GEBP、GEPM/GEBP)が使用され得る。
【0060】
図6は、GEPP/GEBPルーチンおよびGEPM/GEBPルーチンを説明している図を示す。両方のGEMMルーチンは、現在のコンピューティングプラットフォームにおいてオフチップメモリ(DDRといったもの)およびオンチップメモリ(マルチレベルキャッシュといったもの)の異なる特性を最大限に利用するために、lhsマトリクスおよびrhsマトリクスを再帰的に分割する。いくつかの実施例において、lhsマトリクスは、最適なメモリアクセスパターンを達成するために、列主導(column-major)の順序で保管されることが好ましい。
【0061】
いくつかの関連する実施例において、マトリックススキャン順序は、左から右への行先行(row-first)方法、および、上から下への行として定義される。このスキャン順序は、推論演算によって必要とされる好ましいメモリアクセスパターンと一致しない。従って、推論演算のためには、推論演算を開始する前に重み係数が過度にバッファされる。例えば、完全接続(fully-connected)レイヤについて推論演算が実行される場合には、完全接続レイヤのマトリクスサイズが25088×4096であるとすれば、GEMMルーチンを実行するために、N×25088の重み係数を保管できるバッファがリザーブされなければならない。通常のGEMM動作についてN=64である場合には、係数が32ビット浮動小数点の代わりに8ビット整数で表現されているとしても、バッファサイズは1.5MBになる。そうしたバッファサイズは、特に、モバイル機器およびエッジデバイスにとっては高過ぎる。
【0062】
本開示のいくつかの態様に従って、lhsテンソル(例えば、重みテンソル)は、3Dコーディングツリーユニット(CTU3D、または、短くCTU)へと分割され得る。各CTU3Dは、3Dコーディングユニット(CU3D、または、短くCU)へと分割され得る。CTU3Dのスキャン順序はCTU3Dスキャン順序として参照され、CTU3DにおけるCU3Dのスキャン順序はCU3Dスキャン順序として参照され、そして、CU3Dにおける重み係数のスキャン順序はCU3Dスキャン順序の中で参照される。いくつかの実施例において、パーティションおよびスキャン順序に関する情報は、NNRヘッダ、レイヤヘッダ、等といった、種々のレベルのヘッダ内に含まれ得る。パーティションおよびスキャン順序に関する情報は、また、いくつかの実施例においては、予め定義され、または、推測され得ることにも留意する。本開示における用語「ブロック(“block”)」は、CTU3D、またはCU3D等として解釈され得るに留意する。
【0063】
いくつかの実施形態において、重みテンソルは、2つ以上の次元を含むことができる。例えば、lhsテンソルは、列主導(column-major)の順序で保管され得る重み係数を含んでいる。別の実施例において、lhsテンソルは、行主導(row-major)テンソルの形式で保管され、そして、lhsテンソルは行主導テンソルの転置(transpose)によって獲得され得る。いくつかの実施例において、重みテンソルの次元は、[R][S][C][K]のレイアウトを有する畳み込みレイヤ(いくつかの実施例においてはサブレイヤ)について、4であり得る。[C][K]のレイアウトを有する完全接続レイヤ(いくつかの実施例においてはサブレイヤ)について、2であり得る。そして、バイアスレイヤ(いくつかの実施例においてはサブレイヤ)およびバッチ正規化レイヤ(いくつかの実施例においてはサブレイヤ)について、1であり得る。RおよびSは畳み込みカーネルサイズを示し、Cは入力フィーチャーサイズであり、そして、Kは出力フィーチャーサイズである。
【0064】
畳み込みレイヤの実施例において、2次元カーネル2D[R][S]は、1次元カーネル1D[RS](1次元のサイズはR×Sに等しい)へ再成形され得る。従って、4次元テンソル4D[R][S][C][K]は、3次元テンソル3D[RS][C][K]へ再成形され得る。完全接続レイヤは、R=S=1である3次元テンソルの特殊なケースとして取り扱われ得る。
【0065】
一般的に、カーネルサイズRSは、たいてい、入力フィーチャーサイズCおよび出力フィーチャーサイズKよりもはるかに小さい。本開示の一つの態様に従って、3Dテンソル[RS][C][K]は、[C][K]平面に沿って、3Dコーディングツリーユニット(CTU3D)として参照される、オーバーラップしない(non-overlapping)より小さなブロックへと分割され得る。各CTU3Dは、[RS][ctu3d_height][ctu3d_width]の形状(shape)を有する。いくつかの実施例において、max_ctu3d_heightはCTUについて通常の(normal)高さを示し、そして、max_ctu3d_widthはCTU3Dについて通常の幅を示している。一つの実施例において、max_ctu3d_height/max_ctu3d_widthは、NNRヘッダといった、ビットストリームにおいてエンコードされ得る。従って、通常のCTU3Dの[RS][ctu3d_height][ctu3d_width]について、ctu3d_heightはmax_ctu3d_heightに等しく、そして、ctu3d_widthはmax_ctu3d_widthに等しい。テンソルの右側及び/又は下側に配置されたCTU3Dは、より小さいサイズを有し得ることに留意する。例えば、テンソルctu3d_heightの下側にあるCTU3Dの高さはC/max_ctu3d_heightの剰余であり、そして、テンソル ctu3d_widthの右側にあるCTU3Dの幅はK/max_ctu3d_widthの剰余である。
【0066】
図7は、本開示のいくつかの実施形態に従った、テンソル分割を説明している図を示す。テンソル(700)は、[C][K]面に沿って、CTU3Dへと分割される。通常のCTU3Dは[RS][H][W]の形状を有し、HはCTU3Dの高さ(ctu3d_height)を表し、そして、WはCTU3Dの幅(ctu3d_width)を表している。
【0067】
いくつかの実施形態において、3Dテンソル[RS][C][K]は、[C][K]平面において正方形の形状を有するCTU3Dへと分割され得る。そうした実施態様において、max_ctu3d_heightはmax_ctu3d_widthに等しい。いくつかの実施例においては、max_ctu3d_heightおよびmax_ctu3d_widthの両方を表すために、変数max_ctu3d_sizeが使用される。いくつかの実施例において、max_ctu3d_sizeは、2**N(2のN乗、2N)として定義され、そして、Nは8、16、32、64等であり得る。一つの実施例において、max_ctu3d_size情報は、NNRヘッダといった、ビットストリームで符号化され得る。
【0068】
いくつかの実施例においては、推論演算におけるオンチップメモリ要件を促進するために、フラグが、レイヤのCTU3Dサイズが異なるカーネルサイズを用いて制限される必要があるか否か示すために使用される。例えば、フラグがゼロの場合、カーネルのサイズに関係なく、ctu3d_height/ctu3d_widthが、変更されないで保持され得る。この場合、畳み込みレイヤのCTU3Dのサイズは、完全接続レイヤのCTU3DのサイズよりもRS(R×S)倍大きい。別の実施例において、フラグが1に等しい場合、カーネルサイズに基づいて、ctu3d_height/ctu3d_widthがスケール化され得る。例えば、CTU3Dの幅と高さの積は、R×Sでスケールダウンされる。
【0069】
テンソルにおけるCTU3Dは、任意の適切なCTU3Dスキャン順序によってスキャンされ得ることに留意する。いくつかの実施例において、テンソルにおけるCTU3Dは、水平方向のラスタスキャン順序(SCAN_CK)によってスキャンされ得る。いくつかの実施例において、テンソルにおけるCTU3Dは、垂直方向のラスタスキャン順序(SCAN_KC)によってスキャンされ得る。いくつかの実施形態において、CTU3Dスキャン順序情報は、レイヤヘッダ等といった、ヘッダ内に含まれ得る。
【0070】
図8A図8Cは、本開示のいくつかの実施形態に従った、シンタックスの実施例を示している。図8Aは、NNRについてシンタックステーブルの例を示している。図8Bは、NNRヘッダについてシンタックステーブルの例を示している。図8Cは、レイヤヘッダについてシンタックステーブルの例を示している。
【0071】
NNRヘッダにおいては、カーネルサイズに基づいてCTU3Dサイズを変更するか否かを示すためにenable_max_ctu3d_sizeが使用される。例えば、enable_max_ctu3d_sizeがゼロである場合、カーネルサイズにかかわらず、ctu3d_height、ctu3d_width、等といった、CTU3Dサイズパラメータは、変更されずに保持される。enable_max_ctu3d_sizeが1である場合、ctu3d_height、ctu3d_width、等といった、CTU3Dサイズパラメータは、図8Aにおいて(801)および(802)で示されるように、カーネルサイズに基づいてスケール化される。
【0072】
レイヤヘッダにおいては、CTU3Dスキャン順序を示すために、layer_scan_orderが使用される。一つの実施例において、layer_scan_orderがゼロに等しい場合、水平方向でラスタスキャン順序が使用され得る。そして、layer_scan_orderが1に等しい場合、垂直方向でラスタスキャン順序が使用され得る。
【0073】
本開示の一つの態様に従って、CTU3Dそれぞれは、例えば、[C][K]平面に沿って、CU3Dへと、さらに分割され得る。いくつかの実施形態においては、CTU3DをCU3Dへと分割するために、適応パーティションが使用され得る。
【0074】
いくつかの実施態様において、四分木分割(quad-tree splits)が再帰的に使用され得る。各四分木分割は、より大きなブロックを、より大きなブロックと同じ形状の4つのより小さな4つのブロックへと分割することができる。より大きなブロックは、分割ツリー構造の親ノードとして参照され得る。そして、4つのより小さなブロックは、親ノードに対して子ノードとして参照され得る。いくつかの実施例において、CTU3D/CU3Dは、最大再帰深度(recursive depth)が到達されるまで、四分木分割に基づいて再帰的に分割され得る。CTU3Dノードから開始して、CU3Dの四分木が、深度第1四分木スキャン順序を使用して、スキャンされ、そして、処理され得る。同じ親ノードの下の子ノードは、水平方向または垂直方向のいずれかで、ラスタスキャン順序を使用して、スキャンされ、そして、処理される。
【0075】
いくつかの実施形態においては、所与の四分木深度におけるCU3Dについて、CU3Dのmax_cu3d_height/max_cu3d_widthは、(式1)および(式2)を使用して計算され得る。そして、max_cu3d_heightおよびmax_cu3d_widthの両方が既定の閾値より小さいか等しい場合に、最大再帰深度が到達される。この既定の閾値は、明示的にビットストリーム内に含まれ得るか、または、暗黙的にデコーダによって推測され得る既定の数(例えば8)であり得るかのいずれかである。
max_cu3d_height=max_ctu3d_height>>depth (式1)
max_cu3d_width=max_ctu3d_width>>depth (式2)
【0076】
いくつかの実施例においては、max_ctu3d_height=max_ctu3d_widthであるように正方形の形状のパーティションが使用される。所与の四分木深度でのCU3Dについて、これらのCU3Dのmax_cu3d_sizeは、(式3)を使用して計算される。そして、max_cu3d_sizeが、既定の閾値より小さいか等しい場合、最大再帰深度が到達される。閾値は、明示的にビットストリーム内に含まれ得るか、または、暗黙的にデコーダによって推測され得る既定の数(例えば8)であり得るかのいずれかである。
max_cu3d_size=max_ctu3d_size>>depth (式3)
【0077】
図9Aは、本開示のいくつかの実施形態に従った、CTU3DパーティションおよびCU3Dスキャン順序の一つの例を示している。図9Aの実施例において、CTU3D(910)は、[C][K]面内に正方形の形状を有しており、そして、示されるように、[C][K]面において16個のCU3D、ブロック-1-ブロック-16、へと分割される。ブロック-8およびブロック-9は四分木深度1であり、ブロック-1、ブロック-6、ブロック-7、ブロック-10、ブロック-11、およびブロック-16は四分木深度2であり、ブロック-2からブロック-5及びブロック-12からブロック-15は四分木深度3である。垂直方向においてラスタースキャン(raster scan)を使用してCU3Dがスキャンされる場合、CU3Dは、ブロック-1、ブロック-2、ブロック-3、ブロック-4、ブロック-5、ブロック-6、ブロック-7、ブロック-8、ブロック-9、ブロック-10、ブロック-11、ブロック-12、ブロック-13、ブロック-14、ブロック-15、およびブロック-16の順序でスキャンされる。
【0078】
図9Bは、本開示のいくつかの実施形態に従った、CTU3DパーティションおよびCU3Dスキャン順序の一つの例を示している。図9Bの実施例において、CTU3D(920)は、テンソルの右側におけるエッジCTUであり得る。いくつかの実施例において、CTU3D(920)は、示されるように、14個のCU3D、ブロック-1-ブロック-14、へと分割される。ブロック-8およびブロック-9は四分木深度1であり、ブロック-1、ブロック-6、ブロック-7、ブロック-10、ブロック-11、およびブロック-14は四分木深度2であり、ブロック-2からブロック-5及びブロック-12からブロック-13は四分木深度3である。垂直方向においてラスタスキャンを使用してCU3Dがスキャンされる場合、CU3Dは、ブロック-1、ブロック-2、ブロック-3、ブロック-4、ブロック-5、ブロック-6、ブロック-7、ブロック-8、ブロック-9、ブロック-10、ブロック-11、ブロック-12、ブロック-13、およびブロック-14の順序でスキャンされる。
【0079】
図9Bで示されるように、テンソルの右側及び/又は下側に位置するCTU3Dについて、所与の深さにおける親(parent)CU3Dノードは、4つの子(child)ノードの全てを有さなくてよい。テンソルの右側及び/又は下側に位置するCTU3Dについて、cu3d_heightは、max_ctu3d_height/max_cu3d_heightの剰余であり、そして、cu3d_widthは、max_ctu3d_width/max_cu3d_widthの剰余であり得る。
【0080】
本開示の一つの態様に従って、親CU3Dが複数のより小さな子CU3Dへと分割される必要があるか否かを決定するために、レート歪み(rate-distortion、RD)ベースの符号化アルゴリズムが使用され得る。一つの実施例においては、小さな子CU3Dの結合RDが親CU3DのRDより小さい場合、親CU3Dは、複数の小さな子CU3Dへと分割される、さもなければ、親CU3Dは分割される必要がない。いくつかの実施形態においては、分割フラグが、エンコーダにおいて分割決定を記録するために使用され、そして、分割決定をデコーダに対して通知するためにビットストリーム内に含まれ得る。
【0081】
図10Aおよび図10Bは、本開示のいくつかの実施形態に従った、CTU3DをCU3Dへと分割するための例示的なシンタックステーブルを示している。CU3Dについて、四分木深度が閾値(ctu3d_depth)と比較されて、四分木深度が条件(例えば、depth<ctu3d_depth-1)を満たす場合、分割フラグ(split_flag)がビットストリームから取り出される(retrieved)。フラグは、CU3Dが4つの小さな子CU3Dへと分割される親CU3Dであるかを示すために使用される。例えば、split_flagが1である場合、CU3Dは4つのより小さいCU3Dへと分割される。
【0082】
本開示の態様は、ニューラルネットワークモデルの適切なエンコーディングおよびデコーディングを確実にするように、種々のレベルにおいてシンタックスを使用するための技法を提供する。いくつかの実施例において、ビットストリームの構造を記述し、または、複数のレイヤ、複数のブロック(例えば、複数のコーディングユニット、複数のCTU3D、複数のCU3D、等)に適用される情報を提供する、シンタックス要素は、高レベルシンタックスとして参照される。
【0083】
本開示の一つの態様に従って、NNRヘッダサイズパラメータnnr_header_sizeが定義され、そして、NNRヘッダ内に含められ得る。nnr_header_sizeは、符号化レイヤのランダムアクセスを保証するために使用され得る。nnr_header_sizeは、NNRヘッダの任意の場所に置かれ得るに留意する。いくつかの実施例において、nnr_header_sizeは、NNRヘッダ内の第1(first)シンタックス要素である。
【0084】
いくつかの実施形態において、NNRヘッダは、例えば、パラメータmax_ndim_bitdepthおよびmax_1dim_bitdepthを使用して、グローバルなビット深度情報を含み得る。パラメータmax_ndim_bitdepthは、1次元(1D)アレイではないレイヤ間の最大量子化ビット深度として定義され、そして、パラメータmax_1dim_bitdepthは、1Dアレイであるレイヤの最大量子化ビット深度として定義される。パラメータmax_ndim_bitdepthおよびmax_1dim_bitdepthは、デコードされた量子化レイヤについて適切なメモリ割当てを実行するようにデコーダをガイドするために使用される。
【0085】
図11は、本開示の一つの実施形態に従った、NNRヘッダについて一つの例示的なシンタックステーブルを示している。NNRヘッダは、シンタックス要素を含んでいる。
【0086】
具体的に、図11の実施例において、シンタックス要素nnr_header_sizeは、nnr_header_size自体を含むnnr_headerの総バイト数の情報を搬送するパラメータであり得る。シンタックス要素total_layerは、NNR内の全レイヤ数の情報を搬送するパラメータであり得る。シンタックス要素enable_zdep_reorderは、リオーダ(reorder)アルゴリズム(zdepリオーダアルゴリズム)がイネーブルされているか否か示すために使用されるフラグである。例えば、enable_zdep_reorderがゼロの場合、リオーダアルゴリズムは許可されない。そして、enable_zdep_reorderが1の場合は、リオーダアルゴリズムが許可される。シンタックス要素enable_max_ctu3d_sizeは、カーネルサイズに基づいて、CTU3Dのサイズが変更され得るか否かを示すために使用されるフラグである。例えば、enable_max_ctu3d_sizeがゼロの場合、ctu3d_height、ctu3d_width、等といった、CTU3Dのサイズパラメータは、カーネルのサイズに関係なく、変更されず保持される。そしてenable_max_ctu3d_sizeが1の場合、ctu3d_height、ctu3d_width、等といった、CTU3Dのサイズパラメータは、カーネルのサイズに基づいてスケール化され得る。シンタックス要素max_ctu3d_idxは、CTU3Dサイズの情報を搬送するパラメータであり得る。一つの実施例において、CTU3Dサイズパラメータmax_ctu_3d_sizeは、(式4)に基づいて決定され得る。
max_ctu_3d_size=
(max_ctu3d_idx==0)?64:(max_ctu3d_idx==1)?32:(max_ctu3d_idx==2)?16:8
(式4)
従って、max_ctu3d_idxがゼロの場合、max_ctu_3d_sizeは64に設定され、max_ctu3d_idxが1の場合、max_ctu_3d_sizeは32に設定され、max_ctu3d_idxが2の場合、max_ctu_3d_sizeは16に設定され、そして、max_ctu3d_idxが0、1、および2のいずれでもない場合、max_ctu_3d_sizeは8に設定され得る。
【0087】
さらに、シンタックス要素max_ndim_bitdepthは、1次元(1D)アレイではないレイヤ間の最大量子化ビット深度の情報を搬送するパラメータ(グローバルパラメータ)であり得る。シンタックス要素max_1dim_bitdepthは、1Dアレイであるレイヤの最大量子化ビット深度の情報を搬送するパラメータ(グローバルパラメータ)であり得る。
【0088】
本開示の一つの態様に従って、レイヤヘッダは、現在レイヤおよび現在レイヤサブレイヤの情報を含み得る。
【0089】
図12は、本開示の一つの実施形態に従った、レイヤヘッダについて一つの例示的なシンタックステーブルを示している。レイヤヘッダは、様々なシンタックス要素を含んでいる。
【0090】
具体的には、シンタックス要素layer_sizeは、layer_size自体を含む符号化レイヤの総バイト数の情報を搬送するために使用されるパラメータである。レイヤサイズパラメータlayer_sizeは、符号化レイヤのランダムアクセスを保証するために、定義され、そして、レイヤヘッダ内に含まれ得る。レイヤサイズパラメータは、レイヤヘッダ内の任意の場所(サブレイヤループの外側)に配置され得る。いくつかの実施例において、レイヤサイズパラメータlayer_sizeはレイヤヘッダ内の第1(first)シンタックス要素である。
【0091】
いくつかの実施形態において、レイヤは、バイアスサブレイヤ、バッチ正規化サブレイヤ、等といった、サブレイヤを含み得る。サブレイヤの情報は、レイヤヘッダ内に含まれ得る。シンタックス要素total_sublayerは、サブレイヤの数の情報を搬送するために使用されるパラメータである。シンタックス要素sublayer_sizeは、符号化サブレイヤの総バイト数の情報を搬送するために使用されるパラメータである。いくつかの実施例において、サブレイヤサイズパラメータsublayer_sizeは、符号化サブレイヤのランダムアクセスを保証するために、定義され、そして、レイヤヘッダ内に含まれ得る。
【0092】
シンタックス要素sublayer_ndimは、現在サブレイヤの次元の数の情報を搬送するために使用されるパラメータである。シンタックス要素sublayer_shape[]は、現在サブレイヤの形状の情報を搬送するために提起される(sued)パラメータである。一つの実施形態において、sublayer_ndimおよびsublayer_shape[ndim]、等といった、サブレイヤパラメータが、レイヤヘッダ内に含まれる。別の実施形態においては、sublayer_ndimおよびsublayer_shape[ndim]、等といった、サブレイヤパラメータは、レイヤヘッダ内に含まれない。そうした場合、デコーダは、パラメータの値を獲得するために外部モデル構造に依存することができる。
【0093】
シンタックス要素sublayer_scan_orderは、CTU3D/CU3Dスキャン順序を示すために使用されるフラグである。例えば、sublayer_scan_orderがゼロに等しい場合、水平方向のラスタスキャン順序が、CTU3Dスキャン順序及び/又はCU3Dスキャン順序について使用され得る。そして、sublayer_scan_orderが1に等しい場合、垂直方向のラスタスキャン順序が、CTU3Dスキャン順序及び/又はCU3Dスキャン順序について使用され得る
【0094】
シンタックス要素sublayer_sat_maxwは、レイヤ内の多次元テンソルの飽和最大値を搬送するパラメータである。飽和最大値は、整数またはフロート形式のいずれかであり得る。
【0095】
シンタックス要素sublayer_delta_bitdepthは、グローバルビット深度(例えば、NNRヘッダ内のmax_1dim_bitdepthまたはmax_ndim_bitdepth)に対するサブレイヤのビット深度の差異を搬送するために使用される。一つの実施例において、サブレイヤのビット深度は、(式5)を使用して計算され得る。
sublayer bitdepth=
((ndim==1)?max_1dim_bitdepth:max_ndim_bitdepth)-sublayer_delta_bitdepth
(式5)
【0096】
一つの実施形態において、1Dである全てのサブレイヤは、同一のビット深度を共有することができ(例えば、同じmax_1dim_bitdepthを有している)、従って、sublayer_delta_bitdepthは、レイヤヘッダにおいて必要とされない。別の実施形態において、1Dである各サブレイヤは、それ自身のビット深度を有し得る。従って、sublayer_delta_bitdepthが、レイヤヘッダ内に含まれ得る。
【0097】
本開示の一つの態様に従って、レイヤは、複数のサブレイヤを含み得る。一つの実施形態において、レイヤは、畳み込みサブレイヤおよびバイアスサブレイヤを含み得る。別の実施例において、レイヤは、完全接続サブレイヤおよびバイアスサブレイヤを含み得る。いくつかの実施形態において、レイヤがバイアスサブレイヤおよび別のサブレイヤを含む場合、バイアスサブレイヤは、他のサブレイヤの前にビットストリームにおいてコード化(符号化/復号)される。例えば、レイヤが畳み込みサブレイヤおよびバイアスサブレイヤを含む場合、バイアスサブレイヤは、畳み込みサブレイヤの前にエンコードされ、そして、デコードされる。別の実施例において、レイヤが完全接続サブレイヤおよびバイアスサブレイヤを含む場合、バイアスサブレイヤは、完全接続サブレイヤの前にビットストリームにおいてコード化(符号化および復号)される。
【0098】
図13は、本開示の一つの実施形態に従った、一つの例示的なシンタックスを示している。(1310)に示されるように、レイヤが、バイアスサブレイヤ、および、畳み込みサブレイヤ(例えば、タイプがconv)、完全接続サブレイヤ(例えば、タイプがfc)といった、別のサブレイヤとを含む場合、バイアスサブレイヤは、他のサブレイヤの前にビットストリーム内でコード化される。
【0099】
図14は、本開示の一つの実施形態に従った、プロセス(1400)を概説するフローチャートを示している。プロセス(1400)は、電子機器130といった、デバイスにおいて、ニューラルネットワークの表現に対応するビットストリームをデコード(解凍)するために使用され得る。プロセスは、(S1401)で開始して、(S1410)へ進む。
【0100】
(S1410)においては、ニューラルネットワークの表現に対応するビットストリームが、メモリ内に保管される。例えば、メインメモリ160は、ニューラルネットワークの表現である圧縮ニューラルネットワークモデルを保管する。いくつかの実施形態において、圧縮ニューラルネットワークモデルは、アプリケーションサーバ110から電子機器130へ送信される。電子機器130が圧縮ニューラルネットワークモデルを受信すると、電子機器130は、メインメモリ160内に圧縮ニューラルネットワークモデルを保管する。
【0101】
(S1420)においては、ニューラルネットワークにおける複数ブロックに適用されるシンタックス要素が、ビットストリームからデコードされる。
【0102】
(S1430)においては、複数ブロックの重み係数が、シンタックス要素に基づいてデコードされる。
【0103】
いくつかの実施例において、シンタックス要素はNNRヘッダ内に存在している。一つの実施例においては、NNRヘッダから、CTUサイズ(例えば、CTU3Dサイズ)を示すインデックス(例えば、max_ctu3d_idx)がデコードされる。次いで、重みテンソルが、インデックスによって示されるCTUサイズに基づいて、CTUへと分割され得る。次いで、CTUの重み係数が、ビットストリームから再構成され得る。
【0104】
一つの実施例においては、NNRヘッダから、カーネルサイズに基づいてCTUサイズを変更するか否か示すフラグ(例えば、enable_max_ctu3d_size)が、デコードされる。フラグによって示されるカーネルサイズに基づいてCTUサイズの変更をイネーブルすることに応じて、CTUサイズが、カーネルサイズに基づいて更新される。さらに、重みテンソルが、更新されたCTUサイズに基づいてCTUへと分割され得る。次いで、CTUの重み係数が、ビットストリームから再構成され得る。
【0105】
いくつかの実施形態においては、ビットストリームから、CTU内のパーティションを示す1つ以上の分割フラグがデコードされ得る。CTUは、次いで、1つ以上の分割フラグに基づいて、CU(例えば、CU3D)へと分割される。
【0106】
いくつかの実施形態においては、少なくともシンタックス要素(例えば、max_ndim_bitdepth、max_1dim_bitdepth、layer_bitdepth、等)に基づいて、レイヤ内の量子化重み係数に対するビット深度が決定され得る。次いで、量子化重み係数のためのメモリ空間が、ビット深度に基づいて割り当てられ得る。従って、レイヤ内の量子化重み係数は、割り当てられたメモリ空間を使用して、ビットストリームからデコードされ得る。いくつかの実施例においては、NNRヘッダから、グローバルビット深度(例えば、max_ndim_bitdepth、max_1dim_bitdepth、等)がデコードされ得る。次いで、レイヤに対するレイヤヘッダから、グローバルビット深度からのビット深度の差異(例えば、sublayer_delta_bitdepth)がデコードされ得る。レイヤにおける量子化重み係数のビット深度は、グローバルビット深度と、グローバルビット深度からのビット深度の差異との組み合わせに基づいて決定され得る。
【0107】
いくつかの実施例においては、レイヤヘッダから、レイヤ内の複数のブロックのスキャン順序を示すフラグ(例えば、sublayer_scan_order)がデコードされ得る。次いで、スキャン順序に従って、複数のブロックがビットストリームからデコードされ得る。加えて、いくつかの実施例においては、レイヤヘッダから、レイヤ内の次元の数(例えば、sublayer_ndim)、レイヤの形状(例えば、sublayer_shape[])、レイヤ内の飽和最大値(例えば、sublayer_sat_maxw)、および、レイヤ内の量子化ステップサイズ(例えば、レイヤ_stepsize)のうち少なくとも1つが、レイヤヘッダからデコードされ得る。
【0108】
いくつかの実施形態において、レイヤがバイアスサブレイヤおよび別のサブレイヤを含む場合、バイアスサブレイヤは、ビットストリーム内の別のサブレイヤの前にコード化される。
【0109】
いくつかの実施形態においては、ビットストリーム内のヘッダ部分の合計サイズを示すパラメータが、ビットストリーム内のヘッダ部分からデコードされ得る。パラメータは、パラメータに基づいて、ビットストリーム内のヘッダ部分の背後の部分にアクセスするために(ランダムアクセスとして参照される)使用され得る。
【0110】
上述の技法は、コンピュータで読取り可能な命令を使用してコンピュータソフトウェアとして実装され、そして、1つ以上のコンピュータで読取り可能な媒体に物理的に保管され得る。例えば、図15は、開示される技術的事項のうち所定の実施形態を実施するために適したコンピュータシステム(1500)を示している。
【0111】
コンピュータソフトウェアは、命令を含むコードを作成するために、アセンブリ、コンパイル、リンク、または同様のメカニズムの対象となり得る、任意の適切な機械コードまたはコンピュータ言語を使用して符号化され得る。命令は、1つ以上のコンピュータ中央処理装置(CPU)、グラフィックス処理装置(GPU)、等によって、直接的に、または、解釈(interpretation)、マイクロコード実行、等を通して実行され得る。
【0112】
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム装置、モノのインターネット、等を含む、種々のタイプのコンピュータ又はそのコンポーネント上で実行され得る。
【0113】
コンピュータシステム(1500)について図15において示されるコンポーネントは、本質的に例示的なものであり、そして、本開示の実施形態を実装するコンピュータソフトウェアの使用または機能性の範囲に関していなかる制限も示唆するようには意図されていない。また、コンポーネントの構成は、コンピュータシステム(1500)の例示的な実施形態において示されるコンポーネントのうち任意の1つ又は組み合わせに関するいかなる従属性または要件も有するものとして解釈されるべきではない。
【0114】
コンピュータシステム(1500)は、所定のヒューマンインターフェイス入力装置を含み得る。そうしたヒューマンインターフェイス入力装置は、例えば、触覚入力(例えば、キーストローク、スワイプ、データグローブの動き)、オーディオ入力(例えば、音声、拍手)、視覚入力(例えば、ジェスチャ)、嗅覚入力(図示なし)を通じて、一人以上の人間ユーザによる入力に対して応答し得る。ヒューマンインターフェイス装置は、また、オーディオ(例えば、音声、音楽、雰囲気の音)、画像(例えば、スキャン画像、静止画像カメラから獲得する写真画像)、ビデオ(例えば、2次元ビデオ、立体画像を含む3次元ビデオ)といった、人間による意識的な入力に必ずしも直接的に関係しない所定の媒体をキャプチャするためにも使用され得る。
【0115】
入力ヒューマンインターフェイス装置は、キーボード(1501)、マウス(1502)、トラックパッド(1503)、タッチスクリーン(1510)、データグローブ(1504)、ジョイスティック(1505)、マイクロホン(1506)、スキャナ(1507)、カメラ(1508)のうちの1つ以上(それぞれ1つだけが描かれている)を含み得る。
【0116】
コンピュータシステム(1500)は、また、所定のヒューマンインターフェイス出力装置を含み得る。そうしたヒューマンインターフェイス出力装置は、例えば、触覚出力、音、光、および、嗅覚/味覚を通して、一人以上の人間ユーザの感覚を刺激することができる。そうしたヒューマンインターフェイス出力装置は、触覚出力装置(例えば、タッチスクリーン(1510)、データグローブ(図示なし)、または、ジョイスティック(1505)による触覚フィードバック、しかし、入力装置として機能しない触覚フィードバック装置も、また、存在し得る)、オーディオ出力装置(例えば、スピーカー(1509)、ヘッドフォン(図示なし))、視覚出力装置(ブラウン管(CRT)スクリーン、液晶ディスプレイ(LCD)スクリーン、プラズマスクリーン、有機発光ダイオード(OLED)スクリーンを含むスクリーン(1510)であり、各々がタッチスクリーン入力機能を有するか又は有さない、各々が触覚フィードバック機能を有するか又は有さず、-これらのいくつかは、立体画像出力といった手段を介して、2次元の視覚出力または3次元以上の出力をアウトプットすることができ、仮想現実メガネ(図示なし)、ホログラフィックディスプレイおよびスモークタンク(図示なし)、といったもの)、および、プリンタ(図示なし)を含み得る。
【0117】
コンピュータシステム(1500)は、また、人間がアクセス可能なストレージ装置、および、それらの関連媒体を含み得る。CD/DVD等の媒体(1521)を用いるCD/DVD ROM/RW (1520)を含む光媒体、サムドライブ(thumb drive)(1522)、リムーバブルハードドライブまたはソリッドステートドライブ(1523)、テープおよびフロッピー(登録商標)ディスクといったレガシー磁気媒体、セキュリティドングル(図示なし)といった特殊化されたROM/ASIC/PLDベースの装置、等といったものである。
【0118】
当業者であれば、また、ここで開示されている技術的事項に関連して使用される用語「コンピュータで読取り可能な媒体(“computer readable media”)」は、伝送媒体、搬送波、または、他の一時的な信号を包含しないことも理解すべきである。
【0119】
コンピュータシステム(1500)は、また、1つ以上の通信ネットワークに対するインターフェイスを含み得る。ネットワークは、例えば、無線、有線、光であり得る。ネットワークは、さらに、ローカル、ワイドエリア、メトロポリタン、車両および工業、リアルタイム、遅延耐性(delay-tolerant)、等であり得る。ネットワークの例は、イーサネット、無線LAN、移動通信のためのグローバルシステム(GSM)、第3世代(3G)、第4世代(4G)、第5世代(5G)、ロングターム・エボリューション(LTE)、等を含むセルラーネットワーク、ケーブルテレビ、衛星テレビ、および、地上波放送テレビを含む、有線または無線のワイドエリアデジタルネットワーク、CANBusを含む車両および工業、等を含み得る。所定のネットワークは、一般的に、所定の汎用データポートまたはペリフェラルバス(1549)に取り付けられる外部ネットワーク・インターフェイスアダプタを必要とする。例えば、コンピュータシステム(1500)のユニバーサルシリアルバス(USB)ポート、といったものであり、他のものは、一般的に、以下に説明されるシステムバスに取り付けることによって、コンピュータシステム(1500)のコアに組み込まれる(例えば、PCコンピュータシステムへのイーサネット・インターフェイス、または、スマートフォン・コンピュータシステムへのセルラーネットワーク・インターフェイス)。一つの例として、ネットワークは、ネットワークインターフェイスを使用してペリフェラルバス(1549)に接続され得る。これらのネットワークのいずれかを使用して、コンピュータシステム(1500)は、他のエンティティと通信することができる。そうした通信は、一方向性(uni-directional)、受信専用(例えば、放送テレビ)、一方向性送信専用(例えば、所定のCANバス装置へのCANバス)、もしくは、例えば、ローカルまたはワイドエリアデジタルネットワークを使用する他のコンピュータシステムへの、双方向性(bi-directional)であり得る。所定のプロトコルおよびプロトコルスタックは、上述のように、それらのネットワークおよびネットワークインターフェイスの各々で使用され得る。
【0120】
上述のヒューマンインターフェイス装置、人間がアクセス可能なストレージ装置、および、ネットワークインターフェイスは、コンピュータシステム(1500)のコア(1540)に取り付けられ得る。
【0121】
コア(1540)は、1つ以上の中央処理装置(CPU)(1541)、グラフィックス処理装置(GPU)(1542)、フィールドプログラマブルゲートアレイ(FPGA)(1543)の形態で特殊化されたプログラマブル処理装置、所定のタスクのためのハードウェアアクセラレータ(1544)、等を含み得る。これらの装置は、リードオンリーメモリ(ROM)(1545)、ランダムアクセスメモリ(RAM)(1546)、内部非ユーザアクセス可能ハードドライブ、ソリッドステートドライブ(SSD)、等といった内部大容量ストレージ装置(1547)と共に、システムバス(1548)を通じて接続され得る。いくつかのコンピュータシステムにおいて、システムバス(1548)は、追加のCPU、GPU、等による拡張を可能にするために、1つ以上の物理的プラグの形態でアクセス可能であり得る。ペリフェラル装置は、コアのシステムバス(1548)に直接的に取り付けられても、または、ペリフェラルバス(1549)を通じて取り付けられてもよい。ペリフェラルバスのアーキテクチャは、ペリフェラルコンポーネントインターコネクト(PCI)、USB、等を含む。
【0122】
CPU(1541)、GPU(1542)、FPGA(1543)、およびアクセラレータ(1544)は、組み合わせて、上述のコンピュータコードを構成することができる所定の命令を実行することができる。そのコンピュータコードは、ROM(1545)またはRAM(1546)に保管することができる。過渡的データは、また、RAM(1546)に保管することができ、一方で、永久的データは、例えば、内部大容量ストレージ装置(1547)に保管することができる。メモリデバイスのいずれかへの高速保管および検索が、1つ以上のCPU(1541)、GPU(1542)、大容量ストレージ装置(1547)、ROM(1545)、RAM(1546)、等と密接に関連付けされ得る、キャッシュメモリの使用を通じて、可能にされ得る。
【0123】
コンピュータで読取り可能な媒体は、種々のコンピュータ実装オペレーションを実行するためのコンピュータコードをその上に有することができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築され得るか、または、それらは、コンピュータソフトウェア技術の当業者にとって周知かつ入手可能な種類のものであり得る。
【0124】
一つの例として、そして、限定するものではなく、アーキテクチャ(1500)を有するコンピュータシステム、および、具体的にはコア(1540)は、1つ以上の有形なコンピュータで読取り可能な媒体において具現化されたソフトウェアを実行するプロセッサ(CPU、GPU、FPGA、アクセラレータ、等を含む)の結果として機能性を提供することができる。そうしたコンピュータで読取り可能な媒体は、上述のようにユーザがアクセス可能な大容量ストレージ装置、並びに、コア内部大容量ストレージ装置(1547)またはROM(1545)といった、非一時的な性質のコア(1500)に係る所定のストレージ装置であり得る。本開示の様々な実施形態を実装するソフトウェアは、そうした装置において保管され、そして、コア(1540)によって実行され得る。コンピュータで読取り可能な媒体は、特定的なニーズに応じて、1つ以上のメモリデバイスまたはチップを含み得る。ソフトウェアは、コア(1540)、および、具体的には、その中のプロセッサ(CPU、GPU、FPG、等を含む)に、ここにおいて説明された特定のプロセスまたは特定のプロセスに係る特定の部分を実行させ得る。RAM(1546)に保管されたデータ構造を定義すること、および、ソフトウェアによって定義されたプロセスに従ってそうしたデータ構造を修正することを含むものである。追加して、または代替として、コンピュータシステムは、回路(例えば、アクセラレータ(1544))において配線された、または、他の方法で具現化されたロジックの結果として機能性を提供することができる。回路は、ここにおいて説明される特定のプロセスまたは特定のプロセスの特定的な部分を実行するために、ソフトウェアの代わりに、または、一緒に動作することができる。ソフトウェアへの参照は、ロジックを含み、そして、適切な場合には、その逆もまた同様である。コンピュータで読取り可能な媒体への参照は、実行のためのソフトウェアを保管する回路(集積回路(IC)といったもの)、実行のためのロジックを具体化する回路、または、適切な場合には、その両方を含むことができる。本開示は、ハードウェアおよびソフトウェアの任意の適切な組み合わせを包含するものである。
【0125】
添付A:全般的なシンタックスの実施例
nnr(){
……
nnr_header()
for(layer_idx=0;layer_idx<total_layer:++layer_layer){
layer_header()
if(enable_max_ctu3d_size)
max_ctu3d_height=max_ctu3d_width=(2**(bitdepth(int(max_ctu3d_size*max_ctu3d_size/R/S))-1)
sublayer_idx=0
do{
if(sublayer_ndim[sublayer_idx]==1){
array1d(sublayer_idx)
++sublayer_idx
}else{
if(sublayer_type[sublayer_idx]==”conv/fc”&&sublayer_type[sublayer_idx+1]==”bias”)
array1d(sublayer_idx+1)
if(layer_scan_order==SCAN_CK){
for(c=0;c<C;c+=max_ctu3d_height){
for(k=0;k<K;k+=max_ctu3d_width){
ctu3d_height=min(max_ctu3d_height,C-c);
ctu3d_width=min(max_ctu3d_width,K-k);
last_ctu3d_flag=(max_ctu3d_height>=C-c&&max_ctu3d_width>=K-k)?1:0
ctu3d(c,k,ctu3d_height,ctu3d_width)
end_of_layer(last_ctu3d_flag)
}
}
}else if(layer_scan_order==SCAN_KC){
for(k=0;k<K;k+=max_ctu3d_width){
for(c=0;c<C;c+=max_ctu3d_height){
ctu3d_height=min(max_ctu3d_height,C-c);
ctu3d_width=min(max_ctu3d_width,K-k);
last_ctu3d_flag=(max_ctu3d_height>=C-c&&max_ctu3d_width>=K-k)?1:0
ctu3d(c,k,ctu3d_height,ctu3d_width)
end_of_layer(last_ctu3d_flag)
}
}
}
sublayer_idx+=(sublayer_type[sublayer_idx]==”conv/fc”&&sublayer_type[sublayer_idx+1]==”bias”)?2:1
}while(sublayer_idx<total_sublayer)
}
}
……
}

nnr_header(){
nnr_header_sizeoptional
……
total_layer
enable_zdep_reorder
enable_max_ctu3d_size
max_ctu3d_idx
max_ndim_bitdepth
max_1dim_bitdepth
……
}

layer_header({
layer_size
……
total_sublayer
for(sublayer_idx=0;sublayer_idx<total_sublayer;++sublayer_idx){
sublayer_sizeoptional
sublayer_ndim optional
sublayer_shape[ndim] optional
sublayer_scan_order
sublayer_sat_maxw
if(sublayer_ndim!=1) optional
sublayer_delta_bitdepth
}
……
}

ctu3d(){
……
ctu3d_header()
cu3d(0,0,0)
……
}

ctu3d_header(){
……
ctu3d_map_mode_flag
if(!ctu3d_map_mode_flag)
map_mode
enable_start_depth
zdep_array()
……
}

zdep_array(){
……
reorder_flag=false
if(enable_zdep_reorder&&zdep_size>2)
reorder_flag
if(!reorder_flag){
for(n=0;n<zdep_size;++n)
zdep_array[n]=n;
return;
}
queue[0]=-1;
for(n=1;n<zdep_size-1;++n){
signalled_flag
queue[n]=(signalled_flag)?1:(queue[n-1]>0)?-2:-1;
}
queue[zdep_size-1]=(queue[zdep_size-2]>0)?-2:-1;
for(n=0;n<zdep_size;++n){
zdep_array[n]=-1;
if(queue[n]==1){
qval_minus_one
queue[n]=qval_minus_one+1;
}
}
qidx=0,zidx=-1;
do{
while(zdep_array[++zidx]!=-1);
if(queue[qidx]==-1){
zdep_array[zidx]=zidx;
}else{
first_zidx=zidx;
while(queue[qidx]!=-2){
zdep_array[zidx]=queue[qidx];
zidx=queue[qidx];
++qidx;
}
zdep_array[zidx]=first_zidx;
zidx=first_zidx;
}
++qidx;
}while(qidx<zdep_size);
……
}

cu3d(depth,y_idx,x_idx){
……
if(cu3d does not exist)
return
if(depth<ctu3d_depth-1){
split_flag
if(split_flag){
cu3d(depth+1,(y_idx<<1),(x_idx<<1))
cu3d(depth+1,(y_idx<<1)+1,(x_idx<<1))
cu3d(depth+1,(y_idx<<1),(x_idx<<1)+1)
cu3d(depth+1,(y_idx<<1)+1,(x_idx<<1)+1)
return
}
}
predicted_codebook()
signalled_codebook()
if(ctu3d_map_mode_flag)
map_mode
start_depth_delta=0
if(enable_start_depth)
start_depth_delta
start_depth=total_depth-1-start_depth_delta
if(map_mode==0){
uni_mode
if(uni_mode)
unitree3d(start_depth,0,0,0,0,false)
else
octree3d(start_depth,0,0,0,0,false)
}elseif(map_mode==1)
tagtree3d(start_depth,0,0,0,0,false)
escape()
……
}

predicted_codebook(){
……
abs_predicted_diff
if(abs_predicted_diff)
sign
predicted_size=(sign?-int(abs_predicted_diff):abs_predicted_diff)+prev_predicted_size
for(p=0,n=0;n<max_predictor_size;++n){
predicted_flag
if(predicted_flag){
predicted[p]=n
codebook[n]=predictor[predicted[p++]]
}
if(p==predicted_size)
break
}
……
}

signalled_codebook(){
……
signalled_size=0
if(predicted_size<max_codebook_size)
signalled_size
codebook_size=predicted_size+signalled_size
prev=(predicted_size)?abs(codebook[predicted_size-1]):0
for(n=predicted_size;n<codebook_size;n++){
delta=exist=0
if(n>=2)
for(m=0;m<n-1;m++)
if(abs_codebook[m]==abs_codebook[n-1])
exist=1
if(exist)
nzflag_delta=1
else
nzflag_delta
if(nzflag_delta){
sign_delta
abs_delta
delta=(sign_delta?-int(abs_delta):abs_delta)
}
abs_codebook[n]=delta+prev
prev=abs_codebook[n]
}
for(n=predicted_size;n<codebook_size;n++){
sign
codebook[n]=(sign?-int(abs_codebook[n]):abs_codebook[n])
}
……
}

unitree3d(start_depth,depth,z_idx,y_idx,x_idx,skip){
……
zs_idx=(depth==total_depth-1)?zdep_array[z_idx]:z_idx
if(depth<total_depth-1){
nzflag=utree[depth][zs_idx][y_idx][x_idx]=0
if(depth>=start_depth){
if(!skip){
nzflag
utree[depth][zs_idx][y_idx][x_idx]=nzflag
if(!nzflag){
map_nzflag
if(map_nzflag){
if(codebook_size){
cmap_val
map_val=cmap_val
}else{
qmap_val
map_val=qmap_val
}
}
}
}
}
next_z_idx=(z_idx<<1)
next_y_idx=(y_idx<<1)
next_x_idx=(x_idx<<1)
bskip=(depth>=start_depth)?!nzflag:false;
if(location[next_z_idx][next_y_idx][next_x_idx]exist in next depth)
unitree3d(start_depth,depth+1,next_z_idx,next_y_idx,next_x_idx,bskip)
if(location[next_z_idx][next_y_idx][next_x_idx+1]exist in next depth)
unitree3d(start_depth,depth+1,next_z_idx,next_y_idx,next_x_idx+1,bskip)
if(location[next_z_idx][next_y_idx+1][next_x_idx]exist in next depth)
unitree3d(start_depth,depth+1,next_z_idx,next_y_idx+1,next_x_idx,bskip)
if(location[next_z_idx][next_y_idx+1][next_x_idx+1]exist in next depth)
unitree3d(start_depth,depth+1,next_z_idx,next_y_idx+1,next_x_idx+1,bskip)
if(location [next_z_idx+1][next_y_idx][next_x_idx]exist in next depth)
unitree3d(start_depth,depth+1,next_z_idx+1,next_y_idx,next_x_idx,bskip)
if(location[next_z_idx+1][next_y_idx][next_x_idx+1]exist in next depth)
unitree3d(start_depth,depth+1,next_z_idx+1,next_y_idx,next_x_idx+1,bskip)
if(location[next_z_idx+1][next_y_idx+1][next_x_idx]exist in next depth)
unitree3d(start_depth,depth+1,next_z_idx+1,next_y_idx+1,next_x_idx,bskip)
if(location[next_z_idx+1][next_y_idx+1][next_x_idx+1]exist in next depth)
unitree3d(start_depth,depth+1,next_z_idx+1,next_y_idx+1,next_x_idx+1,bskip)
return
}
if(start_depth=total_depth-1||utree[depth-1][z_idx>>1][y_idx>>1][x_idx>>1]){
map_nzflag
if(map_nzflag){
if(codebook_size){
index
map[zs_idx][y_idx][x_idx]=index
}else{
sign
abs_q
map[zs_idx][y_idx][x_idx]=(sign?-int(abs_q):abs_q)
}
}
}else{
sign=0
if(!codebook_size&&map_val)
map_sign
map[zs_idx][y_idx][x_idx]=(sign?-int(map_val):map_val)
}
……
}

octree3d(start_depth,depth,z_idx,y_idx,x_idx,skip){
……
zs_idx=(depth==total_depth-1)?zdep_array[z_idx]:z_idx
proceed=nzflag=oct[depth][zs_idx][y_idx][x_idx]=1
if(depth>=start_depth){
if(!skip){
nzflag
oct[depth][zs_idx][y_idx][x_idx]=nzflag
}
proceed=nzflag
}
if(proceed){
if(depth<total_depth-1){
skip=false
next_z_idx=(z_idx<<1)
next_y_idx=(y_idx<<1)
next_x_idx=(x_idx<<1)
if(location[next_z_idx][next_y_idx][next_x_idx]exist in next depth){
octree3d(start_depth,depth+1,next_z_idx,next_y_idx,next_x_idx,skip)
}
if(location[next_z_idx][next_y_idx][next_x_idx+1]exist in next depth){
if(depth>=start_depth)
skip=this is the last child node and bit value of all other child nodes are zero
octree3d(start_depth,depth+1,next_z_idx,next_y_idx,next_x_idx+1,skip)
}
if(location[next_z_idx][next_y_idx+1][next_x_idx]exist in next depth){
if(depth>=start_depth)
skip=this is the last child node and bit value of all other child nodes are zero
octree3d(start_depth,depth+1,next_z_idx,next_y_idx+1,next_x_idx,skip)
}
if(location[next_z_idx][next_y_idx+1][next_x_idx+1]exist in next depth){
if(depth>=start_depth)
skip=this is the last child node and bit value of all other child nodes are zero
octree3d(start_depth,depth+1,next_z_idx,next_y_idx+1,next_x_idx+1,skip)
}
if(location[next_z_idx+1][next_y_idx][next_x_idx]exist in next depth){
if(depth>=start_depth)
skip=this is the last child node and bit value of all other child nodes are zero
octree3d(start_depth,depth+1,next_z_idx+1,next_y_idx,next_x_idx,skip)
}
if(location[next_z_idx+1][next_y_idx][next_x_idx+1]exist in next depth){
if(depth>=start_depth)
skip=this is the last child node and bit value of all other child nodes are zero
octree3d(start_depth,depth+1,next_z_idx+1,next_y_idx,next_x_idx+1,skip)
}
if(location[next_z_idx+1][next_y_idx+1][next_x_idx]exist in next depth){
if(depth>=start_depth)
skip=this is the last child node and bit value of all other child nodes are zero
octree3d(start_depth,depth+1,next_z_idx+1,next_y_idx+1,next_x_idx,skip)
}
if(location[next_z_idx+1][next_y_idx+1][next_x_idx+1]exist in next depth){
if(depth>=start_depth)
skip=this is the last child node and bit value of all other child nodes are zero
octree3d(start_depth,depth+1,next_z_idx+1,next_y_idx+1,next_x_idx+1,skip)
}
return
}
if(codebook_size){
index
map[zs_idx][y_idx][x_idx]=index
}else{
sign
abs_q
map[zs_idx][y_idx][x_idx]=(sign?-int(abs_q):abs_q)
}
}
……
}

tagtree3d(start_depth,depth,z_idx,y_idx,x_idx,skip){
……
zs_idx=(depth==total_depth-1)?zdep_array[z_idx]:z_idx
proceed=nzflag=1
if(depth)
tgt[depth][zs_idx][y_idx][x_idx]=tgt[depth-1][z_idx>>1][y_idx>>1][x_idx>>1]
if(depth>=start_depth){
if(!skip){
if(codebook_size){
if(depth==start_depth){
index=0
nzflag_index
if(nzflag_index)
index
tgt[depth][zs_idx][y_idx][x_idx]=index
}else{
delta_index
tgt[depth][zs_idx][y_idx][x_idx]=
tgt[depth-1][z_idx>>1][y_idx>>1][x_idx>>1]-delta_index
}
}else{
if(depth==start_depth){
abs_q=0
nzflag_q
if(nzflag_q)
abs_q
tgt[depth][zs_idx][y_idx][x_idx]=abs_q
}else{
delta_abs_q
tgt[depth][zs_idx][y_idx][x_idx]=
tgt[depth-1][z_idx>>1][y_idx>>1][x_idx>>1]-delta_abs_q
}
}
nzflag=(tgt[depth][zs_idx][y_idx][x_idx]!=0)
}
if(depth==total_depth-1&nzflag&&codebook_size==0){
sign_q
tgt[depth][zs_idx][y_idx][x_idx]=
(sign?-int(tgt[depth][zs_idx][y_idx][x_idx]):tgt[depth][zs_idx][y_idx][x_idx])
}
proceed=nzflag
}
if(proceed){
if(depth<total_depth-1){
skip=false
next_z_idx=(z_idx<<1)
next_y_idx=(y_idx<<1)
next_x_idx=(x_idx<<1)
if(location[next_z_idx][next_y_idx][next_x_idx]exist in next depth){
tagtree3d(start_depth,depth+1,next_z_idx,next_y_idx,next_x_idx,skip)
}
if(location[next_z_idx][next_y_idx][next_x_idx+1]exist in next depth){
if(depth>=start_depth)
skip=this is the last child node and value of all other child nodes are smaller than value of parent node
tagtree3d(start_depth,depth+1,next_z_idx,next_y_idx,next_x_idx+1,skip)
}
if(location[next_z_idx][next_y_idx+1][next_x_idx]exist in next depth){
if(depth>=start_depth)
skip=this is the last child node and value of all other child nodes are smaller than value of parent node
tagtree3d(start_depth,depth+1,next_z_idx,next_y_idx+1,next_x_idx,skip)
}
if(location[next_z_idx][next_y_idx+1][next_x_idx+1]exist in next depth){
if(depth>=start_depth)
skip=this is the last child node and value of all other child nodes are smaller than value of parent node
tagtree3d(start_depth,depth+1,next_z_idx,next_y_idx+1,next_x_idx+1,skip)
}
if(location[next_z_idx+1][next_y_idx][next_x_idx]exist in next depth)
if(depth>=start_depth)
skip=this is the last child node and value of all other child nodes are smaller than value of parent node
tagtree3d(start_depth,depth+1,next_z_idx+1,next_y_idx,next_x_idx,skip)
if(location[next_z_idx+1][next_y_idx][next_x_idx+1]exist in next depth){
if(depth>=start_depth)
skip=this is the last child node and value of all other child nodes are smaller than value of parent node
tagtree3d(start_depth,depth+1,next_z_idx+1,next_y_idx,next_x_idx+1,skip)
}
if(location[next_z_idx+1][next_y_idx+1][next_x_idx]exist in next depth){
if(depth>=start_depth)
skip=this is the last child node and value of all other child nodes are smaller than value of parent node
tagtree3d(start_depth,depth+1,next_z_idx+1,next_y_idx+1,next_x_idx,skip)
}
if(location[next_z_idx+1][next_y_idx+1][next_x_idx+1]exist in next depth){
if(depth>=start_depth)
skip=this is the last child node and value of all other child nodes are smaller than value of parent node
tagtree3d(start_depth,depth+1,next_z_idx+1,next_y_idx+1,next_x_idx+1,skip)
}
return
}
map[zs_idx][y_idx][x_idx]=tgt[depth][zs_idx][y_idx][x_idx]
}
……
}

escape(){
……
if(codebook_size)
for(z=0;z<cu_cdepth;++z)
for(y=0;y<cu_height;++y)
for(x=0;x<cu_width:++x)
if(map[z][y][x]==codebook_size){
q=0
nzflag
if(nzflag){
sign
abs_q
q=(sign?-int(abs_q):abs_q)
}
}
……
}
【0126】
本開示は、いくつかの例示的な実施形態を説明してきたが、変更、置換、および様々な代替等価物が存在し、それらは本開示の範囲内にある。このように、当業者であれば、ここにおいて明示的に示され、または、説明されていなくても、本開示の原理を具体化し、かつ、従って、本開示の精神および範囲内にある多のシステムおよび方法を考案することができることが、正しく理解されるだろう。
図1
図2
図3
図4
図5A
図5B
図6
図7
図8A
図8B
図8C
図9A
図9B
図10A
図10B
図11
図12
図13
図14
図15
【国際調査報告】