Mga batayan ng Web Worker image processing

By Technical specialist

Pinapayagan ng Web Worker ang browser na magproseso ng image sa hiwalay na thread para hindi mag-freeze ang UI. Ginagamit ito ng Easy Background Remover.

Hindi mo kailangang i-configure ang workers mismo.

Ang pangunahing thread ay may user-interface na trabaho

Ang isang pahina ng browser ay karaniwang nagpapatakbo ng JavaScript sa isang pangunahing thread. Ang thread na iyon ay nag-coordinate din ng layout, painting, at input. Kung ang isang mahabang pagkalkula ay sumasakop dito, ang mga pag-click ay maaaring maantala, ang animation ay maaaring huminto, at ang browser ay maaaring magbabala na ang pahina ay hindi tumutugon.

Ang isang editor ng imahe ay may maraming mga pangunahing responsibilidad sa thread bago pa man magsimula ang hinuha:

• makatanggap ng seleksyon ng file, i-paste, o i-drop;
• mag-decode at magpakita ng isang imahe;
• pag-update ng pag-unlad at mga estado ng error;
• iguhit ang preview na canvas;
• hawakan Magdagdag at Burahin ang kilusan ng brush;
• maghanda ng mga aksyon sa pag-download o clipboard.

Ang paglalagay ng numerical work ng isang segmentation model sa parehong thread ay gagawing direktang makipagkumpitensya ang mga gawaing iyon. Ang isang manggagawa ay lumilikha ng isang mas malinaw na hangganan.

Ang hangganang nakabatay sa mensahe

Ang editor at manggagawa ay hindi nagbabahagi ng mga ordinaryong variable. Nag-uusap sila sa pamamagitan ng pagpapadala ng mga mensahe. Mukhang ganito ang pinasimpleng daloy:

1. Lumilikha o muling gumagamit ang editor ng isang manggagawa.
2. Hinihiling nito sa manggagawa na simulan ang pagproseso runtime at modelo.
3. Naghahanda ito ng data ng imahe at nagpapadala ng kahilingan sa hinuha.
4. Kino-convert ng manggagawa ang data sa inaasahang input ng modelo.
5. Ang manggagawa ang nagpapatakbo ng modelo at gumagawa ng mga halaga ng maskara.
6. Ibinabalik nito ang mask o data ng resulta.
7. Binubuo ng editor ang preview at pinapagana ang pagpipino o pag-export.

Ang mga mensahe ay dapat magsama ng sapat na konteksto upang tumugma sa isang tugon sa tamang kahilingan. Mahalaga ito kung pipili ang isang user ng isa pang larawan bago matapos ang nakaraang trabaho. Dapat iwasan ng interface ang pagpapakita ng isang lumang resulta sa isang bagong pinagmulan.

Pagkopya at paglilipat ng data ng imahe

Ang pagpapadala ng isang maliit na text message ay mura. Maaaring magastos ang pagpapadala ng milyun-milyong halaga ng pixel kung kailangang kopyahin ng browser ang buong buffer. Sa halip, maaaring ilipat ng mga Web API ang pagmamay-ari ng ilang binary buffer. Ang isang inilipat na buffer ay magiging available sa receiver nang hindi nagpapanatili ng magagamit na duplicate sa gilid ng nagpadala.

Ang pag-optimize na iyon ay may kasamang hadlang sa disenyo: pagkatapos ng paglipat, hindi maaaring patuloy na gamitin ng nagpadala ang parehong buffer na parang pagmamay-ari pa rin nito ang data. Ang isang editor ay maaaring magpanatili ng isang hiwalay na representasyon ng display, lumikha ng isang nakalaang pagproseso buffer, o buuin muli kung ano ang kailangan nito sa ibang pagkakataon.

Hindi lahat ng pagpapatupad ay gumagamit ng paglipat sa eksaktong parehong mga lugar. Ang pangkalahatang aral ay hindi pinapawi ng paghihiwalay ng thread ang paggalaw ng data. Ang mga dimensyon ng larawan, laki ng buffer, at ang bilang ng mga conversion ay nakakaapekto pa rin sa latency at memorya.

