--- title: "Apple PICO codecとは？学習型画像コーデックの仕組み・性能・公開範囲" url: "https://www.issoh.co.jp/tech/details/12341/" published: 2026-06-02 updated: 2026-11-13 categories: ["AI"] publisher: "株式会社一創" --- # Apple PICO codecとは？学習型画像コーデックの仕組み・性能・公開範囲 PICO（Perceptual Image Codec）は、Appleの研究チームが2026年5月に論文で発表した学習型の画像コーデックです。人間の見た目の評価に合わせて最適化しつつ、iPhone上で実用的な速度で動くことを目標に設計されています。論文はarXivに2026年5月6日付で投稿され、CVPR 2026にも採択されました。開発の中心は、2017年から学習型の圧縮を研究してきたスタートアップWaveOneの出身者です。 この記事では、論文本文・GitHubリポジトリ・プロジェクトページの3つの一次情報をもとに、PICOの仕組み、性能の数字が成り立つ測定条件、そして現時点で何が公開されていて何が公開されていないかを整理します。 ## まとめ：PICOの要点と現時点で試せる範囲 - PICOはAppleの研究成果で、論文「What Matters in Practical Learned Image Compression」（arXiv:2605.05148）として公開されています。製品への搭載は論文・README・プロジェクトページのいずれにも書かれていません。 - 主観評価では、同じ見た目の画質を出すのに必要なビットレートがAV1・AV2・VVC・ECM・JPEG-AIより2.3〜3倍少なく、既存の知覚最適化系の学習型コーデックとの比較では、相手側のファイルが20〜40%大きくなるとされています（PICO側から見た削減率に直すと約17〜29%）。 - 速度は12MP画像でエンコード230ms・デコード150ms（iPhone上）です。ただし同じ比較図ではHEICが68ms・14msで、端末に組み込まれた従来形式より速いわけではありません。 - GitHubリポジトリにあるのは比較ビューアのWebページと再構成画像の配布リンクだけで、エンコーダー・デコーダーの実装や学習済みの重みは含まれていません。手元の画像をPICOで圧縮することはできません。 - 漫画やイラストのような単純な合成画像では、従来コーデックより多くのビットを使うと論文自身が書いています。JPEG XL・WebP・AVIFは比較に入っていません。 - 2026年11月13日時点でも、arXivの論文はv1のまま、リポジトリにコードは追加されていません。 以下、公開物の中身、設計の工夫、数字の読み方、弱点の順に見ていきます。 ## PICOの公開物：論文・プロジェクトページ・GitHubの中身 ### 論文の著者と発表時期 論文の著者はKedar Tatwawadi、Parisa Rahimzadeh、Zhanghao Sun、Zhiqi Chen、Ziyun Yang、Sanjay Nair、Divija Hasteer、Oren Rippelの8名で、所属はすべてAppleです。arXivのv1は2026年5月6日（UTC）に投稿されています。GitHubリポジトリの初回コミットは2026年5月4日、READMEへの論文IDの追記は5月7日です（日時はいずれもUTC）。 論文は2つの形で読めます。arXiv v1は付録まで含めた23ページの1ファイルで、[CVPR 2026のOpen Access版](https://openaccess.thecvf.com/content/CVPR2026/html/Tatwawadi%5FWhat%5FMatters%5Fin%5FPractical%5FLearned%5FImage%5FCompression%5FCVPR%5F2026%5Fpaper.html)は本文11ページと補足資料12ページに分かれています。要旨の数字（2.3〜3倍、230ms／150ms、610人・74,925件）はどちらも同じです。この記事で「付録」と書く部分（PSNRの比較、合成画像での弱点など）は、CVPR版では補足資料の側にあります。2026年11月13日にarXiv APIで確かめた時点で、論文はv1から改訂されていません。 ### 開発チームの系譜：WaveOneの学習型コーデック研究 著者リストの最後に名前のあるOren Rippelは、AppleがPICOを発表する前、2016年創業のスタートアップWaveOneで学習型の圧縮を研究していました。2017年にはLubomir Bourdevと連名で、WaveOne Inc.の所属として[「Real-Time Adaptive Image Compression」](https://arxiv.org/abs/1705.05823)をICML 2017で発表しました。この論文は、汎用画像のデータセットで、JPEG・JPEG 2000の約2.5分の1、WebPの約2分の1、BPGの約1.7分の1のファイルサイズになるのが典型だと報告しています。 2021年に同社が出した動画コーデックの論文[ELF-VC](https://arxiv.org/abs/2104.14335)は、著者6名全員がWaveOne Inc.の所属で、うちRippel・Tatwawadi・NairはPICO論文の著者でもあります。ELF-VCはUVGデータセットのPSNRでH.264よりBD-rateを44%下げ、処理速度を公表している学習型コーデックより少なくとも5倍速いとしていました。圧縮率と速度を同時に追う姿勢は、PICOの「知覚品質と端末上の実行時間を同時に最適化する」という設計にそのまま続いています。 WaveOneについては、2023年3月に[Appleへの売却が報じられました](https://siliconangle.com/2023/03/27/apple-acquires-ai-powered-video-compression-startup-waveone/)。元社員の[Bob Stankoshによる売却完了の投稿](https://www.linkedin.com/posts/bob-stankosh-2736794%5Fafter-almost-2-years-at-waveone-last-week-activity-7028343745553014785-hFq%5F)が根拠で、Apple自身は買収を公表していません。 一次情報は[arXivの論文ページ](https://arxiv.org/abs/2605.05148)、[公式プロジェクトページ](https://apple.github.io/ml-pico/)、[公式GitHubリポジトリ](https://github.com/apple-aiml-research/ml-pico)の3か所です。リポジトリは当初 apple/ml-pico として案内され、現在は apple-aiml-research/ml-pico に移っています（旧URLは転送されます）。 ### GitHubリポジトリに入っているもの・入っていないもの 「GitHubで公開」という見出しから、コーデックを手元で動かせると受け取られがちですが、リポジトリの中身は次のとおりです（2026年11月13日に再取得。10月9日の取得時と同じ構成で、最後の更新は9月11日のルートファイル整理です）。 ``` $ gh api repos/apple-aiml-research/ml-pico/contents --jq '.[].name' .nojekyll LICENSE LICENSE_DATA README.md assets crop-picker.html index.html ``` index.html と assets はプロジェクトページの比較ビューア（JavaScriptで書かれたスライダー）で、crop-picker.html はビューアに表示する切り出し位置を決めるための作業用ページです。READMEにある配布物は「CLIC 2020テストセットのうち個人を特定できない画像を、8段階のビットレートでPICOが再構成した画像」で、論文の主観評価に使ったものそのものです。配布ファイルの大きさを2026年11月13日にHEADリクエストで確かめると、10,131,194,079バイト（約10.1GB）でした。 ``` $ curl -sI https://ml-site.cdn-apple.com/datasets/lic/pico.zip | grep -i content-length content-length: 10131194079 ``` 一方、エンコーダー・デコーダーのソースコード、学習済みの重み、Core MLなどの推論用モデル、ビットストリームの仕様書はどこにもありません。論文の付録によれば、顔が写った写真はライセンス上の理由で配布データから外されています。 | 公開物 | 中身 | ライセンス | | ------------------- | ------------------ | ------------------------- | | 論文（arXiv・CVPR 2026） | 設計・評価・付録 | 論文として公開 | | 比較ビューア | 19シーンのスライダー比較 | Apple Sample Code License | | 再構成画像（pico.zip） | CLIC 2020の8ビットレート分 | CC BY-NC-ND 4.0 | | コーデック本体・重み | 非公開 | なし | ライセンスにも注意が要ります。再構成画像はCC BY-NC-ND 4.0で提供され、ライセンスに基づく共有にはクレジット表示などの条件があります。商用利用や改変物の共有は、このライセンスでは許諾されません。ビューアのコードに付くApple Sample Code Licenseは利用・改変・再配布を認めていますが、特許の権利は与えないと明記しています。CC BY-NC-ND 4.0による利用は非営利目的に限られ、社内利用だからといって営利目的の利用が許されるわけではありません。製品評価の素材として加工して配る用途は、法令上の引用などの例外や個別の許諾が成り立たない限りできません。 ## 従来コーデックとの違い：人の目に合わせて学習する設計 JPEG・HEIC・AV1・VVCといった従来のコーデックは、変換とエントロピー符号化を人が設計して組み合わせたものです。論文は、こうした設計は特定の指標に少し寄せることはできても、知覚品質そのものに向けて最適化するのは構造的に難しく、専用ハードウェアが必要になるため普及と更新に時間がかかる、と整理しています。 学習型コーデックは、エンコーダーとデコーダーをニューラルネットワークで作り、ビットレートと画質指標のバランスを学習で最適化します。基本形は、潜在表現の確率分布を別のネットワーク（ハイパープライア）で推定して符号化効率を上げる構成で、[VAE（変分オートエンコーダ）](/tech/details/5575/)の考え方を圧縮に持ち込んだものです。PICOもこの骨格を引き継いでいます。 PICOの特徴は、最適化の目標を画素の一致ではなく人間の評価に置いた点です。論文の付録Aでは、PSNRで上位のDCVC-RT・TCM・ECM・VVCは知覚指標では振るわず、人の評価で同じ画質を出すには2〜3倍のビットレートが必要だったと報告しています。逆にPICOを含む知覚最適化系のコーデックはPSNRでは良い成績を出しません。PSNRで比べる限り、PICOの優位は見えないということです。 ## PICOのアーキテクチャと学習の工夫 ### スケールデコーダーの分離とデバイス間で同じ結果を出す仕組み 学習型コーデックの弱点の1つが、端末によって復号に失敗することです。エントロピー符号化に渡すパラメータが1ビットでもずれると復号できないのに、浮動小数点演算の結果はハードウェアによって微妙に変わります。 PICOは、ハイパーデコーダーを「スケールデコーダー」と「コンテキストデコーダー」に分けました。エントロピー符号化に直接効くスケールσを出すスケールデコーダーは、UINT8に量子化して重みも活性もすべて整数にしたうえで、量子化の倍率計算に残る浮動小数点演算をIEEE規格に従うCPUで実行します。これで端末をまたいでも同じ値が出ることを保証しています。比較図の「Cross-device」欄で、HiFiCやMRICが×なのに対してPICOが○なのは、この設計によるものです。 ### 504×504のタイル分割とパイプライン実行 画像は重なりのない504×504画素のタイルに分けて処理します。エンコード時は隣のタイルから4画素分の余白を取り込んで512×512にし、境界の連続性を保ちます。タイルに分けることで、あるタイルのエントロピー符号化とスケール復号をCPUで行いながら、別のタイルのニューラルネットワーク部分をMLアクセラレーターで同時に動かせます。 ### ワンショット文脈モデル・量子化幅の学習・Haarリサンプリング 自己回帰（AR）で潜在表現を予測すると圧縮率は上がりますが、CPUとMLアクセラレーターの間でデータを何度も往復させるので遅くなります。論文は、往復が必要になるのはスケールσにARを使うからだと指摘し、σは一度で復号し、位置μと量子化幅qだけをアクセラレーター上で反復予測する「ワンショット文脈モデル」を提案しました。 各工夫の効き目は、外したときに必要なビットが何%増えるか（CMMD-CLIPのBD-rate）で示されています。 | 外した工夫 | BD-rateの悪化 | | ---------------------------- | ---------- | | ワンショット文脈モデル（2×2グリッド→なし） | +10.28% | | 量子化幅の学習 | +8.16% | | 学習スケール（ConvScaleと解像度ごとのスケール） | +9.58% | | Haarリサンプリング（→ピクセルシャッフル） | +19.51% | | 上記すべて | +31.69% | 文脈モデルの比較では、チャネル方向の分割（+3.10%）より2×2グリッドのような空間方向の分割の方が効いており、空間的な依存関係を捉える方が重要だと論文は述べています。ConvScaleとHaarリサンプリングは、推論時に通常の畳み込みへ畳み込み直せるので計算量は増えません。 ### 損失関数：文字の崩れとタイル境界の色ずれを抑える2つの項 PICOの損失はMSE・LPIPS・MS-SSIM・GANに、TextFidelityLossとTilingArtifactLossを加えた構成です。GANで写実性を上げると、細部をでっち上げたり小さな文字が読めなくなったりするので、2つの専用の項でそれを抑えています。 - TextFidelityLoss：既存の文字検出器で文字領域のマスクを作り、その領域だけ強いL1損失をかけてGAN系の損失を弱めます。約100枚の小さな文字を含むテスト画像で、文字領域の誤差は0.0093から0.0046に半減しました。 - TilingArtifactLoss：知覚損失やGANは低周波成分を軽視するため、隣り合うタイルで色がずれます。複数解像度のL1損失で低周波を監督し、タイル境界の低周波誤差を0.0020から0.00097に下げています。 学習は2段階で、最初はMSEだけで学習し、次の段階で上の損失をすべて加えて知覚品質へ寄せます。学習データは汎用画像約9万枚、文字画像2,300枚、公開データセット（DIV2K・CLIC・Flickr2K）約2.8万枚です。 ### 140万候補から絞り込んだアーキテクチャ探索 デコーダーの構成は、iPhone 16 Proで12MP画像のニューラルネットワーク処理を100msに収めることを目標に探索されました。候補は約140万通りあり、次の順に絞り込んでいます。 1. 演算量（kMACs/画素）が32.7〜48.0の範囲外を除外し、約50万に 2. 無作為に選んだ1万モデルをiPhone 16 Proで実測し、目標から5%以内の約1,000に 3. 第1段階の学習を30%だけ回し、PSNRのBD-rateで上位20に 4. 20モデルを最後まで学習し、知覚指標と目視で1つに決定 できあがったエンコーダー／デコーダーのパラメータ数は1,520万／960万、ディスク上で30.4MB／19.4MB、端末上のピークメモリは38.8MB／25.4MBです。ビットレートは1つのモデルで扱い、8段階の粗いレベルを補間して71段階の品質レベルを切り替えます。 ## 圧縮性能の数字と測定条件 ### 主観評価の集め方 「2.3〜3倍」という数字は、人による主観評価から出したものです。評価は外部の評価プラットフォームMabyduckで行い、参照画像を見ながら2つの再構成画像を盲検で比べる方式（CLIC圧縮チャレンジと同じ手順）を採っています。CLIC 2020テストセット（428枚）・Kodak・DIV2Kで、610人の評価者から74,925件の比較を集め、ベイズ型のEloスコアに換算しました。評価者は色覚・コントラスト感度・圧縮ノイズの検出力を事前に検査されています。 ### 知覚BD-rateと必要ビット量の倍率換算 READMEとプロジェクトページに掲載された比較図（論文のFigure 1）にある「PICOに対する知覚BD-rate」は、PICOと同じ見た目の画質を出すのに何%多くビットが必要かを表します。倍率に直すと次のとおりです。 | コーデック | 分類 | BD-rate | 必要なビット量 | | ------------- | ------ | ------- | ------- | | HEIC | 従来型 | +227% | 約3.3倍 | | AV2 | 従来型 | +173% | 約2.7倍 | | AV1 | 従来型 | +169% | 約2.7倍 | | VVC（VTM） | 従来型 | +151% | 約2.5倍 | | ECM | 従来型 | +148% | 約2.5倍 | | JPEG-AI（HOP） | 学習型 | +129% | 約2.3倍 | | DCVC-RT Intra | 学習型 | +172% | 約2.7倍 | | HiFiC | 学習型・知覚 | +40% | 約1.4倍 | | C3-WD | 学習型・知覚 | +40% | 約1.4倍 | | MRIC | 学習型・知覚 | +21% | 約1.2倍 | 要旨の「AV1・AV2・VVC・ECM・JPEG-AIに対して2.3〜3倍」は表の上半分に当たります。「最良の学習型に対して20〜40%の削減」は分母に注意が必要で、論文5.2節はHiFiC・C3-WD・MRICのファイルが同じ画質でPICOより20〜40%大きいと説明しています。PICOを分母にした増加率なので、相手側から見たPICOの削減率は約17〜29%です。JPEG-AIはISO/IEC 6048-1として規格化された学習型コーデックで、論文ではより高画質な設定であるHOP（High Operation Point）と比べています。論文はGANや拡散モデルを使うコーデックが、使わないもの（JPEG-AIやMLIC++）より知覚品質で大きく勝つ傾向も指摘しています。 報道で見かける「容量を最大3分の1に」は、この倍率を丸めた表現です。誰がどのデータで比べても3分の1になるという意味ではなく、主に自然写真のデータセットで、人の評価をそろえたときの平均的な差です。 ### 比較相手の実装と版：JPEG XL・WebP・AVIFは対象外 従来型コーデックの数字は、各規格の参照実装を論文の付録Eの設定で動かした結果です。参考文献に書かれた版は次のとおりで、エンコーダーの版や設定が変われば差も変わります。 | 比較相手 | 使われた実装 | 版・取得時点 | | ---- | ------------ | ------------------------- | | AV1 | AOM（libaom） | v3.12.1（2025年4月） | | AV2 | AVM（研究用アンカー） | research-v11.0.0（2025年9月） | | VVC | VTM | 23.11（2025年7月） | | ECM | ECM参照ソフトウェア | 2025年9月のmaster | | BPG | libbpg | 0.9.5（2015年1月） | 論文本文とCVPR版の補足資料を全文検索すると、JPEG XL・WebP・AVIFという語は1回も出てきません。Webでよく使う画像形式のうち、AVIFは中身の符号化にAV1を使うので、AV1の結果がある程度の目安になります。ただしAVIFのエンコーダー（libavifなど）の設定まで同じとは限りません。JPEG XLとWebPについては、PICOとの差を示すデータがありません。「JPEG XLより何倍小さいか」を論文から言うことはできないということです。 ## 処理速度：iPhoneで230ms/150msとHEICとの差 速度は12MP画像1枚の処理時間です。論文本文の測定機種はiPhone 17 Pro Maxで、比較図とREADMEでは「iPhone 17」と表記されています。PICOについてはニューラルネットワーク部分だけの時間と、エントロピー符号化などを含めた全体の時間の両方が示されています。 | コーデック | 実行環境 | エンコード | デコード | | ------------------- | --------- | ----- | ------- | | PICO（全体） | iPhone 17 | 230ms | 150ms | | PICO（NNのみ） | iPhone 17 | 160ms | 96ms | | PICO（NNのみ） | V100 | 140ms | 82ms | | HEIC | iPhone 17 | 68ms | 14ms | | AV1 | iPhone 17 | 710ms | 41ms | | JPEG-AI BOP（NNのみ） | iPhone 17 | 130ms | 72ms | | JPEG-AI HOP（NNのみ） | iPhone 17 | 850ms | 560ms | | HiFiC（NNのみ） | iPhone 17 | 680ms | 3,200ms | | DCVC-RT Intra（NNのみ） | iPhone 17 | 710ms | 980ms | iPhone上の数値は、各手法の公開実装と同じネットワーク構成をAppleがPICOと同じコンパイラ最適化で端末に載せて測ったものです。それ以外の環境の数値は元論文・リポジトリの公称値の引用です。AV1のエンコードには「ハードウェア支援があればもっと速くなる見込み」という注記が付いています。 この表から読み取るべきなのは、PICOは知覚最適化系の中では桁違いに速い（NN部分同士で比べるとデコードはHiFiCの3,200msに対して96msで、約33分の1）一方、端末に組み込まれたHEICと比べるとデコードは10倍以上遅いという点です。「V100で動く大半の学習型コーデックより速い」という要旨の表現は正確ですが、写真アプリの表示速度がHEICより速くなるという意味ではありません。なお論文は、アーキテクチャ探索の目標として、12MP画像のニューラルネットワーク部分のデコード100ms（iPhone 16 Pro）を実用上許容できる速さに置いています。 ## プロジェクトページの比較ビューアの見方 プロジェクトページでは、PICOを左に固定し、右側をHiFiC・DCVC-RT・VVC・BPGに切り替えてスライダーで比べられます。このビューアは「同じ画質ならファイルが小さい」ことを見せるものではなく、「ほぼ同じファイルサイズでどれだけ画質が違うか」を見せるものです。ビューアが読み込む assets/bpp\_data.json を集計すると、そのことが数字で確かめられます。次のコードはPython 3用で、JSONをbpp\_data.jsonという名前で保存したディレクトリで実行します（2026年10月9日取得のファイルで実行）。 ``` import json, statistics d = json.load(open("bpp_data.json")) print("scenes", len(d)) for k in ["hific", "dcvc", "vvc", "bpg"]: r = [float(v["pico"]) / float(v[k]) for v in d.values() if k in v] print(k, len(r), round(statistics.mean(r), 3), round(min(r), 3), round(max(r), 3)) # 実行結果 # scenes 19 # hific 19 0.986 0.968 1.0 # dcvc 19 0.966 0.908 0.995 # vvc 19 0.934 0.791 1.004 # bpg 9 0.92 0.846 0.99 ``` 19シーンでのPICOのビット数は、VVCに対して平均93.4%、HiFiCに対して平均98.6%です。PICOのbppはシーンごとに0.095〜0.507と変わり、1シーンだけはPICOの方がVVCよりわずかに大きくなっています。一部の紹介記事にある「bpp 0.341に固定して比較」は、そのうち1シーンの値で、全体が固定されているわけではありません。 論文が質的比較で強調しているのは細部の保持で、HiFiCについては細部のでっち上げ、平らな面への模様の付加、小さな文字が読めなくなる点を問題として挙げています。ビューアでもこの観点で見比べると差がつかみやすくなります。一方、ビューアを見て「VVCの2.5分の1のサイズでこの画質」と受け取るのは誤りです。サイズ差は主観評価の曲線から計算したもので、ビューアは同程度のサイズで並べています。 ## PICOの弱点と採用判断で外せない注意点 ### 漫画・イラストなど単純な合成画像で起きる逆転 論文の付録Iは、PICOが自然画像に向けて最適化されており、漫画のような極端に単純な合成画像では、従来コーデックより多くのビットを使わないと同じ画質にならないと認めています。理由は、そうした画像が従来コーデックの自己回帰的なモデル化にぴったり合うためだと説明されています。評価に使われた3つのデータセット（CLIC 2020・Kodak・DIV2K）はいずれも写真中心で、スクリーンショットやUI画像、図表での性能は示されていません。 ### Webサイトの画像配信にまだ使えない理由 PICOにはファイル形式としての仕様（拡張子・MIMEタイプ・コンテナ）も、配布されたデコーダーもありません。ブラウザもOSも読めない以上、Webサイトの画像を今PICOに置き換えることはできず、表示速度の改善策の候補にも入りません。ECサイトなどで画像の重さに悩んでいるなら、今取れる手は、AVIFやWebPへの変換と、表示サイズに合わせたリサイズの自動化です。変換を配信側で行うなら[Cloudinaryの画像変換URL](/tech/details/17683/)、ビルド時に最適化するなら[Astroのastro:assets](/tech/details/2762/)のような仕組みが現実的です。 学習型画像コーデックをいずれ自社サービスで扱う可能性があるなら、注目すべきはPICOそのものより、規格化済みのJPEG AIの実装が進むかどうかと、AppleがPICOの技術をOSの画像処理やカメラに取り込むと発表するかどうかの2点です。後者について、この記事で参照した論文・README・プロジェクトページには、製品搭載の具体的な予定は書かれていません。 ### ベンチマークの数字を自社判断に使う前の確認点 - 速度は最適化をそろえたAppleの実装での比較で、各手法の作者による最速実装と同じとは限りません。 - この表のBD-rateは人の評価に基づく値です。論文の付録Aでは、PSNRによる比較でPICOの優位は示されていません。社内でPSNRを画質基準にする場合は、対象画像で別途評価する必要があります。 - 主観評価はAppleが外部プラットフォームに委託したもので、この記事で参照した論文・README・プロジェクトページには、第三者による同条件での再評価結果は示されていません。重みが非公開のため、第三者はPICOで新しい画像を圧縮して検証することもできません。 ## よくある質問 ### PICOは何の略ですか？ Perceptual Image Codecの略で、人間の知覚に合わせて最適化した画像コーデックという意味です。Raspberry Pi Picoなどのマイコンボードとは無関係です。 ### PICOのコードやモデルをダウンロードして画像を圧縮できますか？ できません。GitHubリポジトリにあるのは比較ビューアのWebページと、論文の評価に使った再構成画像（約10.1GB）の配布リンクだけで、エンコーダー・デコーダーの実装や学習済みの重みは公開されていません。 ### PICOはiPhoneやmacOSに搭載されますか？ 論文・README・プロジェクトページのいずれにも、製品への搭載についての記述はありません。現時点では研究成果の発表という位置づけです。 ### PICOとJPEG AIの違いは何ですか？ JPEG AIはISO/IEC 6048-1として規格化された学習型コーデックで、PICOはAppleの研究段階のコーデックです。論文の主観評価では、JPEG AIの高画質設定（HOP）はPICOと同じ画質を出すのに約2.3倍のビットを必要としました。一方、JPEG AIはISO規格として仕様が発行され参照ソフトウェアも公開されているのに対し、PICOは仕様も実装も公開されていません。 ### PICOを開発したのは誰ですか？ Appleの研究者8名です。著者リストの最後のOren Rippelをはじめ、Kedar Tatwawadi・Sanjay Nairは、2023年3月にAppleへの売却が報じられたWaveOneで学習型の動画コーデックELF-VCを発表した顔ぶれです。Appleは買収を公表していません。 ## 関連記事 - [VAE（変分オートエンコーダ）とは｜仕組み・損失関数・GANや拡散モデルとの違いを実装まで解説](/tech/details/5575/) - [Neural Engine（ANE）とは？16コアの意味・M5世代の性能・Core MLでの使い方](/tech/details/11414/) - [Core MLとは？Create ML・coremltools 9でのモデル作成とSwift推論、Core AIとの使い分け](/tech/details/7513/) - [NPUとは？CPU・GPUとの役割分担とTOPSの実効性能・採用判断【2026年版】](/tech/details/16171/) - [Cloudinaryとは：画像変換URLの書き方とクレジット料金の実額を解説](/tech/details/17683/) --- 出典: [Apple PICO codecとは？学習型画像コーデックの仕組み・性能・公開範囲]()（株式会社一創）