Gratis Chrome-extensie — uitsnijden op je apparaat

Basis van beeldverwerking met een Web Worker

Zware berekeningen op de hoofddraad maken de pagina stroperig. Een Web Worker voert de modelinferentie uit op een aparte thread, zodat knoppen en previews bruikbaar blijven.

Voor jou als gebruiker voelt dat als: de editor blijft reageren terwijl het masker wordt berekend.

De hoofdthread heeft een gebruikersinterfacetaak

Een browserpagina voert normaal gesproken JavaScript uit op een hoofdthread. Die draad coördineert ook de lay-out, het schilderen en de invoer. Als één lange berekening het in beslag neemt, kunnen klikken vertraagd aanvoelen, kunnen de animaties stoppen en kan de browser waarschuwen dat de pagina niet meer reageert.

Een afbeeldingseditor heeft voldoende hoofdverantwoordelijkheden voordat de verwerking zelfs maar begint:

Door het numerieke werk van een segmentatiemodel op dezelfde lijn te plaatsen, zouden deze taken rechtstreeks met elkaar concurreren. Een werknemer creëert een duidelijkere grens.

De op berichten gebaseerde grens

De redacteur en de medewerker delen geen gewone variabelen. Ze communiceren door berichten te sturen. Een vereenvoudigde stroom ziet er als volgt uit:

  1. De editor maakt of hergebruikt een werknemer.
  2. Het vraagt ​​de werknemer om de inferentieruntime en het model te initialiseren.
  3. Het bereidt beeldgegevens voor en verzendt een gevolgtrekkingsverzoek.
  4. De medewerker zet de gegevens om in de verwachte invoer van het model.
  5. De werknemer voert het model uit en produceert maskerwaarden.
  6. Het stuurt de masker- of resultaatgegevens terug.
  7. De editor stelt het voorbeeld samen en maakt verfijning of export mogelijk.

Berichten moeten voldoende context bevatten om een ​​antwoord aan het juiste verzoek te koppelen. Dit is van belang als een gebruiker een andere afbeelding kiest voordat de vorige taak is voltooid. De interface moet voorkomen dat een oud resultaat via een nieuwe bron wordt weergegeven.

Beeldgegevens kopiëren en overbrengen

Een klein sms-bericht sturen is goedkoop. Het verzenden van miljoenen pixelwaarden kan kostbaar zijn als de browser de volledige buffer moet kopiëren. Web-API’s kunnen in plaats daarvan het eigendom van bepaalde binaire buffers overdragen. Een overgedragen buffer komt beschikbaar voor de ontvanger zonder dat er een bruikbaar duplicaat aan de zenderzijde overblijft.

Die optimalisatie brengt een ontwerpbeperking met zich mee: na de overdracht kan de afzender niet dezelfde buffer blijven gebruiken alsof hij nog steeds eigenaar is van de gegevens. Een editor kan een afzonderlijke weergaveweergave behouden, een speciale gevolgtrekkingsbuffer maken of reconstrueren wat hij later nodig heeft.

Niet elke implementatie gebruikt overdracht op precies dezelfde plaatsen. De algemene les is dat het scheiden van threads er niet voor zorgt dat gegevensbewegingen verdwijnen. De afmetingen van afbeeldingen, de buffergrootte en het aantal conversies hebben nog steeds invloed op de latentie en het geheugen.

Wat Easy Background Remover in de werknemer stopt

Easy Background Remover gebruikt een Web Worker met een browser-inferentieruntime voor segmentatie op het apparaat. De zware automatische uitschakelstap levert een masker op. De editor geeft vervolgens het samengestelde resultaat weer en ondersteunt CPU-canvas-penseelverfijning.

Deze scheiding geeft mislukkingen een nuttiger grens. Als de werknemer niet kan initialiseren of crasht tijdens de verwerking, kan de interface een werknemergerelateerde fout rapporteren in plaats van te vertrouwen op een permanent bevroren tabblad als het enige signaal.

Het houdt ook de claim van lokale verwerking begrijpelijk. Het verzenden van pixels van een extensiepagina naar de eigen medewerker is communicatie binnen de browseromgeving, en niet een upload naar een externe knipsel-API. Tijdens de eerste sessie kan het herbruikbare modelitem afzonderlijk worden gedownload; zie Waarom bij de eerste uitvoering een model wordt gedownload.