Ano ang inilalagay ng Easy Background Remover sa manggagawa

Gumagamit ang Easy Background Remover ng isang Web Worker na may runtime ng pagproseso ng browser para sa on-device na segmentation. Ang mabigat na awtomatikong pag-alis ng background na hakbang ay gumagawa ng maskara. Ang editor pagkatapos ay ipinapakita ang pinagsama-samang resulta at sumusuporta sa CPU-canvas brush refinement.

Ang paghihiwalay na ito ay nagbibigay sa mga pagkabigo ng isang mas kapaki-pakinabang na hangganan. Kung hindi makapagsimula o mag-crash ang manggagawa sa panahon ng pagproseso, maaaring mag-ulat ang interface ng error na nauugnay sa manggagawa sa halip na umasa sa isang tab na permanenteng nagyelo bilang tanging signal.

Pinapanatili din nitong nauunawaan ang claim sa lokal na pagproseso. Ang pagpapadala ng mga pixel mula sa isang extension page sa sarili nitong manggagawa ay komunikasyon sa loob ng browser environment, hindi isang pag-upload sa isang remote pag-alis ng background API. Maaaring hiwalay na i-download ng unang session ang reusable model asset; tingnan ang Bakit nagda-download ng modelo ang unang pagtakbo.

Ang isang manggagawa ay hindi gumagawa ng mabilis na pagkalkula

Pinapabuti ng mga manggagawa ang kakayahang tumugon, hindi ang kakayahan ng raw device. Ang modelo ay gumagamit pa rin ng CPU, GPU, o iba pang mga mapagkukunan ng runtime ayon sa kung ano ang maibibigay ng browser. Ang isang malaking input ay maaari pa ring magtagal at nangangailangan ng mas maraming memory kaysa sa isang maliit.

Nananatili ang ilang limitasyon:

• Ang pagsisimula ng modelo ay may tunay na gastos;
• Ang mga pixel buffer ay sumasakop sa memorya sa magkabilang panig kung kinopya;
• Ang pagbabago ng laki at pag-format ng conversion ay tumatagal ng oras;
• Ang mga aparatong mababa ang memorya ay maaaring makipagpunyagi sa malalaking larawan;
• mas maraming manggagawa ang maaaring magpataas ng pagtatalo sa halip na bawasan ito;
• Ang mga pag-update sa pag-export at canvas ay maaari pa ring kasangkot sa pangunahing thread.

Ang pagsisimula ng limang pagproseso worker para sa limang larawan ay hindi awtomatikong limang beses na mas mabilis. Ang mga manggagawa ay nakikibahagi sa parehong makina. Ang mga parallel na trabaho ay maaaring makipagkumpitensya para sa bandwidth ng memorya at mga mapagkukunan ng pagpapatupad, habang ang bawat halimbawa ng modelo ay maaaring magdala ng sarili nitong gastos sa memorya.

Ang pag-uulat ng progreso ay kooperatiba

Ang isang manggagawa ay maaaring magpadala ng mga mensahe ng katayuan, ngunit hindi nito awtomatikong alam kung anong porsyento ng pag-unlad ang mararamdamang tumpak. Ang pag-download ng modelo, pagsisimula ng runtime, paghahanda ng input, pagproseso, conversion ng mask, at pag-render ng preview ay magkahiwalay na mga yugto na may iba’t ibang timing.

Ang ilang mga phase ay may nasusukat na bilang ng byte. Ang isang solong pagpapatupad ng modelo ay maaari lamang ilantad ang “nagsimula” at “tapos na.” Ang isang maayos na porsyento na umuunlad nang pantay-pantay ay maaaring maging kosmetiko sa halip na isang tumpak na sukat.

Ang kapaki-pakinabang na pag-unlad ng UI ay pinangalanan ang yugto kung posible: paghahanda ng modelo, pagproseso ng larawan, o resulta ng pagbuo. Pinangangasiwaan din nito ang pagkabigo at pagkansela sa halip na mag-iwan ng spinner na walang paliwanag.

