Suporta sa Browser at Performance para sa Client-Side na Background Removal

Ano ang Dapat Ibigay ng Browser

Tumatakbo sa loob ng web page ang client-side background remover, kaya bawat kakayahang kailangan nito ay dapat ibigay ng browser sa halip na i-install. Apat ang mahalaga, at hindi mapapatakbo ang tool sa device na kulang kahit isa.

Pinapatakbo ng WebAssembly ang model sa sariling sandbox ng browser, kaya nananatili sa device mo ang footage ng client-side tool; ang bgremover.ai naman ay ina-upload ito sa GPU servers namin, gaya ng ipinapaliwanag sa paano gumagana ang background removal. Halos puro matrix multiplication ang inference, kaya GPU ang kailangan nito: inilalantad ito ng WebGL sa pamamagitan ng graphics API, at ng WebGPU sa pamamagitan ng compute API.

Kung wala ang alinman, babalik sa CPU ang inference. Kailangan ding may mag-encode ng mga tapos na frame sa isang file: MediaRecorder, ang mas malawak na paraan, o WebCodecs, ang mas pino. Ang ikaapat na requirement, memory para sa decoded frames, ang pinakaminamaliit.

Tatlong Execution Path

Workaround ang WebGL at hindi talaga disenyo: ginawa ang API para gumuhit ng triangles, at kumakain ng oras ang paglipat ng data sa textures. Ito pa rin ang praktikal na default. Nakikipag-agawan ang WASM sa main thread maliban kung ilipat sa worker ang trabaho, at kailangan ng BEN2 ng FP16 WebGPU, kaya mga bagong desktop GPU lang.

Availability ang nagpapasya rito, hindi preference: ang tool na WebGPU lang ang ini-implement ay mabilis kung saan ito tumatakbo at wala sa lahat ng iba pa.

Bakit Mas Mabagal ang Unang Takbo

1. 1 Isang beses lang dina-download ang model

   Bago maproseso ang kahit anong frame.

2. 2 Nag-i-initialise at nagwa-warm up ito

   Saka dadaan ang unang frame.

3. 3 Nilalaktawan ng mga susunod na clip ang dalawa

   Galing sa cache, kaya initialisation na lang ang natitira.

Kaya dapat i-load ng client-side tool ang model kapag may ginawang aksyon ang user, hindi pagka-load ng page: ang megabytes ng WebAssembly na dumarating pagbukas mo ay magpapamukhang sira ang page para sa sinumang nagbabasa lang.

Ang Kuwenta ng Decoded Frames

Ang decoded na video frame ay mga uncompressed na pixel, kaya resolution ang pangunahing kumakain ng memory.

Kuwenta ang mga numerong iyon, hindi sukat, at hindi magandang gabay ang compressed na laki ng file. Hindi kailangang naka-decode ang lahat ng frame nang sabay, pero may hawak na working set ang pipeline: ang frame na dine-decode, ang sine-segment, ang mask nito, ang composite, at ang buffer ng encoder.

I-multiply ang ilang frame sa 33 MB sa 4K at magsisimulang maging mahalaga ang budget ng tab, lalo na sa phone. Kung pumalya ang mahabang high-resolution na clip o nag-reload ang tab, bawasan ang resolution sa halip na ang haba: kapag hinati sa dalawa ang bawat dimension, nagiging ikaapat ang memory.

Ano ang Nagtatakda ng Tagal ng Processing

Mga ugnayan ito, hindi numero: walang sinasabi tungkol sa phone ang oras na sinukat sa isang laptop.

• Bilang ng frameHaba beses frame rate; doble ang 60 fps kaysa sa 30 fps.
• ResolutionNakakaapekto sa decode, composite at encode; hindi nagbabago ang inference.
• Execution pathMagkakaiba ang WebGPU, WebGL at WASM-SIMD sa iisang machine.
• Klase ng deviceTatlong magkaibang machine ang GPU ng desktop, laptop at phone.
• Pagpili ng modelMas mahal kada frame ang matting kaysa sa MediaPipe.
• Init ng deviceTina-throttle ang tuloy-tuloy na GPU work sa mainit na phone.

Browser Support Matrix

Dapat may verification kada browser dito bago mag-claim ang site ng universal support. Ang claim na kaya naming gawin nang walang test ay sa architecture: kailangan ng client-side tool ng WebAssembly at GPU path, hindi WebGPU. Kailangan ng bgremover.ai ng WebCodecs, na ginagamit nito para ihanda ang upload at buuin ang export.

Ang Totoong Lagay sa Mobile

Para sa client-side tool, ang maliit na footprint ng MediaPipe selfie segmentation ang nagpapagana sa mobile browser. Kasya sa budget ng tab sa phone ang ilang megabyte na may katamtamang memory; ang model na pang-desktop GPU ay hindi. Iniiwasan ito ng bgremover.ai dahil sa GPU servers tumatakbo ang model nito; ang phone pa rin ang nagde-decode at nag-e-encode ng clip.

Hindi kami magke-claim ng universal mobile support bago mag-test kada browser. Mas mahirap ang mobile: mas kaunting memory kada tab, agresibong eviction, thermal throttling. Ang mas maiikling clip sa mas mababang resolution ang maaasahang paraan, at isang frame lang ang litrato sa photo background remover.

Mga Madalas Itanong