Com funciona Araluma

La resposta breu

Araluma fa servir una arquitectura híbrida: la majoria d’eines s’executen completament al vostre navegador sense cap pujada, i un grapat encaminen una sola sol·licitud de xarxa a través de la nostra pròpia infraestructura quan el navegador no pot igualar la qualitat, sempre amb un recurs invisible en el costat del client. Us diem en quin camí us trobeu, a cada eina i en aquesta pàgina.

La taula següent és representativa, no exhaustiva (el catàleg no para de créixer). Mostra un exemple de cada tipus de camí:

Eina d’exemple	On es fa la feina
Retall en cercle (només navegador)	100% al vostre navegador, Canvas API. Cap pujada, funciona fora de línia.
Previsualització de compressió (només navegador)	100% al vostre navegador, canvas.toBlob. Cap pujada. El control lliscant es manté instantani.
Baixada de compressió (toca el servidor)	Un viatge d’anada i tornada al nostre servei a api.araluma.com (sharp més libvips en un VPS a Alemanya), amb recurs al navegador.
Eliminació de Fons (toca el servidor)	Un viatge d’anada i tornada a un Cloudflare Worker que executa BiRefNet en GPU de xarxa, amb un recurs WebAssembly al vostre navegador.

Les eines de retallat, redimensionament, PDF i conversió de format (a part del camí de sortida AVIF) es troben en el costat només de navegador. La baixada de compressió, l’eliminació de fons, l’ampliació amb intel·ligència artificial i les conversions amb sortida AVIF es troben en el costat que toca el servidor, cadascuna amb un recurs local.

Podeu verificar les afirmacions de només navegador en uns 30 segons: obriu les DevTools, aneu al tauler Xarxa, esborreu el registre i després feu servir qualsevol eina de només navegador. Veureu zero sol·licituds que transportin els bytes de la vostra imatge fora de la pàgina. Per a les eines que toquen el servidor veureu exactament una pujada per operació, als punts finals amb nom propi de més amunt.

Per què híbrida

La majoria d’eines d’imatge en línia se situen en un extrem: puja-ho-tot-a-un-servidor (espereu viatges d’anada i tornada i l’operador es queda el vostre fitxer) o tot-al-navegador (pagueu en qualitat i velocitat en els passos de codificació i intel·ligència artificial). Cap dels dos extrems guanya a tot arreu.

Vam triar el costat del client allà on els navegadors ja són excel·lents. L’element <canvas> s’encarrega del retallat, la rotació, el redimensionament i la codificació de previsualització amb pèrdua en JPG o WebP, i els navegadors moderns descodifiquen cada format comú de manera nativa. Vam triar el costat del servidor només per als pocs passos en què el navegador encara perd de manera mesurable:

• Compressió, en la baixada final. El sharp més libvips del costat del servidor produeix fitxers un 10 a 15% més petits byte per byte que els codificadors del navegador a la mateixa qualitat visual, i exposa un ajust de velocitat i croma d’AVIF que el navegador no ofereix. El control lliscant i la previsualització continuen executant-se al vostre navegador perquè la iteració es mantingui instantània. Només el toc a «Baixa» passa pel nostre servei.
• Eliminació de fons amb intel·ligència artificial, en el camí per defecte. El model BiRefNet que executa la segmentació d’imatges de Cloudflare (la mateixa arquitectura que remove.bg) necessita una GPU real per acabar en un segon o dos. El recurs dins del navegador (ISNet mitjançant ONNX Runtime més WebAssembly) funciona, però triga molt més i produeix una retallada visiblement més basta en els cabells, el pèl i les vores fines.
• Ampliació amb intel·ligència artificial, en el camí per defecte. La superresolució al núvol recupera detall que un remostratge del costat del navegador no pot, amb un recurs al navegador quan el servei no és a l’abast.

El cost que acceptem per ser al costat del servidor en aquests camins és un viatge d’anada i tornada per operació. El cost que evitem mantenint-nos al costat del client a tot arreu és aquesta mateixa quota a les parts del flux de treball que iteren més de pressa.

La canonada, pas a pas

1. Seleccioneu un fitxer

A través del selector de fitxers, l’arrossegar i deixar anar o l’enganxar, el navegador lliura a la JavaScript un objecte File. La JavaScript llegeix els bytes amb FileReader o Blob.arrayBuffer(). En cap moment d’aquest pas el fitxer s’envia per la xarxa, sigui quina sigui l’eina que feu servir.