Ang pagkansela ay higit pa sa pagtatago ng spinner

Kung isasara ng user ang isang larawan o magsisimulang muli, maaaring balewalain ng interface ang magiging tugon mula sa hindi napapanahong kahilingan. Ang paghinto kaagad sa pinagbabatayan na pagkalkula ay maaaring mangailangan ng karagdagang suporta mula sa runtime o pagwawakas at muling paggawa sa manggagawa.

Ang pagwawakas sa isang manggagawa ay mapagpasyahan, ngunit itinatapon nito ang nasimulang estado nito. Maaaring kailanganin ng susunod na trabaho na i-load at simulan muli ang modelo. Para sa isang maikling operasyon, ang pagmamarka ng lipas na resulta ay maaaring maging mas mura kaysa sa pagsira sa lahat.

Ang tamang pagpipilian ay nakasalalay sa presyon ng memorya, tagal ng operasyon, at mga kakayahan sa runtime. Mula sa pananaw ng user, ang mahalagang panuntunan ay hindi dapat i-overwrite ng lipas na trabaho ang kasalukuyang pag-edit.

Ang mga error ay kailangang tumawid din sa hangganan

Ang isang exception sa loob ng isang manggagawa ay hindi nagiging isang normal na main-thread exception. Dapat mag-ulat ang manggagawa ng mga magagamit na error, at dapat makinig ang editor para sa mga pagkabigo sa antas ng manggagawa.

Ang mahusay na paghawak ng error ay nakikilala ng hindi bababa sa:

• hindi available ang modelong asset;
• Nabigo ang pagsisimula ng modelo;
• Nabigo ang pag-decode ng imahe o paghahanda ng input;
• nabigo ang hinuha;
• huminto ang manggagawa nang hindi inaasahan;
• ang resulta ay hindi na kabilang sa kasalukuyang kahilingan.

Ito ay mas naaaksyunan kaysa sa isang generic na “may nangyaring mali,” lalo na kapag ang unang-run na setup at normal na pagpoproseso ng imahe ay may iba’t ibang mga remedyo.

Ang output ng manggagawa ay isa pa ring unang maskara

Ang arkitektura ng thread ay hindi nagpapabuti sa isang hindi tiyak na gilid nang mag-isa. Maaaring ibalik ng manggagawa ang isang teknikal na wastong maskara na wala pa ring balahibo, transparent na materyal, makitid na strap, o isang gustong anino. Iyon ay segmentation at intent questions.

Ang trabaho ng editor ay nagpapatuloy pagkatapos ng hinuha: i-scale ang mask sa gumaganang coordinate system, i-composite ang isang preview, hayaan ang user na pinuhin ito, at i-export ang kasalukuyang estado. Ipinapaliwanag ng Resolusyon ng maskara kumpara sa laki ng preview kung bakit hindi dapat malito ang mga coordinate system na iyon.

Isang maigsi na modelo ng pag-iisip

Isipin ang manggagawa bilang isang lokal na espesyalista sa likod ng window ng mensahe:

• pagmamay-ari ng editor ang pakikipag-ugnayan;
• pagmamay-ari ng manggagawa ang mabigat na gawaing hinuha;
• ang binary na data ng imahe ay tumatawid sa isang tinukoy na hangganan;
• ang manggagawa ay nagbabalik ng maskara, hindi isang tapos na paghatol tungkol sa bawat gilid;
• ang editor ay nananatiling responsable para sa kasalukuyang estado, pagsusuri, pagpipino, at pag-export.

Para sa view ng modelo sa mga pixel mismo, magpatuloy sa [What an on-device pag-alis ng background model seees](/fil/what-an-on-device-pag-alis ng background-model-sees/). Para sa end-to-end na praktikal na pangkalahatang-ideya, tingnan ang Paano gumagana ang lokal na pag-aalis ng background.