Grunnleggende bildebehandling med Web Worker

By Technical specialist

Tunge beregninger på hovedtråden gjør siden treg. En Web Worker kjører modellberegningen på egen tråd, så knapper og forhåndsvisning forblir brukbare.

For deg merkes det som at editoren fortsatt svarer mens masken beregnes.

Hovedtråden har en brukergrensesnittjobb

En nettleserside kjører vanligvis JavaScript på en hovedtråd. Den tråden koordinerer også layout, maling og input. Hvis en lang beregning opptar det, kan klikk føles forsinket, animasjonen kan stoppe, og nettleseren kan advare om at siden ikke svarer.

En bilderedigerer har mange hovedtrådsansvar før konklusjonen i det hele tatt starter:

• motta et filvalg, lim inn eller slipp;
• dekode og vise et bilde;
• oppdater fremdrift og feiltilstander;
• tegne forhåndsvisningslerretet;
• håndtak Legg til og slett børstebevegelse;
• forberede nedlastings- eller utklippstavlehandlinger.

Å sette en segmenteringsmodells numeriske arbeid på samme tråd ville få disse oppgavene til å konkurrere direkte. En arbeider skaper en klarere grense.

Den meldingsbaserte grensen

Redaktøren og arbeideren deler ikke vanlige variabler. De kommuniserer ved å sende meldinger. En forenklet flyt ser slik ut:

1. Redaktøren oppretter eller gjenbruker en arbeider.
2. Den ber arbeideren om å initialisere slutningskjøringen og modellen.
3. Den forbereder bildedata og sender en slutningsforespørsel.
4. Arbeideren konverterer dataene til modellens forventede input.
5. Arbeideren kjører modellen og produserer maskeverdier.
6. Den sender masken eller resultatdataene tilbake.
7. Redaktøren setter sammen forhåndsvisningen og muliggjør foredling eller eksport.

Meldinger bør inneholde nok kontekst til å matche et svar på riktig forespørsel. Dette har betydning hvis en bruker velger et annet bilde før forrige jobb er ferdig. Grensesnittet må unngå å vise et gammelt resultat over en ny kilde.

Kopiering og overføring av bildedata

Det er billig å sende en liten tekstmelding. Å sende millioner av pikselverdier kan være dyrt hvis nettleseren må kopiere hele bufferen. Web-APIer kan overføre eierskap til visse binære buffere i stedet. En overført buffer blir tilgjengelig for mottakeren uten å beholde et brukbart duplikat på sendersiden.

Denne optimeringen kommer med en designbegrensning: etter overføring kan avsenderen ikke fortsette å bruke den samme bufferen som om den fortsatt eier dataene. En redaktør kan beholde en separat visningsrepresentasjon, lage en dedikert slutningsbuffer eller rekonstruere det den trenger senere.

Ikke alle implementeringer bruker overføring på nøyaktig de samme stedene. Den generelle lærdommen er at trådseparasjon ikke får databevegelsen til å forsvinne. Bildedimensjoner, bufferstørrelse og antall konverteringer påvirker fortsatt ventetid og minne.

Hva Easy Background Remover legger i arbeideren

Easy Background Remover bruker en Web Worker med en nettleserinferenskjøring for segmentering på enheten. Det tunge automatiske utskjæringstrinnet produserer en maske. Redigeringsprogrammet viser deretter det sammensatte resultatet og støtter forfining av CPU-lerrets børste.

Denne separasjonen gir feil en mer nyttig grense. Hvis arbeideren ikke kan initialisere eller krasjer under inferens, kan grensesnittet rapportere en arbeiderrelatert feil i stedet for å stole på en permanent frossen fane som eneste signal.

Det holder også kravet om lokal behandling forståelig. Å sende piksler fra en utvidelsesside til sin egen arbeider er kommunikasjon i nettlesermiljøet, ikke en opplasting til en ekstern cutout API. Den første økten kan separat laste ned det gjenbrukbare modellelementet; se Hvorfor først kjøre laster ned en modell.

En arbeider gjør ikke beregningen øyeblikkelig

Arbeidere forbedrer respons, ikke rå enhetskapasitet. Modellen bruker fortsatt CPU, GPU eller andre kjøretidsressurser i henhold til hva nettleseren kan tilby. En stor inngang kan fortsatt ta lengre tid og kreve mer minne enn en liten.

