क्रॉप

इमेज क्रॉप करें गोल क्रॉप करें

ऑप्टिमाइज़

इमेज कंप्रेस करें इमेज अपस्केल करें बैकग्राउंड हटाएं

बदलाव

इमेज रीसाइज़ करें

कन्वर्ट

अन्य

JPG को PDF में बदलें

Araluma कैसे काम करता है

हर टूल क्या करता है, कहाँ चलता है और आप इसे स्वयं कैसे सत्यापित कर सकते हैं, तकनीकी विवरण।

संक्षिप्त उत्तर

Araluma एक hybrid architecture का उपयोग करता है: ज़्यादातर टूल्स पूरी तरह आपके browser में, बिना किसी upload के चलते हैं, और कुछ टूल्स तब एक ही network request को हमारे अपने infrastructure से होकर भेजते हैं जब browser गुणवत्ता की बराबरी नहीं कर पाता, हमेशा एक अदृश्य client-side fallback के साथ। हम आपको हर टूल में और इस page पर बताते हैं कि आप किस path पर हैं।

नीचे दी गई table प्रतिनिधि है, संपूर्ण नहीं (कैटलॉग बढ़ता ही रहता है)। यह हर तरह के path का एक-एक उदाहरण दिखाती है:

उदाहरण टूलकाम कहाँ होता है
Circle Crop (browser-only)100% आपके browser में, Canvas API। कोई upload नहीं, offline काम करता है।
Compress preview (browser-only)100% आपके browser में, canvas.toBlob। कोई upload नहीं। slider तुरंत चलता है।
Compress download (server-touching)api.araluma.com पर हमारी service को एक round-trip (जर्मनी में एक VPS पर sharp और libvips), एक browser fallback के साथ।
Remove Background (server-touching)एक Cloudflare Worker को एक round-trip जो edge GPUs पर BiRefNet चलाता है, आपके browser में एक WebAssembly fallback के साथ।

cropping, resizing, PDF, और format-conversion टूल्स (AVIF-output path को छोड़कर) browser-only तरफ़ हैं। Compression download, background removal, AI upscaling, और AVIF-output conversions server-touching तरफ़ हैं, हर एक एक local fallback के साथ।

आप browser-only दावों को लगभग 30 सेकंड में सत्यापित कर सकते हैं: DevTools खोलें, Network panel पर जाएँ, log साफ़ करें, फिर किसी भी browser-only टूल का उपयोग करें। आपको आपकी image के bytes ले जाने वाली शून्य requests page से बाहर जाती दिखेंगी। server-touching टूल्स के लिए आपको प्रति operation ठीक एक upload दिखेगा, ऊपर बताए गए named endpoints पर।

Hybrid क्यों

अधिकांश online image टूल्स किसी एक चरम पर होते हैं: सब-कुछ-server-पर-upload (आप round-trips का इंतज़ार करते हैं और operator आपकी file रखता है), या all-in-browser (आप encode और AI चरणों में गुणवत्ता और गति का मूल्य चुकाते हैं)। कोई भी चरम हर जगह नहीं जीतता।

हमने client-side वहाँ चुना जहाँ browsers पहले से उत्कृष्ट हैं। <canvas> element cropping, rotating, resizing, और JPG या WebP में lossy preview encode संभालता है, और आधुनिक browsers हर आम format को natively decode करते हैं। हमने server-side सिर्फ़ उन कुछ चरणों के लिए चुना जहाँ browser अब भी मापने योग्य रूप से पिछड़ता है:

  • Compression, final download पर। server-side sharp और libvips समान visual quality पर browser encoders की तुलना में byte-for-byte 10 से 15% छोटी files बनाते हैं, और AVIF speed तथा chroma tuning देते हैं जो browser नहीं देता। slider और preview अब भी आपके browser में चलते हैं ताकि iteration तुरंत रहे। केवल “Download” tap हमारी service से होकर जाता है।
  • AI background removal, default path पर। Cloudflare की image segmentation जो BiRefNet model चलाती है (remove.bg जैसी architecture) उसे एक या दो सेकंड में पूरा करने के लिए एक असली GPU चाहिए। in-browser fallback (ONNX Runtime और WebAssembly के ज़रिए ISNet) काम तो करता है, पर कहीं अधिक समय लेता है और बाल, fur तथा महीन किनारों पर दिखने में खुरदुरा cutout देता है।
  • AI upscaling, default path पर। cloud super-resolution उस detail को वापस लाती है जिसे browser-side resample नहीं ला सकता, और जब service न पहुँचे तब एक browser fallback के साथ।

इन paths पर server-side होने की जो कीमत हम स्वीकार करते हैं वह है प्रति operation एक round-trip। बाक़ी हर जगह client-side बने रहकर हम जो कीमत बचाते हैं वह उन्हीं workflow भागों पर वही शुल्क है जो सबसे तेज़ी से iterate होते हैं।

Pipeline, चरण दर चरण

1. आप एक file चुनते हैं

