Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
画像のリサイズ関数の裏側では何が起きている?
Search
Yuto
May 16, 2026
Technology
19
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
画像のリサイズ関数の裏側では何が起きている?
Yuto
May 16, 2026
More Decks by Yuto
See All by Yuto
自分の言葉で伝える
tsukamoto1783
0
4
「ラストエリクサー症候群」からの脱却~ 持ってるアイテム温存するだけで眠らせてませんか? ~
tsukamoto1783
0
29
humanlayerのブログから学ぶ、良いCLAUDE.mdの書き方
tsukamoto1783
0
310
【超入門】AR 技術の"さわり"だけ学んでみる
tsukamoto1783
0
32
MCPサーバーって結局何ができるの?
tsukamoto1783
0
37
LT会:普段お世話になってるStackTraceと少しだけ向き合ってみる
tsukamoto1783
0
82
初使用の技術スタックで、 ミニマルなアプリケーションを 2日で作る
tsukamoto1783
0
90
アクセシビリティ対応について考えよう
tsukamoto1783
0
34
Flutterのすヽめ
tsukamoto1783
0
31
Other Decks in Technology
See All in Technology
AI de Idea
kawaguti
PRO
2
120
AIによるクリエイティブ生成を行う上での試行錯誤
plaidtech
PRO
0
160
なぜ「決定性」が 決定的に重要なのか? Durable Execution 基盤の数理的理解 #serverlessjp / ServerlessDays Tokyo 2026
ytaka23
3
650
Railsのように考える: See through the Master
snoozer05
PRO
4
1.1k
今話題のAI「Jev」って何? 宇宙最速で学ぶ会
minorun365
PRO
28
16k
「ピッケル本」日本語版は4.0(第6版)が出版されるべき / pickaxe4-nagoyark05
kakutani
2
180
LLMに渡さなかった仕事
nanaism
0
820
AIは推し活である。
kurazuuuuuu
1
440
AIを活用するために決めた "やらないこと" - 価値に注目する / Not betting on AI
soudai
PRO
2
550
作って終わりじゃないサーバーレス 〜9年運用する大規模EC物流API基盤の設計・運用のリアル〜
zozotech
PRO
0
170
現場で役立つ技術負債の効果的な返済方法
masuda220
PRO
9
4.5k
登壇の自信を奪う3匹のオバケ / 3 Ghosts That Rob You of Your Confidence in Public Speaking
pauli
9
1k
Featured
See All Featured
Optimizing for Happiness
mojombo
378
71k
Amusing Abliteration
ianozsvald
1
310
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
56
3.5k
RailsConf 2023
tenderlove
30
1.5k
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
1.1k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
2.2k
The #1 spot is gone: here's how to win anyway
tamaranovitovic
4
1.2k
Design in an AI World
tapps
1
320
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
68
57k
Ecommerce SEO: The Keys for Success Now & Beyond - #SERPConf2024
aleyda
1
2.2k
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
290
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(非可逆圧縮):人間の目に分からない細かいデータを間引くイメージ 容量は減るが、画質は劣化*する (≒*人の目には”元のピクセル維持”に見える、元に戻らない)
まとめ 改めて、何が原因だったでしょうか?
まとめ “アプリ側リサイズ時” と ”モデル学習時” に使用している ”補間アルゴリズム” の違 いが原因(学習時よりも画質の荒い画像データで推論実行していたため)
まとめ • よくあるライブラリのリサイズ関数には ”補間処理” が入ることを認知する • リサイズの補間アルゴリズムの違いをざっくり把握する →「知らない・存在自体認知していない」と、調べることもできない、調査対象にも ならない 「画像がボケる」「推論結果が一致しない」...
そんな時は裏側で動いている補間種類について新ためて確認し、最適な補間種類 を選択しましょう。 プロとして補間種類の特徴を理解し、要件に合わせて適切に使い分けれれるようになりたいよね。っというお話(自戒)でした。
画像リサイズ関数の裏側では何が起きている? ~ 補間アルゴリズムの違いを把握して適切な選択を ~ ご清聴ありがとうございました