Com funciona Araluma

La resposta breu

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

Eina	On es fa la feina
Circle Crop	100% al navegador, Canvas API. Sense pujada, funciona sense connexió.
Vista prèvia de Compress (slider + comparació de formats)	100% al navegador, canvas.toBlob. Sense pujada.
Descàrrega final de Compress	Una petició al nostre servei a api.araluma.com (Fastify + sharp + libvips en un VPS a Alemanya).
Remove Background	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.

És possible verificar les afirmacions del costat del client en uns 30 segons: obriu DevTools → Network, esborreu el registre i feu servir Circle Crop o el slider 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 dues eines que utilitzen servidor veureu exactament una pujada per operació, als endpoints indicats més amunt.

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ó 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/croma AVIF i a la sortida JPEG XL que el navegador no exposa. El slider 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, en el camí per defecte. El model BiRefNet que executa cf.image.segment de Cloudflare (la mateixa arquitectura que remove.bg) necessita una GPU real per acabar en 1-3 segons. L’alternativa al navegador (ISNet via ONNX Runtime + WebAssembly) funciona, tarda 20-40 segons en la primera execució i 2-10 segons després, i produeix un retall visualment més rudimentari en cabells, pelatge i vores fines.

El cost que s’accepta per ser al costat del servidor en aquests dos camins és una petició per operació. El cost que s’evita quedant-se al costat del client a tot arreu (Circle Crop, la vista prèvia de Compress) é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

• Circle Crop. Una transformació de píxels Canvas 2D amb un camí de retall circular. El bitmap es dibuixa en un <canvas> amb la rotació i el zoom triats, s’aplica el retall circular i l’interior del cercle es llegeix de tornada com a ImageData. Cropper.js gestiona la interacció del marc de retall. Completament al navegador.
• Compress — vista prèvia i slider. Recodifica JPG, PNG, WebP o AVIF usant canvas.toBlob perquè la vista prèvia costat a costat s’actualitzi en moure el slider de qualitat. Completament al navegador. Sense pujada encara.
• Compress — Descàrrega. En fer «Descarrega», la imatge s’envia una vegada a api.araluma.com (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 + paràmetres) limitada a 500 MB, de manera que tornar a descarregar la mateixa imatge amb els mateixos paràmetres reprodueix els bytes emmagatzemats a la memòria cau — 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 (araluma-bg-remover), s’emmagatzema temporalment en un bucket R2 privat (araluma-bg-temp), 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.
• Remove Background — alternativa WebAssembly. Si el Worker 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 de 5 MB al núvol), l’eina canvia de manera transparent al model ISNet que s’executa localment al navegador via ONNX Runtime Web amb WebAssembly. La primera execució descarrega el model d’uns ~80 MB i tarda 20-40 segons; les execucions posteriors triguen 2-10 segons. Sense pujada en aquest camí — 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 Araluma en una pestanya nova i obriu DevTools → Network.
2. Feu servir Circle Crop o el slider 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 Compress → Descarrega o Remove Background. Veureu exactament un POST a api.araluma.com (Compress) o al Worker de Remove Background, 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 Araluma. 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 cada eina:
   • Circle Crop i 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 quatre eines han funcionat sense connexió (una lleugerament degradada, tres 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:

• Compress Descarrega 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 veu la imatge durant la durada de la pujada temporal i la crida de segmentació (generalment 1-3 segons en total), després de la qual la còpia temporal és eliminada per la regla de cicle de vida de R2. No s’envien mai els bytes a cap proveïdor de models de tercers — 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 la vista prèvia de Compress i a tot Circle Crop.
• 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 descàrrega de Compress a api.araluma.com, 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 Compress Descarrega o el camí per defecte de Remove Background — els altres camins 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@araluma.com. Les preguntes tècniques són benvingudes.