file picker, drag-and-drop, या paste के ज़रिए, browser JavaScript को एक File object सौंपता है। JavaScript FileReader या Blob.arrayBuffer() का उपयोग करके bytes पढ़ता है। इस चरण में किसी भी समय file network पर नहीं भेजी जाती, चाहे आप कोई भी टूल उपयोग कर रहे हों।

2. browser image को decode करता है

आधुनिक browsers JPG, PNG, WebP, GIF, और AVIF को natively decode करते हैं। हम raw bytes को एक ऐसे bitmap में बदलने के लिए createImageBitmap() का उपयोग करते हैं जिस पर GPU काम कर सके, main thread से अलग। ऐसे browsers के लिए जो HEIC को natively decode नहीं करते, हम एक WebAssembly decoder पर fallback करते हैं जो आपके browser में locally चलता है।

3. टूल अपना काम करता है, यहाँ paths अलग होते हैं

  • Browser-only टूल्स (cropping, resizing, compression preview और slider, PDF assembly, और अधिकांश format conversions)। ये Canvas pixel transforms और canvas.toBlob re-encodes के रूप में आपकी मशीन पर ही चलते हैं। interactive crop frame Cropper.js का उपयोग करता है। page से कुछ बाहर नहीं जाता।
  • Compression download। जब आप “Download” tap करते हैं, image एक बार api.araluma.com को जाती है (जर्मनी में एक Hostinger VPS पर एक Fastify service, Node के साथ sharp और libvips, वही C libraries जो Squoosh अपने server path पर उपयोग करता है)। इसे उन्हीं parameters के साथ re-encode किया जाता है जो आपने preview में सेट किए, और bytes वापस stream होती हैं। service एक tenant-isolated, content-addressed cache (input bytes और parameters का hash) रखती है ताकि समान settings के साथ वही image फिर download करने पर cached bytes दोबारा चलें। वह cache आपके द्वारा, आपके IP, या filename से index नहीं किया जाता। यदि service अनुपलब्ध हो, तो टूल in-browser preview blob पर fallback करता है।
  • Background removal, default cloud path। image एक बार एक Cloudflare Worker पर upload होती है, एक private R2 bucket में stage होती है, Cloudflare की image segmentation द्वारा process होती है जो edge GPUs पर BiRefNet model चलाती है, और cutout वापस stream होता है। staged object को परिणाम चाहे जो हो, एक R2 lifecycle rule द्वारा एक घंटे के भीतर delete कर दिया जाता है। एक सामान्य photo एक या दो सेकंड में पूरी होती है। दैनिक per-IP और upload-size caps free tier को टिकाऊ रखते हैं।
  • Background removal, WebAssembly fallback। यदि Worker अनुपलब्ध है (आपका network गिर जाता है, एक सख्त firewall इसे रोकता है, दैनिक quota पूरा है, या file cloud cap के लिए बहुत बड़ी है), तो टूल चुपचाप ISNet model पर switch कर जाता है जो ONNX Runtime Web और WebAssembly के ज़रिए locally चलता है। पहली बार model download होता है और अधिक समय लेता है, बाद के बार तेज़ होते हैं। इस path पर कोई upload नहीं, DevTools में सत्यापन योग्य।
  • AI upscaling। default path image को एक बार एक cloud super-resolution service को भेजता है और बड़ा किया गया परिणाम वापस stream करता है, और जब service न पहुँचे तब एक browser-side fallback के साथ।

4. आप परिणाम download करते हैं

output bitmap एक Blob में encode किया जाता है, एक object URL में लपेटा जाता है, और आपके browser के standard file-save dialog को सौंपा जाता है। file आपकी disk पर आ जाती है।

इसे खुद सत्यापित कैसे करें

जो आपको पसंद हो वह चुनें:

तरीका 1. Network tab देखें

  1. एक नए tab में Araluma खोलें और DevTools, फिर Network panel खोलें।
  2. Circle Crop या Compress preview slider जैसे किसी browser-only टूल का उपयोग करें। आपको केवल HTML, CSS, JS, और fonts की requests दिखेंगी, साथ ही पहले उपयोग पर संबंधित WebAssembly modules। कोई request आपकी image के bytes नहीं ले जाएगी।
  3. अब Compress Download या Remove Background जैसे किसी server-touching टूल का उपयोग करें। आपको आपकी image को named endpoint पर ले जाता हुआ ठीक एक POST दिखेगा, और परिणाम के साथ एक response वापस आता हुआ। आकार और timing पढ़ने के लिए किसी भी request पर hover करें।

“Initiator” column बताता है कि किस script ने प्रत्येक request को trigger किया, और “Type” column बताता है कि क्या भेजा गया। हम दोनों में से कुछ नहीं छिपाते।

