Grunderna för bildbehandling av Web Worker
En Web Worker är en separat JavaScript-exekveringskontext som kan utföra dyra beräkningar utan att få redaktörens huvudtråd att göra allt arbete. För webbläsarbildbehandling betyder det att modellinställningar och slutledningar kan springa bort från tråden som ansvarar för knappar, förloppsmeddelanden, borstinmatning och skärmuppdateringar.
Resultatet är inte “gratis bakgrundsbearbetning.” Samma enhet utför fortfarande beräkningen och använder minne. Den arkitektoniska fördelen är separation: en tung modelloperation är mindre sannolikt att blockera varje gränssnittssvar medan den körs.
Huvudtråden har ett användargränssnittsjobb
En webbläsarsida kör normalt JavaScript på en huvudtråd. Den tråden koordinerar också layout, målning och input. Om en lång beräkning upptar det kan klick kännas försenade, animering kan stoppas och webbläsaren kan varna att sidan inte svarar.
En bildredigerare har massor av huvudtrådsansvar innan slutledning ens börjar:
- ta emot ett filval, klistra in eller släpp;
- avkoda och visa en bild;
- uppdatera framsteg och feltillstånd;
- rita förhandsgranskningsduken;
- handtag Lägg till och radera borströrelse;
- förbered nedladdnings- eller urklippsåtgärder.
Att lägga en segmenteringsmodells numeriska arbete på samma tråd skulle få dessa uppgifter att konkurrera direkt. En arbetare skapar en tydligare gräns.
Den meddelandebaserade gränsen
Redaktören och arbetaren delar inte vanliga variabler. De kommunicerar genom att skicka meddelanden. Ett förenklat flöde ser ut så här:
- Redaktören skapar eller återanvänder en arbetare.
- Den ber arbetaren att initiera slutledningstiden och modellen.
- Den förbereder bilddata och skickar en slutledningsbegäran.
- Arbetaren omvandlar data till modellens förväntade input.
- Arbetaren kör modellen och producerar maskvärden.
- Den skickar mask- eller resultatdata tillbaka.
- Redaktören sammanställer förhandsgranskningen och möjliggör förfining eller export.
Meddelanden bör innehålla tillräckligt med sammanhang för att matcha ett svar på rätt begäran. Detta har betydelse om en användare väljer en annan bild innan det föregående jobbet avslutas. Gränssnittet måste undvika att visa ett gammalt resultat över en ny källa.
Kopiera och överföra bilddata
Att skicka ett litet sms är billigt. Att skicka miljontals pixelvärden kan bli dyrt om webbläsaren måste kopiera hela bufferten. Webb-API:er kan istället överföra äganderätten till vissa binära buffertar. En överförd buffert blir tillgänglig för mottagaren utan att behålla en användbar duplikat på avsändarsidan.
Den optimeringen kommer med en designbegränsning: efter överföringen kan avsändaren inte fortsätta använda samma buffert som om den fortfarande äger data. En redaktör kan behålla en separat visningsrepresentation, skapa en dedikerad slutledningsbuffert eller rekonstruera vad den behöver senare.
Inte varje implementering använder överföring på exakt samma ställen. Den allmänna lärdomen är att trådseparation inte gör att datarörelser försvinner. Bilddimensioner, buffertstorlek och antalet konverteringar påverkar fortfarande latens och minne.
Vad Easy Background Remover lägger i arbetaren
Easy Background Remover använder en Web Worker med en webbläsarinferenskörning för segmentering på enheten. Det tunga automatiska utskärningssteget producerar en mask. Redaktören visar sedan det sammansatta resultatet och stöder förfining av pensel för CPU-canvas.
Denna separation ger misslyckanden en mer användbar gräns. Om arbetaren inte kan initiera eller kraschar under slutledning, kan gränssnittet rapportera ett arbetarrelaterat fel istället för att förlita sig på en permanent frusen flik som enda signal.
Det håller också påståendet om lokal bearbetning begripligt. Att skicka pixlar från en tilläggssida till sin egen arbetare är kommunikation inom webbläsarmiljön, inte en uppladdning till ett fjärrutskärnings-API. Den första sessionen kan ladda ner den återanvändbara modelltillgången separat; se Varför först köra laddar ner en modell.
En arbetare gör inte beräkningar direkt
Arbetare förbättrar lyhördheten, inte obehandlad enhetskapacitet. Modellen förbrukar fortfarande CPU, GPU eller andra körtidsresurser beroende på vad webbläsaren kan tillhandahålla. En stor ingång kan fortfarande ta längre tid och kräva mer minne än en liten.
Flera gränser kvarstår:
- modellinitiering har en verklig kostnad;
- pixelbuffertar upptar minne på båda sidor om de kopieras;
- storleksändring och formatkonvertering tar tid;
- enheter med lågt minne kan kämpa med stora bilder;
- Fler arbetstagare kan öka konflikterna istället för att minska dem.
- Export och canvasuppdateringar kan fortfarande involvera huvudtråden.
Att starta fem inferensarbetare för fem bilder är inte automatiskt fem gånger snabbare. Arbetarna delar samma maskin. Parallella jobb kan konkurrera om minnesbandbredd och exekveringsresurser, medan varje modellinstans kan bära sin egen minneskostnad.
Framstegsrapporteringen är samarbetsvillig
En arbetare kan skicka statusmeddelanden, men den vet inte automatiskt vilken framstegsprocent som kommer att kännas korrekt. Modellnedladdning, runtime-initiering, ingångsförberedelse, slutledning, maskkonvertering och förhandsvisningsrendering är separata faser med olika timing.
Vissa faser har mätbara byte-antal. En enskild modellutförande kan bara visa “startad” och “avslutad”. En jämn procentandel som avancerar jämnt kan därför vara kosmetisk snarare än en exakt mätning.
Användbara framsteg UI namnger fasen när det är möjligt: förbereda modell, bearbeta bild eller bygga resultat. Den hanterar också fel och avbokningar istället för att lämna en spinner utan förklaring.
Avbokning är mer än att dölja en spinner
Om användaren stänger en bild eller börjar om kan gränssnittet ignorera det eventuella svaret från den föråldrade begäran. Att stoppa den underliggande beräkningen omedelbart kan kräva ytterligare stöd från körtiden eller avsluta och återskapa arbetaren.
Att säga upp en arbetare är avgörande, men det kasserar dess initialiserade tillstånd. Nästa jobb kan behöva ladda och initiera modellen igen. För en kort operation kan det vara billigare att markera resultatet som inaktuellt än att riva allt.
Det korrekta valet beror på minnestryck, drifttid och körtid. Ur användarens perspektiv är den viktiga regeln att inaktuellt arbete inte får skriva över den aktuella redigeringen.
Fel måste också passera gränsen
Ett undantag inom en arbetare blir inte ett normalt huvudtrådsundantag. Arbetaren måste rapportera användbara fel, och redaktören bör lyssna efter fel på arbetarnivå.
Bra felhantering särskiljer åtminstone:
- modelltillgång inte tillgänglig;
- modellinitiering misslyckades;
- bildavkodning eller inmatningsförberedelse misslyckades;
- slutledning misslyckades;
- arbetare slutade oväntat;
- Resultatet hör inte längre till den aktuella begäran.
Detta är mer åtgärdbart än ett allmänt “något gick fel”, särskilt när den första installationen och normal bildbehandling har olika lösningar.
Arbetarutdata är fortfarande bara en första mask
Trådarkitektur förbättrar inte en tvetydig kant i sig. Arbetaren kan returnera en tekniskt giltig mask som fortfarande saknar päls, transparent material, smala remmar eller en önskad skugga. Det är segmenterings- och avsiktsfrågor.
Redaktörens jobb återupptas efter slutledning: skala masken till det fungerande koordinatsystemet, komponera en förhandsgranskning, låt användaren förfina den och exportera det aktuella tillståndet. Maskupplösning vs förhandsvisningsstorlek förklarar varför dessa koordinatsystem inte ska förväxlas.
En kortfattad mental modell
Tänk på arbetaren som en lokal specialist bakom ett meddelandefönster:
- redaktören äger interaktionen;
- Arbetaren äger den tunga slutledningsuppgiften;
- binära bilddata korsar en definierad gräns;
- arbetaren lämnar tillbaka en mask, inte en färdig bedömning av varje kant;
- Redaktören förblir ansvarig för aktuell status, granskning, förfining och export.
För modellens bild av själva pixlarna, fortsätt med What a on-device cutout model sees. För en praktisk översikt från början till slut, se Hur lokal bakgrundsborttagning fungerar.