2. El navegador descodifica la imatge

Els navegadors moderns descodifiquen de manera nativa JPG, PNG, WebP, GIF i AVIF. Fem servir createImageBitmap() per convertir els bytes en brut en un bitmap amb què la GPU pot treballar, fora del fil principal. Per a HEIC en navegadors que no el descodifiquen de manera nativa, recorrem a un descodificador WebAssembly que s’executa localment al vostre navegador.

3. L’eina fa la seva feina, on els camins divergeixen

• Eines de només navegador (retallat, redimensionament, la previsualització i el control lliscant de compressió, l’assemblatge de PDF i la majoria de conversions de format). Aquestes s’executen com a transformacions de píxels del Canvas i recodificacions canvas.toBlob justament a la vostra màquina. El marc de retall interactiu fa servir Cropper.js. Res no surt de la pàgina.
• Baixada de compressió. Quan toqueu «Baixa», la imatge va una vegada a api.araluma.com (un servei de Fastify en un Hostinger VPS a Alemanya, Node més sharp i libvips, les mateixes biblioteques C que Squoosh fa servir en el seu camí de servidor). Es recodifica amb els paràmetres que heu establert a la previsualització, i els bytes tornen en flux. El servei manté una memòria cau aïllada per inquilí i adreçada per contingut (un resum dels bytes d’entrada més els paràmetres) de manera que tornar a baixar la mateixa imatge amb els mateixos ajustos reprodueix bytes emmagatzemats. Aquesta memòria cau no s’indexa per vós, la vostra IP ni el nom del fitxer. Si el servei no és a l’abast, l’eina recorre al blob de previsualització del navegador.
• Eliminació de fons, camí del núvol per defecte. La imatge es puja una vegada a un Cloudflare Worker, es desa en un dipòsit R2 privat, la processa la segmentació d’imatges de Cloudflare que executa el model BiRefNet en GPU de xarxa, i la retallada torna en flux. L’objecte desat s’elimina en una hora mitjançant una regla de cicle de vida d’R2, sigui quin sigui el resultat. Una foto típica acaba en un segon o dos. Límits diaris per IP i per mida de pujada mantenen el nivell gratuït sostenible.
• Eliminació de fons, recurs WebAssembly. Si el Worker no és a l’abast (la vostra xarxa cau, un tallafoc estricte el bloqueja, la quota diària és plena o el fitxer és massa gran per al límit del núvol), l’eina canvia en silenci al model ISNet executat localment mitjançant ONNX Runtime Web i WebAssembly. La primera execució descarrega el model i triga més, les execucions posteriors són més ràpides. Cap pujada en aquest camí, verificable a les DevTools.
• Ampliació amb intel·ligència artificial. El camí per defecte envia la imatge una vegada a un servei de superresolució al núvol i torna en flux el resultat engrandit, amb un recurs del costat del navegador si no es pot arribar al servei.

4. Baixeu el resultat

El bitmap de sortida es codifica en un Blob, s’embolcalla en una URL d’objecte i es lliura al diàleg estàndard de desament de fitxers del vostre navegador. El fitxer aterra al vostre disc.

Com verificar-ho vós mateix

Trieu el que preferiu:

Mètode 1. Observeu la pestanya Xarxa

1. Obriu Araluma en una pestanya nova i obriu les DevTools, després el tauler Xarxa.
2. Feu servir una eina de només navegador com el Retall en cercle o el control lliscant de previsualització de compressió. Veureu sol·licituds només per a HTML, CSS, JS i tipografies, més els mòduls WebAssembly rellevants en el primer ús. Cap sol·licitud no transportarà els bytes de la vostra imatge.
3. Ara feu servir una eina que toqui el servidor com la Baixada de compressió o l’Eliminació de Fons. Veureu exactament un POST que transporta la vostra imatge al punt final amb nom propi, i una resposta que torna amb el resultat. Passeu el cursor per sobre de qualsevol sol·licitud per llegir-ne la mida i el temps.

La columna «Initiator» us diu quin script ha activat cada sol·licitud, i la columna «Type» us diu què s’ha enviat. No n’amaguem cap.

Mètode 2. Feu servir les eines fora de línia

