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
Yuto
May 16, 2026
Technology
18
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
2
「ラストエリクサー症候群」からの脱却~ 持ってるアイテム温存するだけで眠らせてませんか? ~
tsukamoto1783
0
26
humanlayerのブログから学ぶ、良いCLAUDE.mdの書き方
tsukamoto1783
0
290
【超入門】AR 技術の"さわり"だけ学んでみる
tsukamoto1783
0
30
MCPサーバーって結局何ができるの?
tsukamoto1783
0
33
LT会:普段お世話になってるStackTraceと少しだけ向き合ってみる
tsukamoto1783
0
80
初使用の技術スタックで、 ミニマルなアプリケーションを 2日で作る
tsukamoto1783
0
90
アクセシビリティ対応について考えよう
tsukamoto1783
0
31
Flutterのすヽめ
tsukamoto1783
0
31
Other Decks in Technology
See All in Technology
LLM Internals: 언어 모델의 계보와 알고리즘 진화 (2023~2026)
inureyes
PRO
0
550
QAエンジニア起点で進める、SmartHRにおける信頼性向上について
kaomi_wombat
1
150
Contract One Engineering Unit 紹介資料
sansan33
PRO
0
19k
Model Studio CLI × Token Plan
maigo999
0
190
Invisible to AI? Making TYPO3 Sites Quotable by AI Search Systems
wolfgangwagner
0
220
Bits Agent Builder の⼊⾨と活⽤事例
nulabinc
PRO
0
180
20分でわかるセキュアAPI
nwiizo
2
300
エンドユーザー視点で見る SansanのMeraki活用と内製自動化
sansantech
PRO
0
100
関東Kaggler会発表資料
takoi
1
250
Bits AI を制するものは Datadog を制す / The player that controls Bits AI, controls Datadog
kaminashi
0
120
老害フォレンジッカーはAI羊の夢を見るか?
tadmaddad
0
340
カートの信頼性を担保するWireMockを使ったe2eテスト
ykagano
0
390
Featured
See All Featured
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
940
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.9k
The AI Search Optimization Roadmap by Aleyda Solis
aleyda
1
6.1k
Designing for Timeless Needs
cassininazir
1
440
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Java REST API Framework Comparison - PWX 2021
mraible
34
9.7k
Building a Scalable Design System with Sketch
lauravandoore
463
34k
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
230
The Anti-SEO Checklist Checklist. Pubcon Cyber Week
ryanjones
0
210
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
Test your architecture with Archunit
thirion
1
2.3k
Un-Boring Meetings
codingconduct
0
390
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(非可逆圧縮):人間の目に分からない細かいデータを間引くイメージ 容量は減るが、画質は劣化*する (≒*人の目には”元のピクセル維持”に見える、元に戻らない)
まとめ 改めて、何が原因だったでしょうか?
まとめ “アプリ側リサイズ時” と ”モデル学習時” に使用している ”補間アルゴリズム” の違 いが原因(学習時よりも画質の荒い画像データで推論実行していたため)
まとめ • よくあるライブラリのリサイズ関数には ”補間処理” が入ることを認知する • リサイズの補間アルゴリズムの違いをざっくり把握する →「知らない・存在自体認知していない」と、調べることもできない、調査対象にも ならない 「画像がボケる」「推論結果が一致しない」...
そんな時は裏側で動いている補間種類について新ためて確認し、最適な補間種類 を選択しましょう。 プロとして補間種類の特徴を理解し、要件に合わせて適切に使い分けれれるようになりたいよね。っというお話(自戒)でした。
画像リサイズ関数の裏側では何が起きている? ~ 補間アルゴリズムの違いを把握して適切な選択を ~ ご清聴ありがとうございました