Com funciona RoundCut

Detall tècnic de què fa cada eina, on s'executa i com podeu verificar-ho vosaltres mateixos.

La resposta breu

RoundCut fa servir una arquitectura híbrida: la majoria d’eines s’executen completament al vostre navegador sense cap pujada, i una grapada encaminen una única petició de xarxa a través de la nostra pròpia infraestructura quan el navegador no pot igualar la qualitat, sempre amb una alternativa invisible al costat del client. En cada eina i en aquesta pàgina s’indica quin camí s’utilitza en cada moment.

La taula següent és representativa, no exhaustiva (regularment s’incorporen noves eines). Mostra un exemple de cada tipus de camí:

Eina d’exempleOn es fa la feina
Circle Crop (només al navegador)100% al navegador, Canvas API. Sense pujada, funciona sense connexió.
Vista prèvia de Compress (només al navegador)100% al navegador, canvas.toBlob. Sense pujada. El control lliscant és instantani.
Descàrrega final de Compress (passa pel servidor)Una petició al nostre servei a api.roundcut.com.br (Fastify + sharp + libvips en un VPS a Alemanya), amb una alternativa al navegador.
Remove Background (passa pel servidor)Una petició a un Cloudflare Worker que executa BiRefNet a les GPU d’edge de Cloudflare, amb una alternativa WebAssembly al navegador quan el núvol no és accessible.

El retall, el redimensionament, la conversió de format (excepte la codificació AVIF) i la vista prèvia de Compress s’executen tots completament al vostre navegador. L’eliminació de fons, la descàrrega de Compress, l’ampliació amb IA, la codificació AVIF i el PDF amb diverses imatges encaminen cadascun una única petició i recorren al navegador quan el núvol no és accessible.

És possible verificar les afirmacions del costat del client en uns 30 segons: obriu DevTools → Network, esborreu el registre i feu servir una eina només de navegador com Circle Crop o el control lliscant de vista prèvia de Compress, no veureu cap petició que transporti els bytes de la imatge fora de la pàgina. Per a les eines que passen pel servidor veureu exactament una pujada per operació, als endpoints indicats.

Per què híbrid

La majoria d’eines d’imatge en línia se situen en un extrem: o pugen-ho-tot-a-un-servidor (s’espera el viatge d’anada i tornada i l’operador conserva el fitxer), o tot-al-navegador (es paga en qualitat i velocitat a les etapes de codificació i IA). Cap extrem guanya a tot arreu.

S’ha optat pel costat del client on els navegadors ja excel·leixen, l’element <canvas> s’ocupa del retall, la rotació, el redimensionament i la codificació de la vista prèvia amb pèrdua en JPG/WebP, i pel costat del servidor on el navegador perd de manera mesurable:

  • Compressió d’imatges, en la descàrrega final. sharp + libvips 8.17 al servidor produeix fitxers un 10-15% més petits byte a byte que els codificadors del navegador amb la mateixa qualitat visual, i ofereix accés a l’ajust de velocitat i croma d’AVIF i a la sortida JPEG XL que el navegador no exposa. El control lliscant i la vista prèvia continuen executant-se al navegador perquè la iteració segueixi sent instantània, només l’acció «Descarrega» passa pel nostre servei.
  • Eliminació de fons per IA i ampliació per IA, en el camí per defecte. Els models (BiRefNet per a la segmentació, superresolució per a l’ampliació) necessiten una GPU real per acabar en segons. Les alternatives al navegador funcionen, però són més lentes i produeixen un resultat visualment més rudimentari en cabells, pelatge i vores fines.
  • Codificació AVIF, en la conversió. El codificador AVIF al navegador és lent en alguns dispositius, de manera que la sortida AVIF encamina una petició al Worker de compressió, amb una codificació al fil principal del navegador com a alternativa.

El cost que s’accepta per ser al costat del servidor en aquests camins és una petició per operació. El cost que s’evita quedant-se al costat del client a tot arreu és la petició als trams del flux de treball que iterem més ràpid.

La canonada, pas a pas

1. Seleccioneu un fitxer

A través del selector de fitxers, arrossegant-lo o enganxant-lo, el navegador passa a JavaScript un objecte File. JavaScript llegeix els bytes usant FileReader o Blob.arrayBuffer(). En cap moment d’aquest pas s’envia el fitxer per la xarxa, independentment de quina eina s’estigui utilitzant.

2. El navegador descodifica la imatge