1. Carregueu qualsevol pàgina d’eina d’Araluma. Executeu l’Eliminació de Fons una vegada sobre una imatge petita perquè el model ISNet del navegador quedi a la memòria cau.
2. Obriu les DevTools, aneu a Xarxa i marqueu Fora de línia (o desconnecteu el Wi-Fi).
3. Torneu a carregar la pàgina. Els recursos estàtics estan a la memòria cau, així que encara es carrega.
4. Proveu les eines:
   • Les eines de només navegador continuen funcionant. Mai no van necessitar la xarxa.
   • La Baixada de compressió recorre al blob de previsualització del navegador (una codificació una mica menys eficient, però funcional).
   • L’Eliminació de Fons recorre al model ISNet WebAssembly i funciona sense cap sol·licitud sortint.

Si aquestes eines han funcionat fora de línia (algunes degradades, les de només navegador idèntiques), aleshores per definició cap servidor no ha vist la vostra imatge.

Què veiem, i què no

En els camins de només navegador, no veiem res sobre la vostra imatge. No hi ha cap sol·licitud per mirar, cap memòria cau per emmagatzemar-la, cap línia de registre per cercar amb grep.

En els camins que toquen el servidor:

• La Baixada de compressió veu els bytes de la imatge durant la codificació (normalment uns quants centenars de mil·lisegons), manté una entrada de memòria cau adreçada per contingut durant el seu TTL, i prou. La memòria cau no s’indexa per usuari, IP, nom de fitxer ni cap identificador que poguéssim fer servir per trobar les «vostres» imatges. No registrem el contingut de la imatge. El servei de codificació es comparteix entre els mateixos inquilins que la v1 servia abans de la migració, amb CORS per inquilí, límits de velocitat i URL canòniques signades amb HMAC.
• L’Eliminació de Fons veu la imatge durant la pujada de desament i la crida de segmentació (normalment un segon o dos), després de la qual la còpia desada s’elimina per la regla de cicle de vida d’R2. Mai no lliurem els vostres bytes a un proveïdor de model de tercers. El model BiRefNet s’executa dins de la pròpia infraestructura de Cloudflare, no en una API externa a l’estil de remove.bg, fal.ai o Replicate.
• L’Ampliació amb intel·ligència artificial veu la imatge durant la crida de superresolució, retorna el resultat i no reté res lligat a vós.

En tots els camins, el nostre proveïdor d’analítica (Cloudflare Web Analytics) registra dades agregades de visites de pàgina: URL, país, família de navegador, Core Web Vitals. Cap galeta, cap identificador persistent, res lligat a una persona.

Per a les eines que descarreguen un mòdul WebAssembly en el primer ús (el descodificador de HEIC, el model ISNet ONNX), el nostre proveïdor d’allotjament veu que algú ha recuperat el mòdul, de la mateixa manera que veu un fitxer CSS recuperat. El mòdul en si no porta cap informació sobre la vostra 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 pla amb «illes» de JavaScript millorades de manera progressiva només allà on viuen les eines interactives.
• CSS vanil·la amb propietats personalitzades, sense Tailwind, sense CSS-in-JS. Tot el sistema de disseny és un únic fitxer tokens.css.
• canvas.toBlob i <canvas>, la codificació de JPEG, PNG, WebP i AVIF per a les eines i les previsualitzacions del costat del navegador.
• Cropper.js, la capa d’interacció del rectangle de retall.
• ONNX Runtime Web, que executa el recurs ISNet WebAssembly per a l’Eliminació de Fons.
• Cloudflare allotja la compilació estàtica i la serveix des de la xarxa, i executa els Workers, l’R2 i la canonada de segmentació d’imatges (BiRefNet) darrere del camí per defecte de l’Eliminació de Fons.
• Fastify amb sharp i libvips sobre Node, el servei de baixada de Compressió a api.araluma.com, en un Hostinger VPS a Alemanya.
• Cloudflare Web Analytics, recomptes de visites de pàgina agregats i sense galetes.

Compatibilitat amb navegadors

Cada eina funciona a la versió actual i a l’anterior de Chrome, Firefox, Safari i Edge, en escriptori i en mòbil. El lloc fa servir la millora progressiva: on un navegador admet una API més nova (per exemple showSaveFilePicker o OffscreenCanvas), la fem servir, i on no l’admet, recorrem a l’equivalent més antic. No hi ha cap mur de «el vostre navegador no és compatible».

Els únics requisits durs són la JavaScript (per a qualsevol eina) i una connexió de xarxa (només quan feu servir un camí que toca el servidor, les eines de només navegador s’executen totalment fora de línia després de la primera càrrega de la pàgina).

Preguntes

Hi ha res que no hàgim cobert? Escriviu a support@araluma.com. Les preguntes tècniques són benvingudes.