Een werknemer voert de berekeningen niet onmiddellijk uit

Werknemers verbeteren het reactievermogen, niet de onbewerkte apparaatcapaciteiten. Het model verbruikt nog steeds CPU-, GPU- of andere runtimebronnen, afhankelijk van wat de browser kan bieden. Een grote invoer kan nog steeds langer duren en meer geheugen vereisen dan een kleine.

Er blijven verschillende limieten bestaan:

Het starten van vijf inferentiewerkers voor vijf afbeeldingen is niet automatisch vijf keer sneller. De arbeiders delen dezelfde machine. Parallelle taken kunnen concurreren om geheugenbandbreedte en uitvoeringsbronnen, terwijl elke modelinstantie zijn eigen geheugenkosten met zich mee kan brengen.

Voortgangsrapportage is coöperatief

Een medewerker kan statusberichten verzenden, maar weet niet automatisch welk voortgangspercentage als accuraat zal aanvoelen. Het downloaden van modellen, runtime-initialisatie, invoervoorbereiding, verwerking, maskerconversie en voorbeeldweergave zijn afzonderlijke fasen met verschillende timing.

Sommige fasen hebben meetbare byteaantallen. Een uitvoering van een enkel model mag alleen ‘begonnen’ en ‘voltooid’ weergeven. Een gelijkmatig percentage dat gelijkmatig vooruitgaat, kan daarom eerder cosmetisch zijn dan een nauwkeurige meting.

Nuttige voortgang De gebruikersinterface benoemt indien mogelijk de fase: model voorbereiden, afbeelding verwerken of resultaat bouwen. Het behandelt ook mislukkingen en annuleringen in plaats van een spinner zonder uitleg achter te laten.

Annulering is meer dan het verbergen van een spinner

Als de gebruiker een afbeelding sluit of opnieuw begint, kan de interface het uiteindelijke antwoord van het verouderde verzoek negeren. Het onmiddellijk stoppen van de onderliggende berekening vereist mogelijk extra ondersteuning van de runtime of het beëindigen en opnieuw aanmaken van de werker.

Het beëindigen van een werker is doorslaggevend, maar de geïnitialiseerde status wordt hierbij genegeerd. Bij de volgende taak moet het model mogelijk opnieuw worden geladen en geïnitialiseerd. Voor een korte operatie kan het als oud markeren van het resultaat goedkoper zijn dan alles afbreken.

De juiste keuze hangt af van de geheugendruk, de werkingsduur en de runtimemogelijkheden. Vanuit het perspectief van de gebruiker is de belangrijke regel dat oud werk de huidige bewerking niet mag overschrijven.

Fouten moeten ook de grens overschrijden

Een uitzondering binnen een worker wordt geen normale hoofdthreaduitzondering. De medewerker moet bruikbare fouten melden en de redacteur moet luisteren naar fouten op werkerniveau.

Een goede foutafhandeling onderscheidt in ieder geval:

Dit is beter uitvoerbaar dan een generiek ‘er is iets misgegaan’, vooral wanneer de eerste installatie en normale beeldverwerking verschillende oplossingen hebben.

De output van werknemers is nog steeds slechts een eerste masker

Thread-architectuur verbetert op zichzelf geen dubbelzinnige voorsprong. De medewerker kan een technisch geldig masker retourneren dat nog steeds bont, transparant materiaal, smalle bandjes of een gewenste schaduw mist. Dat zijn segmentatie- en intentievragen.

De taak van de redacteur wordt hervat na verwerking: schaal het masker in het werkende coördinatensysteem, stel een voorbeeld samen, laat de gebruiker het verfijnen en exporteer de huidige status. Maskerresolutie versus voorbeeldgrootte legt uit waarom deze coördinatensystemen niet met elkaar verward mogen worden.

Een beknopt mentaal model

Beschouw de werknemer als een lokale specialist achter een berichtenvenster:

Voor de weergave van de pixels zelf door het model gaat u verder met Wat een uitgesneden model op het apparaat ziet. Voor een compleet praktisch overzicht, zie Hoe lokale achtergrondverwijdering werkt.

Ontdek meer

Interessant