Els navegadors moderns descodifiquen nativament JPG, PNG, WebP, GIF i AVIF. Es fa servir createImageBitmap() per convertir els bytes bruts en un bitmap amb el qual la GPU pot treballar, fora del fil principal. Per a HEIC en navegadors que no el descodifiquen nativament, es recorre a un descodificador WebAssembly que s’executa localment al navegador.

3. L’eina fa la seva feina, aquí és on els camins divergeixen

  • Eines només de navegador (retall, redimensionament, conversió de format a PNG/JPEG/WebP, la vista prèvia de Compress). Una transformació de píxels Canvas 2D o un còdec WebAssembly recodifica el bitmap localment. El resultat queda llest sense cap pujada. Cropper.js gestiona el marc de retall interactiu per a les eines de retall, i canvas.toBlob s’ocupa de la recodificació de la vista prèvia. Completament al navegador.
  • Compress, descàrrega. En fer «Descarrega», la imatge s’envia una vegada a api.roundcut.com.br (un servei Fastify en un VPS a Alemanya operat per Hostinger, Node 24 + sharp 0.34 + libvips 8.17, les mateixes biblioteques C que fa servir Squoosh en el seu camí de servidor). Es recodifica amb els mateixos paràmetres configurats a la vista prèvia, i els bytes es transmeten de tornada al navegador. El servei manté una memòria cau aïllada per tenant i adreçada per contingut (un hash dels bytes d’entrada i els paràmetres) limitada a 500 MB, de manera que tornar a descarregar la mateixa imatge amb els mateixos paràmetres reprodueix els bytes emmagatzemats, la memòria cau no s’indexa per usuari, IP ni nom de fitxer. Si el servei no és accessible, l’eina recorre al blob de vista prèvia al navegador.
  • Remove Background, camí al núvol per defecte. La imatge es puja una vegada a un Cloudflare Worker, s’emmagatzema temporalment en un bucket R2 privat, es processa per la transformació cf.image.segment de Cloudflare que executa el model BiRefNet a les GPU d’edge de Cloudflare, i el retall es transmet de tornada. L’objecte R2 temporal s’elimina en el termini d’una hora per una regla de cicle de vida de R2, independentment del resultat. Una foto típica finalitza en 1-3 segons. Els límits diaris per IP i de pujada de 5 MB mantenen el nivell gratuït sostenible.
  • Altres eines amb suport al núvol (ampliació amb IA, codificació AVIF, PDF amb diverses imatges) segueixen la mateixa forma: una petició a infraestructura amb nom (una API d’imatge al núvol per a la superresolució, el Worker de compressió per a la codificació AVIF, el nostre servei VPS per al PDF amb diverses imatges), el resultat es transmet de tornada, i una alternativa transparent al navegador si aquesta petició falla.
  • Alternativa WebAssembly. Si el camí al núvol corresponent no és accessible (la xarxa cau, s’està darrere d’un tallafoc estricte, la quota diària s’ha esgotat o el fitxer supera el límit del núvol), l’eina canvia de manera transparent a un model o còdec local que s’executa al navegador, per exemple el model d’eliminació de fons ISNet via ONNX Runtime Web amb WebAssembly. La primera execució descarrega el model i és més lenta, les execucions posteriors són més ràpides. Sense pujada en aquests camins alternatius, es pot verificar a DevTools.

4. Descarregueu el resultat

El bitmap de sortida es codifica en un Blob, s’embolica en una object URL i s’ofereix al diàleg estàndard de guardat de fitxers del navegador. El fitxer apareix al disc.

Com verificar-ho

Trieu el mètode que preferiu:

Mètode 1. Observeu la pestanya Network

  1. Obriu RoundCut en una pestanya nova i obriu DevTools → Network.
  2. Feu servir una eina només de navegador, Circle Crop o el control lliscant de vista prèvia de Compress. Veureu peticions d’HTML/CSS/JS/tipografies únicament, a més dels mòduls WebAssembly corresponents en el primer ús. Cap petició transportarà els bytes de la imatge.
  3. Ara feu servir una eina que passa pel servidor, Compress → Descarrega o Remove Background. Veureu exactament un POST que transporta la imatge, i una resposta que torna amb el resultat. Passeu el cursor per sobre de qualsevol petició per veure la mida i el temps.

La columna «Initiator» indica quin script ha iniciat cada petició, i la columna «Type» indica el que s’ha enviat. No s’amaga cap de les dues.

