obrobka

ブラウザ内で完結する画像処理 — 変換、リサイズ、背景除去。ファイルがデバイスから出ることはありません。

obrobka.dobrovolskyi.com.ua

ウクライナ語第一、英語第二。MITライセンス。

機能

すべてWebAssemblyとしてWeb Worker内で実行されます。サーバーもアップロードもアカウントもありません。

Related MCP server: mcp-image-tools

なぜ興味を引くか

同じコアがブラウザアプリとMCPサーバーの両方を支えています。 packages/core はDOMもNode APIも持たず、RGBAバッファーに対する純粋な関数であり、すべてのI/Oはポートの背後にあります。1つの runJob() がブラウザタブとAIエージェントの両方にサービスを提供します。

npx obrobka-mcp

エージェントに8つのツールを提供します — convert_image, resize_image, remove_background, smart_crop, upscale_image, read_metadata, strip_metadata, process_batch — これらはbase64ブロブではなくファイルパスで動作します。

モデルの選択はモデルカードではなく測定に基づいています。 すべての候補は選定前にダウンロードされプロファイリングされました — 数値は M2プランを参照してください。2つの発見が設計を変えました:

• MODNetとormbgは人間のみで訓練されています。人間以外の被写体では空のマスクを返すため、一般的なデフォルトとしては除外されます。

• BiRefNet_liteは1024×1024で4.2 GBの空きメモリがある状態でOOMキラーに殺されました。ブラウザタブはさらに低い上限があるため、採用されませんでした。

U²-Netpは4.4 MBで汎用性があることが判明し、デフォルトの階層は当初の計画より10倍軽量になりました。

スマホの写真が横向きになっていたのに、誰も気づかなかった。 JPEGとHEICは向きをピクセルではなくタグとして保存します。@jsquash/jpeg はそれを無視しますが、ブラウザの <img> は適用します。そのため「処理前」プレビューは直立に見え、結果は横向きになりました — これは Orientation: 6 を持つ専用の8×4 JPEGで測定され、タグの有無にかかわらず8×4にデコードされました。パイプラインは現在、座標を推論する操作の前にタグを読み取って回転させます。

バッチ並行処理には2つの正解があります。 モデルなしでは、4つのワーカーが20ファイルを3639 msから1186 msに短縮します — 223 MBで3.1倍。モデルがある場合、同じプールは罠です: ONNX Runtimeはセッション内で既に並列化しているため、4つのU²-Netpセッションは1.2 GBで1.8倍、2つのisnetセッションは2.2 GBに達し、タブが保持できる上限を超えます。したがってプールは needsModel ? 1 : min(cores − 1, 4) です。

ZIP圧縮は形式に依存し、推測とは異なります。 WebPをデフレートするとCPUが10倍かかるのに0.1%しか節約できません — 予想通りです。当社のPNGをデフレートすると**15.2%**節約できます。エンコーダーが高速に圧縮し、冗長性を残すためです。PNGにはレベル4、それ以外は無圧縮。

アーキテクチャ

packages/core             pure ops over RGBA buffers — no DOM, no Node
  ops/                    resample · crop · fit · mask · outline · smartCrop
  ports/                  Codec · Segmenter · Upscaler · Metadata
packages/codecs           jSquash, split into browser and Node adapters
packages/models           model registry and three preprocessing recipes
packages/onnx-node        onnxruntime-node + on-disk cache
packages/onnx-web         onnxruntime-web + Cache Storage, WebGPU → WASM
packages/metadata         EXIF reading (exifr) and byte-level stripping
packages/heic             libheif, isolated — LGPL, loaded on demand
packages/contract-tests   one suite, run against both adapters
apps/web                  Astro + Svelte island, PWA
apps/mcp                  stdio MCP server

コントラクトテストがポート境界の要点です: 同じスイートが onnxruntime-node と onnxruntime-web の両方に対して実行されるため、それらの間の相違は本番ではなく即座に明らかになります。

モデル

すべて寛容なライセンスです — プロジェクトは寄付を受けているため、非商用モデルライセンスは不適切です。

モデルはR2から配信され、初回使用後にブラウザにキャッシュされます。

開発

Node ≥ 22.12 と pnpm 11 が必要です。

pnpm install
pnpm typecheck
pnpm test
pnpm --filter @obrobka/web dev

一部のテストには実際のHEICが必要ですが、これはローカルで生成できません — libheifは読み取りのみです。ファイルはHEIF適合セットから一度取得され、モデルとともに ~/.cache/obrobka/fixtures にキャッシュされます。EXIF向きやGPSを含むJPEGを含む他のすべては、テスト時にバイト単位で構築されます: リポジトリ内の写真は、誰かの座標を持つ誰かの写真になるからです。

エンドツーエンドテストは、本番の _headers を適用する静的サーバーに対して実行されます。crossOriginIsolated はそれ以外では検証できないためです:

pnpm --filter @obrobka/web build
pnpm exec playwright test

テストに関する注記

セグメンテーションは写真ではなく、手続き的に生成された陰影付き球体に対してテストされます。これによりパイプライン（前処理、推論、マスク、合成）が機能することが証明されますが、髪、ガラス、毛皮の品質については何も語りません。それはサイトを使用して判断してください。

以前のフィクスチャである、硬いエッジを持つ平らな円は、これらのモデルにとって分布外であることが判明しました: 同じ形状が、アップスケールされたかどうかだけで0.97または0.03のスコアになりました。セグメンテーションモデルに対してテストを書く場合は知っておく価値があります。

ライセンス

MIT。モデルの重みはそれぞれ独自のライセンスを持ち、上記に記載されています。