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
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Yuto
May 16, 2026
Technology
15
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
24
humanlayerのブログから学ぶ、良いCLAUDE.mdの書き方
tsukamoto1783
0
290
【超入門】AR 技術の"さわり"だけ学んでみる
tsukamoto1783
0
29
MCPサーバーって結局何ができるの?
tsukamoto1783
0
32
LT会:普段お世話になってるStackTraceと少しだけ向き合ってみる
tsukamoto1783
0
78
初使用の技術スタックで、 ミニマルなアプリケーションを 2日で作る
tsukamoto1783
0
89
アクセシビリティ対応について考えよう
tsukamoto1783
0
29
Flutterのすヽめ
tsukamoto1783
0
30
Other Decks in Technology
See All in Technology
探索・可視化・自動化を一本化 Amazon Quickでデータ活用スピードを上げる方法
koheiyoshikawa
0
170
変更し続けられるシステムをどう保つか — AI時代のSSoTという設計原則
kawauso
1
1.1k
Oracle Exadata Database Service on Cloud@Customer X11M (ExaDB-C@C) サービス概要
oracle4engineer
PRO
2
8.5k
AI_Dev_Day_製造業領域でのAI活用から見た活用の罠と成功に導く実践知.pdf
kintotechdev
0
160
CDKで書くECSのベストプラクティス、 改めて考え直す2026 #cdkconf2026
makies
3
940
PHPで作って学ぶリアルタイム音声対話AIとWebSocket入門 by ムナカタ
munakata
0
130
”AIを使う” から ”AIに任せる” へ ─ 開発プロセスを再設計してAIを組織標準にするまで
cyberagentdevelopers
PRO
1
140
AI時代におけるエンジニアの新たな役割──FDEとクオリアの探求/登壇資料(戸井田 裕貴)
hacobu
PRO
0
310
それでも、技術なブログを書く理由 #kichijojipm / Why I Still Write Tech Blogs Even Now
shinkufencer
0
360
AI時代におけるテストの基礎の再定義 / Rethinking the Fundamentals of Testing in the AI Era
mineo_matsuya
13
4.4k
Amazon Quick 入門!
ysuzuki
2
130
全社でのソフトウェアサプライチェーン攻撃対策をやってみた with Takumi Guard
z63d
0
270
Featured
See All Featured
A Soul's Torment
seathinner
6
3.1k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3.4k
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
220
The SEO identity crisis: Don't let AI make you average
varn
0
520
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
620
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
Deep Space Network (abreviated)
tonyrice
0
230
New Earth Scene 8
popppiees
3
2.4k
Git: the NoSQL Database
bkeepers
PRO
432
67k
ラッコキーワード サービス紹介資料
rakko
1
4M
The World Runs on Bad Software
bkeepers
PRO
72
12k
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(非可逆圧縮):人間の目に分からない細かいデータを間引くイメージ 容量は減るが、画質は劣化*する (≒*人の目には”元のピクセル維持”に見える、元に戻らない)
まとめ 改めて、何が原因だったでしょうか?
まとめ “アプリ側リサイズ時” と ”モデル学習時” に使用している ”補間アルゴリズム” の違 いが原因(学習時よりも画質の荒い画像データで推論実行していたため)
まとめ • よくあるライブラリのリサイズ関数には ”補間処理” が入ることを認知する • リサイズの補間アルゴリズムの違いをざっくり把握する →「知らない・存在自体認知していない」と、調べることもできない、調査対象にも ならない 「画像がボケる」「推論結果が一致しない」...
そんな時は裏側で動いている補間種類について新ためて確認し、最適な補間種類 を選択しましょう。 プロとして補間種類の特徴を理解し、要件に合わせて適切に使い分けれれるようになりたいよね。っというお話(自戒)でした。
画像リサイズ関数の裏側では何が起きている? ~ 補間アルゴリズムの違いを把握して適切な選択を ~ ご清聴ありがとうございました