Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
画像のリサイズ関数の裏側では何が起きている?
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Yuto
May 16, 2026
Technology
2
0
Share
画像のリサイズ関数の裏側では何が起きている?
Yuto
May 16, 2026
More Decks by Yuto
See All by Yuto
「ラストエリクサー症候群」からの脱却~ 持ってるアイテム温存するだけで眠らせてませんか? ~
tsukamoto1783
0
16
humanlayerのブログから学ぶ、良いCLAUDE.mdの書き方
tsukamoto1783
0
270
【超入門】AR 技術の"さわり"だけ学んでみる
tsukamoto1783
0
22
MCPサーバーって結局何ができるの?
tsukamoto1783
0
26
LT会:普段お世話になってるStackTraceと少しだけ向き合ってみる
tsukamoto1783
0
66
初使用の技術スタックで、 ミニマルなアプリケーションを 2日で作る
tsukamoto1783
0
82
アクセシビリティ対応について考えよう
tsukamoto1783
0
24
Flutterのすヽめ
tsukamoto1783
0
21
Other Decks in Technology
See All in Technology
可視化から活用へ — Mesh化・Segmentation・アライメントの研究動向
gpuunite_official
0
230
分断された OT と IT を繋ぐ架け橋 -Kubernetes が切り拓く 産業用組み込み製品の現在地 -
yudaiono
1
130
業務に残された「良くない型」で考える「TypeScriptの難しさ」
sajikix
2
580
"うちにはまだ早い"は本当? ─ 小さく始めるPlatform Engineering入門
harukasakihara
7
640
Oracle AI Database@Azure:サービス概要のご紹介
oracle4engineer
PRO
6
1.7k
既存プロダクトQAから新規プロダクトQAへ
ryotakahashi
0
160
TypeScriptで実現する既存APIを活用したリモートMCPサーバー構築 / TSKaigi 2026
soarteclab
0
120
その英語学習、AWSで代替できませんか?
suzutatsu
1
130
Cortex(Code) を ML モデルの 精度改善サイクルに組み込む.pdf
oimo23
0
230
AI Agent に“攻略本”を渡したら、150フォームの移行が回り始めた話/登壇資料(高橋 悟生)
hacobu
PRO
0
140
LookerとADKで作る社内AIエージェント
chanyou0311
0
270
GitHub Copilot CLI で考える複数エージェント設計
tomokusaba
0
120
Featured
See All Featured
Leveraging LLMs for student feedback in introductory data science courses - posit::conf(2025)
minecr
1
250
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
200
RailsConf 2023
tenderlove
30
1.4k
How to audit for AI Accessibility on your Front & Back End
davetheseo
0
370
The AI Search Optimization Roadmap by Aleyda Solis
aleyda
1
5.8k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.8k
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
2
1.5k
Being A Developer After 40
akosma
91
590k
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
118
110k
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
61
44k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.6k
A Modern Web Designer's Workflow
chriscoyier
698
190k
Transcript
画像リサイズ関数の裏側では何が起きている? ~ 補間アルゴリズムの違いを把握して適切な選択を ~
勉強会の実施意義 • 得た情報に対する「まとめる・伝える・話す」練習 • 知識の定着化 • 知識共有 • 失敗共有
はじめに 過去、以下の事例が発生。原因が分かりますか?
はじめに “アプリ側リサイズ時” と ”モデル学習時” に使用している ”補間アルゴリズム” の違い が原因 内部的に ”補間処理”
が走るが、引数がオプション指定であるため気づけなかった • “補間” について知らないと、オプション指定なので気づけない
本日のゴール • よくあるライブラリのリサイズ関数には ”補間処理” が入ることを認知する • リサイズ時の ”補間アルゴリズム” の違いをざっくり把握する ライブラリのリサイズ処理は、指定せずとも内部的に補間処理が走っています。
「ライブラリ関数が内部的にいい感じに対応してくれる」ことはありがたいが、 「知っててよしなに任せる」のと「知らずによしなにやってるくれてる」とでは 大きく異なります。
目次 • リサイズ処理とは? • 代表的な補完アルゴリズム • デフォルト設定の罠 • 備考:混同注意事項
リサイズ処理とは? • 画像データは、格子状に並んだピクセルの集合体です
リサイズ処理とは? • 画像データは、格子状に並んだピクセルの集合体です • ピクセルの数を「物理的に増やしたり減らしたりする」処理がリサイズ処理です 【増やす】 【減らす】
リサイズ処理とは? • 画像データは、格子状に並んだピクセルの集合体です • ピクセルの数を「物理的に増やしたり減らしたりする」処理がリサイズ処理です • リサイズ時に新たに発生する「元データに存在しないピクセル」を何色にするかを計算して色 を決定するプロセスが ”補間” です
• → 補間までがセットで「リサイズ関数(処理)」として扱われます
リサイズ処理とは? • おさらい
代表的な補完アルゴリズム 1. 最近傍補間(Nearest neighbor: ニアレストネイバー) 2. 双一次補間(Bilinear: バイリニア) 3. 双三次補間(Bicubic:
バイキュビック) ※ 他にも沢山ありますが割愛
代表的な補完アルゴリズム 最近傍補間(Nearest neighbor: ニアレストネイバー) • 「一番近いピクセルの色をそのままコピーする」 • メリット:計算が速い。また、元の色をそのまま使うため、新しい色(中間色) が勝手に生成されない •
デメリット:斜めの線や境界線が「ガタガタ(階段状)」になりやすい • ex. ドット絵、機械学習用ラベル
代表的な補完アルゴリズム 双一次補間(Bilinear: バイリニア) • 「周りの4ピクセルから距離に応じて少しずつ色を混ぜる」 • メリット:ニアレストネイバーより滑らかな見た目になる。計算も比較的速い • デメリット:境界線が少し「ボヤッ」とした印象になる(色を混ぜているため) •
ex. 画面プレビュー、UI
代表的な補完アルゴリズム 双三次補間(Bicubic: バイキュビック) • 「周りの16ピクセルを広範囲に分析して、色の変化の流れを予測する」 • メリット:バイリニアよりも境界線がシャープで、写真の細部などが綺麗に残る • デメリット:計算量が多く、処理に時間がかかる •
ex. 写真
代表的な補完アルゴリズム
デフォルト設定の罠 言語やライブラリによって、デフォルト設定されている補完アルゴリズムは様々であること に注意が必要です。 基本的にはデフォルトでどれかで実行されるため、この辺の認識が無いと、意図しない 品質劣化やパフォーマンスの低下を招いてしまいます。 • Python: OpenCV / resize
関数 • デフォルト値:INTER_LINEAR(バイリニア) • Node: sharp / resize 関数 • デフォルト値:lanczos3(ランチョス)※ ≒Bicubicの強化版 • Flutter: image / copyResize 関数 • デフォルト値:nearest(ニアレストネイバー)
混同注意①:”リサイズ” と “画面上での拡大” • リサイズ:データの再構築。ピクセル数そのものが変化する • 拡大:単なる”引き伸ばし”。ピクセルは不変であり画面上で大きく表示されるだけ
混同注意②:”リサイズ” と “圧縮” • リサイズ:データの再構築。ピクセル数そのものが変化する • 圧縮:元のピクセルを維持したまま、容量だけ減らす • PNG(可逆圧縮):容量だけ小さくし、データの中身は変えない(劣化しない、復元可能) •
JPEG(非可逆圧縮):人間の目に分からない細かいデータを間引くイメージ 容量は減るが、画質は劣化*する (≒*人の目には”元のピクセル維持”に見える、元に戻らない)
まとめ 改めて、何が原因だったでしょうか?
まとめ “アプリ側リサイズ時” と ”モデル学習時” に使用している ”補間アルゴリズム” の違 いが原因(学習時よりも画質の荒い画像データで推論実行していたため)
まとめ • よくあるライブラリのリサイズ関数には ”補間処理” が入ることを認知する • リサイズの補間アルゴリズムの違いをざっくり把握する →「知らない・存在自体認知していない」と、調べることもできない、調査対象にも ならない 「画像がボケる」「推論結果が一致しない」...
そんな時は裏側で動いている補間種類について新ためて確認し、最適な補間種類 を選択しましょう。 プロとして補間種類の特徴を理解し、要件に合わせて適切に使い分けれれるようになりたいよね。っというお話(自戒)でした。
画像リサイズ関数の裏側では何が起きている? ~ 補間アルゴリズムの違いを把握して適切な選択を ~ ご清聴ありがとうございました