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
Web技術を最大限活用してRAW画像を現像する / Developing RAW Images...
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
TOMIKAWA Sotaro
September 21, 2025
Programming
3.3k
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Web技術を最大限活用してRAW画像を現像する / Developing RAW Images on the Web
https://fec-tokyo.connpass.com/event/352581/
TOMIKAWA Sotaro
September 21, 2025
More Decks by TOMIKAWA Sotaro
See All by TOMIKAWA Sotaro
ReactとSvelteのその先、Ripple-TS / Beyond React and Svelte: Ripple-TS
ssssota
3
2.5k
Atomics APIを知る / Understanding Atomics API
ssssota
2
1.4k
なんでRustの環境構築してないのにRust製のツールが動くの? / Why Do Rust-Based Tools Run Without a Rust Environment?
ssssota
15
56k
漸進。
ssssota
0
3.7k
Preact、HooksとSignalsの両立 / Preact: Harmonizing Hooks and Signals
ssssota
1
3.8k
useSyncExternalStoreを使いまくる
ssssota
6
7k
React CompilerとFine Grained Reactivityと宣言的UIのこれから / The next chapter of declarative UI
ssssota
8
6.2k
新しいAPI createRawSnippet触ってみた / What is the createRawSnippet?
ssssota
2
340
脱法Svelte / Evasion of svelte rules
ssssota
1
350
Other Decks in Programming
See All in Programming
AI時代に設計が 最大の生産性レバーになる 意図駆動開発とデータを消さない設計|Don't Delete Your Data or Your Intent — Design as the Deepest Lever in the AI Era
tomohisa
1
840
What's New in Android 2026
veronikapj
0
260
自動化したのに回らない テスト運用の壁―AI時代の品質責任と生産性
mfunaki
0
160
Android CLI
fornewid
0
220
ITヒヤリハットを整理してみた ~ライフサイクルと原因から考える再発防止策~
koukimiura
1
140
ドリフトを絶対に許さない(?)CDK運用 / CDK Ops with Zero Tolerance for Drifts (?)
akihisaikeda
1
180
SlackアプリとLambdaの 連携を構築した話
pawn_4_s
1
120
進化を続けるGo toolsの現在地 / The Current State of Ever-Evolving Go Tools
hond0413
0
210
PHP Application における Kubernetes 内 gRPC 通信
ganchiku
0
590
OpenSpecのproposalにbrainstormingを持たせてみた
tigertora7571
1
220
型も通る、synthも通る、それでも危ない 〜AIのCDKの権限とコストを機械で検証する〜 / It Passes Type Checks, It Passes Synth Checks, but It’s Still Risky — Automatically Verifying Permissions and Costs in AI’s CDK —
seike460
PRO
1
550
わからない話を追いかけたら、プログラミング言語を作る側にいた
ydah
3
500
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
55
10k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
2k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
Ten Tips & Tricks for a 🌱 transition
stuffmc
0
160
Lightning Talk: Beautiful Slides for Beginners
inesmontani
PRO
2
630
For a Future-Friendly Web
brad_frost
183
10k
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
700
Optimising Largest Contentful Paint
csswizardry
37
3.9k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.5k
Are puppies a ranking factor?
jonoalderson
1
3.8k
Embracing the Ebb and Flow
colly
88
5.1k
Transcript
Web技術を最⼤限活⽤して RAW画像を現像する sssssota / #fec_tokyo
⾃⼰紹介 ssssota (冨川宗太郎) sは4つ テックリード(写真・現像は素人) { x: "ssssotaro", gh: "ssssota",
cameras: ["S5IIX", "S9", "fp L"] }
RAW画像とは何か カメラをやっているとRAW画像という概念に出会う (最近ではiPhoneなどのスマホでもRAW画像を出力できる) 一般的な写真のフォーマットであるJPEGはRGB各8bit、 計24bitで色を表現する すると (28)3=約1680万色 になる
RAW画像とは何か カメラのセンサーは各色12bit〜16bitといった解像能を持つ 8bit→1680万色だったのが14bit→4兆色になる すると、ファイルサイズがでかくなる。(30MiB〜100MiB)
RAW画像とは何か そんなとても大きいRAW画像 カメラメーカー各社が独自規格で出力してくれる オープンな規格(TIFF, DNG)も存在するが 日本の大手メーカー各社は使わず...
RAW画像を現像する とにかくデカい、独自規格なバイナリ 一般的には デスクトップアプリケーション・モバイルアプリケーションで ネイティブな並列処理、GPU処理を活用しながら行う
Webエンジニアなので Webで完結させたい
resolve.photos
概観
課題の整理 1. カメラメーカー各社の独自フォーマット 2. デカいファイルに対する処理速度
LibRaw RAW画像を読めるOSS メーカー独自の規格の多くを自前でサポートするのは困難 ただしC++
C++のLibRawをブラウザで動かすためにWASMを使う WASMへのコンパイルにはEmscriptenを使う libraw.wasm
WebAssemblyの制約 現在も仕様の策定が進行しているが、JS - WASM間で 文字列や構造体などの非数な値をやりとりするのは難しい メモリ空間は共有できるので、 構造体をメモリに直接読み書きする手法を用いる
メモリから構造体を読むために C/C++の構造体は定義からメモリレイアウトが確定する struct Sample { uint8_t foo; uint16_t bar; }
typed-cstruct 構造体の定義をTypeScriptで書き下すと型付きで バイナリを読み書きできるようになるライブラリ 構造体がたくさんあると手書きが大変なので @typed-cstruct/generator でCのヘッダーファイルからTypeScriptも生成
WebAssemblyは速いが WebAssemblyはそれなりに速いが、 JavaScriptと同じスレッドで動くために メインスレッドでヘビーな利用をするとUIが硬直する
Web Worker WebAssemblyで動かすようなCPUヘビーな処理は 往々にしてWeb Workerに逃がす Web Workerに逃がすことでUIをブロッキングせずに 処理を進める Comlinkやbidcを用いてWeb Workerとの通信を
抽象化するのが一般的
レンダリングする ここまででビットマップ画像が得られる Canvas APIではRGB各色16bitのビットマップを扱えない WebGL 2.0を使うことになる
現像する 現状resolve.photosはノイズ除去や収差補正はサポートせず とある動画編集ソフトを参考にノードベースのLUT適用を実現
⾼速なLUT適⽤ 6000x4000ピクセルの色を取得、1つずつLUTに入れて... とするととても遅い 1つのことを繰り返しするのはGPUが得意 → WebGPU WebGL2でレンダリング時に
LUTをテクスチャとして読み込み、WebGLで画像に対し適用 ノードベースで複数のノード(=LUT)があることもあるので WebGLのフラグメントシェーダーは動的に生成する WebGLを⽤いたLUT適⽤
概観
改善余地 • そもそも機能数が全く足りてない ◦ 技術的におもしろい部分だけ作って満足している節がある ◦ PoCとしては十分... • WebAssembly Multithreading
◦ 検証不足 • RAW画像解析をそもそもGPGPUできる説 ◦ 現実的ではないが夢はある • 最近はAI現像っていうのが流行ってるらしい ◦ マルチモーダルなローカルLLMがWebにきたらアツいですね
おわり 参考 • https://github.com/ssssota/resolve.photos • https://github.com/ssssota/libraw.wasm • https://github.com/LibRaw/LibRaw • https://github.com/ssssota/typed-cstruct