Mètode 2. Feu servir les eines sense connexió

  1. Carregueu qualsevol pàgina d’eina de RoundCut. Useu Remove Background una vegada en una imatge petita perquè el model ISNet al navegador quedi a la memòria cau.
  2. Obriu DevTools → Network → marqueu Offline (o apagueu el Wi-Fi).
  3. Recarregueu la pàgina, els recursos estàtics estan a la memòria cau, de manera que continua carregant-se.
  4. Proveu les eines:
    • Les eines només de navegador (Circle Crop, redimensionament, la vista prèvia de Compress) continuen funcionant, mai no han necessitat la xarxa.
    • Compress Descarrega recorre al blob de vista prèvia al navegador (codificació lleugerament menys eficient, però funcional).
    • Remove Background recorre al model WebAssembly ISNet i funciona sense cap petició sortint.

Si les eines han funcionat sense connexió (les que tenen suport al núvol lleugerament degradades, les només de navegador idèntiques), per definició cap servidor ha vist la imatge.

Què veiem, i què no veiem

En els camins del costat del client, no es veu res sobre la imatge. No hi ha cap petició a analitzar, cap memòria cau on emmagatzemar-la, cap línia de registre on cercar-la.

En els camins del costat del servidor:

  • El servei de compressió i PDF veu els bytes de la imatge durant la durada de la codificació (generalment uns centenars de mil·lisegons), manté una entrada de memòria cau adreçada per contingut durant el TTL de la memòria cau, i res més. La memòria cau no s’indexa per usuari, IP, nom de fitxer ni cap identificador que es pugués fer servir per trobar les vostres imatges. No es registra el contingut de les imatges. El servei de codificació és compartit entre els mateixos dos tenants que servia la versió 1 abans de la migració, amb CORS, límits de velocitat i URL canòniques signades amb HMAC per tenant.
  • Remove Background i els altres camins d’IA veuen la imatge durant la durada de la pujada temporal i la crida del model (generalment uns quants segons), després de la qual la còpia temporal és eliminada per una regla de cicle de vida de R2. El model BiRefNet s’executa dins de la pròpia infraestructura de Cloudflare, no en una API externa estil remove.bg / fal.ai / Replicate.

En tots els camins, el nostre proveïdor d’analítiques (Cloudflare Web Analytics) registra dades agregades de visualitzacions de pàgina. URL, país, família de navegador, Core Web Vitals. Sense galetes, sense identificadors persistents, res vinculat a una persona.

Per a les eines que descarreguen un mòdul WebAssembly en el primer ús (el descodificador HEIC, el model ONNX ISNet), el nostre proveïdor d’allotjament veu que algú ha demanat el mòdul, de la mateixa manera que veu que algú ha demanat el fitxer CSS. El mòdul en si no conté cap informació sobre la imatge.

L’inventari complet de dades és a la nostra política de privadesa.

La pila tecnològica

Per als curiosos:

  • Astro, el generador de llocs estàtics. Cada pàgina s’envia com a HTML simple amb «illes» JavaScript millorades progressivament només on viuen les eines interactives.
  • CSS vanilla amb propietats personalitzades, sense Tailwind, sense CSS-in-JS. El sistema de disseny complet és un únic fitxer tokens.css.
  • canvas.toBlob / <canvas>, codificació JPEG, PNG, WebP, AVIF (compatible amb el navegador) a les eines només de navegador, i tota la feina de retall i redimensionament.
  • Cropper.js, la capa d’interacció del rectangle de retall.
  • ONNX Runtime Web, executa l’alternativa WebAssembly ISNet per a Remove Background.
  • Cloudflare Pages, allotja la compilació estàtica i la serveix des de l’edge.
  • Cloudflare Workers + R2 + cf.image.segment (BiRefNet), la canonada per defecte de Remove Background.
  • Fastify + sharp 0.34 + libvips 8.17 en Node 24, el servei de compressió i PDF a api.roundcut.com.br, en un VPS de Hostinger a Alemanya.
  • Cloudflare Web Analytics, recompte de visualitzacions de pàgina agregat, sense galetes.

Compatibilitat amb navegadors

Totes les eines funcionen a la versió actual i l’anterior de Chrome, Firefox, Safari i Edge, escriptori i mòbil. El lloc fa servir la millora progressiva: on un navegador admet una API més nova (p. ex. showSaveFilePicker, OffscreenCanvas), es fa servir, on no, es recorre a l’equivalent antic. No hi ha cap barrera «el teu navegador no és compatible».

Els únics requisits imprescindibles són JavaScript (per a qualsevol eina) i una connexió de xarxa (només en fer servir una eina amb suport al núvol en el seu camí per defecte, les eines només de navegador funcionen completament sense connexió després de la primera càrrega de pàgina).

Preguntes

Alguna cosa que no hem cobert? Envieu un correu electrònic a support@roundcut.app. Les preguntes tècniques són benvingudes.