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
作って終わりじゃないサーバーレス 〜9年運用する大規模EC物流API基盤の設計・運用のリアル〜
zozotech
PRO
0
170
C#コードの結合を可視化する Roslyn解析による設計改善と リファクタリング判断
dora56
0
120
Railsのように考える: See through the Master
snoozer05
PRO
4
1.1k
Vibe Coding で作ったプロダクトをどう安全に動かすか / How to Safely Run Products Built with Vibe Coding
glidenote
0
160
SREは、MCPとAutopilotをこう使え!
kazumax55
3
890
ソフトウェアDNAとクラウドエージェントのススメ
cloudace
0
110
2026-09-18 gotanda.sre Terraformで複数環境作ったり、複数Stateに分割したりそれとTerragrunt / Terraform multi envs and multi states
masasuzu
2
530
アプリをもっと"iOSアプリっぽく"する小さな工夫 / Small Touches That Make Your App Feel More Like an iOS App
matsuji
2
950
Azure Serverless 2026:Production-ready な AI エージェント基盤 / Azure Serverless 2026: Production-Ready AI Agent Platform
miyake
2
230
開発投資の期待値を上げるプロダクトロードマップづくり ~プロダクトエンジニアが越境して事業を伸ばす~
kekekenta
1
210
山手線を徒歩で一周してわかった、 位置情報アプリは「足」が最強のデバッガー
hinakko
0
160
ADKで始める業務改善 - AIエージェント開発時の考えと設計
harappa80
2
200
Featured
See All Featured
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
2
550
We Have a Design System, Now What?
morganepeng
55
8.3k
Code Reviewing Like a Champion
maltzj
528
40k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.9k
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
3
3.8k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Game over? The fight for quality and originality in the time of robots
wayneb77
1
280
Unlocking the hidden potential of vector embeddings in international SEO
frankvandijk
0
940
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
3k
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
1
320
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.3k
Skip the Path - Find Your Career Trail
mkilby
1
230
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(非可逆圧縮):人間の目に分からない細かいデータを間引くイメージ 容量は減るが、画質は劣化*する (≒*人の目には”元のピクセル維持”に見える、元に戻らない)
まとめ 改めて、何が原因だったでしょうか?
まとめ “アプリ側リサイズ時” と ”モデル学習時” に使用している ”補間アルゴリズム” の違 いが原因(学習時よりも画質の荒い画像データで推論実行していたため)
まとめ • よくあるライブラリのリサイズ関数には ”補間処理” が入ることを認知する • リサイズの補間アルゴリズムの違いをざっくり把握する →「知らない・存在自体認知していない」と、調べることもできない、調査対象にも ならない 「画像がボケる」「推論結果が一致しない」...
そんな時は裏側で動いている補間種類について新ためて確認し、最適な補間種類 を選択しましょう。 プロとして補間種類の特徴を理解し、要件に合わせて適切に使い分けれれるようになりたいよね。っというお話(自戒)でした。
画像リサイズ関数の裏側では何が起きている? ~ 補間アルゴリズムの違いを把握して適切な選択を ~ ご清聴ありがとうございました