तरीका 2. टूल्स offline उपयोग करें

  1. कोई भी Araluma टूल page लोड करें। एक छोटी image पर Remove Background एक बार चलाएँ ताकि in-browser ISNet model cache हो जाए।
  2. DevTools खोलें, Network पर जाएँ, और Offline टिक करें (या Wi-Fi बंद करें)।
  3. page reload करें। static assets cached हैं, इसलिए यह फिर भी load होता है।
  4. टूल्स आज़माएँ:
    • Browser-only टूल्स काम करते रहते हैं। उन्हें कभी network की ज़रूरत नहीं थी।
    • Compress Download in-browser preview blob पर fallback करता है (थोड़ा कम कुशल encode, पर कार्यात्मक)।
    • Remove Background ISNet WebAssembly model पर fallback करता है और बिना किसी outbound request के काम करता है।

यदि वे टूल्स offline काम किए (कुछ घटिया स्तर पर, browser-only वाले समान), तो परिभाषा के अनुसार किसी server ने आपकी image नहीं देखी।

हम क्या देखते हैं, और क्या नहीं

browser-only paths पर, हम आपकी image के बारे में कुछ नहीं देखते। देखने के लिए कोई request नहीं, store करने के लिए कोई cache नहीं, grep करने के लिए कोई log line नहीं।

server-touching paths पर:

  • Compress Download encode की अवधि के लिए image bytes देखता है (आमतौर पर कुछ सौ milliseconds), अपने TTL के लिए एक content-addressed cache entry रखता है, और बस। cache user, IP, filename, या किसी ऐसे identifier से index नहीं किया जाता जिससे हम “आपकी” images ढूँढ सकें। हम image content log नहीं करते। encode service उन्हीं tenants के बीच साझा है जो cutover से पहले v1 serve करती थी, per-tenant CORS, rate limits, और HMAC-signed canonical URLs के साथ।
  • Remove Background staging upload और segmentation call की अवधि के लिए image देखता है (आमतौर पर एक या दो सेकंड), जिसके बाद staged copy R2 lifecycle rule द्वारा delete कर दी जाती है। हम आपके bytes कभी किसी third-party model provider को नहीं सौंपते। BiRefNet model Cloudflare के अपने infrastructure के अंदर चलता है, किसी बाहरी remove.bg, fal.ai, या Replicate-style API पर नहीं।
  • AI upscaling super-resolution call की अवधि के लिए image देखता है, परिणाम लौटाता है, और आपसे जुड़ा कुछ भी नहीं रखता।

हर path पर, हमारा analytics provider (Cloudflare Web Analytics) aggregate page-view data रिकॉर्ड करता है: URL, देश, browser family, Core Web Vitals। कोई cookies नहीं, कोई persistent identifiers नहीं, किसी व्यक्ति से जुड़ा कुछ नहीं।

ऐसे टूल्स के लिए जो पहले उपयोग पर एक WebAssembly module download करते हैं (HEIC decoder, ISNet ONNX model), हमारा hosting provider देखता है कि किसी ने module fetch किया, उसी तरह जैसे वह एक CSS file fetch होते देखता है। module स्वयं आपकी image के बारे में कोई जानकारी नहीं रखता।

पूरी data inventory हमारी privacy policy में है।

technology stack

जिज्ञासु लोगों के लिए:

  • Astro, static site generator। हर page plain HTML के रूप में आता है, progressively-enhanced JavaScript “islands” केवल वहाँ जहाँ interactive टूल्स रहते हैं।
  • Vanilla CSS with custom properties, कोई Tailwind नहीं, कोई CSS-in-JS नहीं। पूरा design system एक ही tokens.css file है।
  • canvas.toBlob और <canvas>, browser-side टूल्स और previews के लिए JPEG, PNG, WebP, और AVIF encoding।
  • Cropper.js, crop-rectangle interaction layer।
  • ONNX Runtime Web, जो Remove Background के लिए ISNet WebAssembly fallback चलाता है।
  • Cloudflare static build को host करता है और इसे edge से serve करता है, और default Remove Background path के पीछे Workers, R2, और image-segmentation pipeline (BiRefNet) चलाता है।
  • Fastify with sharp and libvips on Node, api.araluma.com पर Compress download service, जर्मनी में एक Hostinger VPS पर।
  • Cloudflare Web Analytics, aggregate, cookie-less page-view counts।

browser समर्थन

हर टूल Chrome, Firefox, Safari, और Edge के मौजूदा और पिछले version पर, desktop और mobile पर काम करता है। साइट progressive enhancement का उपयोग करती है: जहाँ कोई browser नया API support करता है (उदाहरण के लिए showSaveFilePicker या OffscreenCanvas), हम उसे उपयोग करते हैं, और जहाँ नहीं करता, हम पुराने समकक्ष पर fallback करते हैं। “आपका browser समर्थित नहीं है” जैसी कोई दीवार नहीं है।

एकमात्र कठोर शर्तें JavaScript (किसी भी टूल के लिए) और एक network connection (केवल किसी server-touching path का उपयोग करते समय, browser-only टूल्स पहले page load के बाद पूरी तरह offline चलते हैं) हैं।

प्रश्न

कुछ जो हमने कवर नहीं किया? ईमेल करें support@araluma.com। तकनीकी प्रश्न स्वागत योग्य हैं।