Det gjenstår flere grenser:

• modellinitiering har en reell kostnad;
• pikselbuffere opptar minne på begge sider hvis de kopieres;
• Endre størrelse og formatkonvertering tar tid;
• enheter med lite minne kan slite med store bilder;
• flere arbeidere kan øke konflikten i stedet for å redusere den;
• Eksport og lerretsoppdateringer kan fortsatt involvere hovedtråden.

Å starte fem inferensarbeidere for fem bilder er ikke automatisk fem ganger raskere. Arbeiderne deler samme maskin. Parallelle jobber kan konkurrere om minnebåndbredde og utførelsesressurser, mens hver modellforekomst kan bære sine egne minnekostnader.

Fremdriftsrapportering er samarbeidsvillig

En arbeider kan sende statusmeldinger, men den vet ikke automatisk hvilken fremdriftsprosent som vil føles nøyaktig. Modellnedlasting, runtime-initialisering, inputforberedelse, inferens, maskekonvertering og forhåndsvisningsgjengivelse er separate faser med ulik timing.

Noen faser har målbare bytetellinger. En enkelt modellutførelse kan bare vise “startet” og “ferdig”. En jevn prosentandel som går jevnt frem kan derfor være kosmetisk i stedet for en nøyaktig måling.

Nyttig fremdriftsgrensesnitt navngir fasen når det er mulig: forberede modell, behandle bilde eller bygge resultat. Den håndterer også feil og kansellering i stedet for å etterlate en spinner uten forklaring.

Avbestilling er mer enn å skjule en spinner

Hvis brukeren lukker et bilde eller starter på nytt, kan grensesnittet ignorere det eventuelle svaret fra den utdaterte forespørselen. Å stoppe den underliggende beregningen umiddelbart kan kreve ekstra støtte fra kjøretiden eller å avslutte og gjenskape arbeideren.

Å si opp en arbeider er avgjørende, men det forkaster den initialiserte tilstanden. Den neste jobben må kanskje lastes inn og initialiseres på nytt. For en kort operasjon kan det være billigere å markere resultatet som foreldet enn å rive ned alt.

Det riktige valget avhenger av minnetrykk, operasjonsvarighet og kjøretidskapasitet. Fra brukerens perspektiv er den viktige regelen at gammelt arbeid ikke må overskrive gjeldende redigering.

Feil må også krysse grensen

Et unntak inne i en arbeider blir ikke et normalt hovedtrådunntak. Arbeideren må rapportere brukbare feil, og redaktøren bør lytte etter feil på arbeidernivå.

God feilhåndtering skiller minst:

• modellaktivum utilgjengelig;
• modellinitialisering mislyktes;
• bildedekoding eller inndataforberedelse mislyktes;
• slutning mislyktes;
• arbeider stoppet uventet;
• Resultatet tilhører ikke lenger gjeldende forespørsel.

Dette er mer handlingsdyktig enn et generisk “noe gikk galt”, spesielt når førstegangsoppsett og normal bildebehandling har forskjellige løsninger.

Arbeiderutgang er fortsatt bare en første maske

Trådarkitektur forbedrer ikke en tvetydig kant i seg selv. Arbeideren kan returnere en teknisk gyldig maske som fortsatt mangler pels, gjennomsiktig materiale, smale stropper eller en ønsket skygge. Dette er segmenterings- og intensjonsspørsmål.

Redaktørens jobb gjenopptas etter inferens: skaler masken til det fungerende koordinatsystemet, komponer en forhåndsvisning, la brukeren avgrense den og eksporter gjeldende tilstand. Maskeoppløsning vs forhåndsvisningsstørrelse forklarer hvorfor disse koordinatsystemene ikke skal forveksles.

En kortfattet mental modell

Tenk på arbeideren som en lokal spesialist bak et meldingsvindu:

• redaktøren eier interaksjonen;
• arbeideren eier den tunge slutningsoppgaven;
• binære bildedata krysser en definert grense;
• arbeideren returnerer en maske, ikke en ferdig vurdering om hver kant;
• redaktøren forblir ansvarlig for gjeldende status, gjennomgang, foredling og eksport.

For modellens visning av selve pikslene, fortsett med What a on-device cutout model sees. For en praktisk oversikt fra ende til ende, se Hvordan lokal bakgrunnsfjerning fungerer.