Araluma ทำงานอย่างไร

คำตอบสั้น ๆ

Araluma ใช้ สถาปัตยกรรมแบบผสม: เครื่องมือส่วนใหญ่ทำงานทั้งหมดในเบราว์เซอร์ ของคุณโดยไม่มีการอัปโหลด และมีไม่กี่ตัวที่ส่งคำขอเครือข่ายครั้งเดียวผ่าน โครงสร้างพื้นฐานของเราเองเมื่อเบราว์เซอร์ไม่สามารถเทียบคุณภาพได้ โดยมีเส้นทาง สำรองฝั่งไคลเอนต์ที่มองไม่เห็นเสมอ เราบอกคุณว่าคุณกำลังอยู่บนเส้นทางใด ทั้งในแต่ละเครื่องมือและในหน้านี้

ตารางด้านล่างเป็น ตัวแทน ไม่ใช่รายการที่ครบถ้วน (ชุดเครื่องมือยังเติบโต อยู่เรื่อย ๆ) โดยแสดงตัวอย่างหนึ่งของเส้นทางแต่ละประเภท:

เครื่องมือตัวอย่าง	งานเกิดขึ้นที่ใด
Circle Crop (เบราว์เซอร์เท่านั้น)	100% ในเบราว์เซอร์ของคุณ ผ่าน Canvas API ไม่มีการอัปโหลด ใช้งานออฟไลน์ได้
Compress ตัวอย่าง (เบราว์เซอร์เท่านั้น)	100% ในเบราว์เซอร์ของคุณ ผ่าน canvas.toBlob ไม่มีการอัปโหลด แถบเลื่อนตอบสนองทันที
Compress ดาวน์โหลด (สัมผัสเซิร์ฟเวอร์)	ส่งคำขอไปกลับครั้งเดียวไปยังบริการของเราที่ api.araluma.com (sharp บวก libvips บน VPS ในเยอรมนี) พร้อมเส้นทางสำรองในเบราว์เซอร์
Remove Background (สัมผัสเซิร์ฟเวอร์)	ส่งคำขอไปกลับครั้งเดียวไปยัง Cloudflare Worker ที่รัน BiRefNet บน GPU ขอบ พร้อมเส้นทางสำรอง WebAssembly ในเบราว์เซอร์ของคุณ

เครื่องมือครอบตัด ปรับขนาด PDF และการแปลงฟอร์แมต (ยกเว้นเส้นทางที่ส่งออก เป็น AVIF) อยู่ฝั่งเบราว์เซอร์เท่านั้น การดาวน์โหลดบีบอัด การลบพื้นหลัง การขยายด้วย AI และการแปลงที่ส่งออกเป็น AVIF อยู่ฝั่งสัมผัสเซิร์ฟเวอร์ แต่ละอย่างมีเส้นทางสำรองในเครื่อง

คุณสามารถยืนยันข้ออ้างฝั่งเบราว์เซอร์เท่านั้นได้ในราว 30 วินาที: เปิด DevTools ไปที่แผง Network ล้างล็อก แล้วใช้เครื่องมือฝั่งเบราว์เซอร์เท่านั้นตัวใดก็ได้ คุณจะเห็นว่าไม่มีคำขอใดที่นำไบต์รูปภาพของคุณออกจากหน้า สำหรับเครื่องมือ ฝั่งสัมผัสเซิร์ฟเวอร์ คุณจะเห็นการอัปโหลดเพียงครั้งเดียวต่อการดำเนินการ ไปยัง endpoint ที่ระบุชื่อไว้ข้างต้น

ทำไมจึงเป็นแบบผสม

เครื่องมือรูปภาพออนไลน์ส่วนใหญ่อยู่ที่ปลายสุดข้างใดข้างหนึ่ง: อัปโหลดทุกอย่าง ไปยังเซิร์ฟเวอร์ (คุณต้องรอการเดินทางไปกลับและผู้ดำเนินการเก็บไฟล์ของคุณ) หรือทั้งหมดในเบราว์เซอร์ (คุณจ่ายด้วยคุณภาพและความเร็วในขั้นตอนการเข้ารหัส และ AI) ไม่มีปลายสุดใดชนะในทุกที่

เราเลือกฝั่งไคลเอนต์ในที่ที่เบราว์เซอร์ทำได้ดีอยู่แล้ว องค์ประกอบ <canvas> จัดการการครอบตัด การหมุน การปรับขนาด และการเข้ารหัสตัวอย่างแบบสูญเสียใน JPG หรือ WebP และเบราว์เซอร์สมัยใหม่ถอดรหัสทุกฟอร์แมตทั่วไปได้โดยกำเนิด เราเลือกฝั่งเซิร์ฟเวอร์เฉพาะไม่กี่ขั้นตอนที่เบราว์เซอร์ยังด้อยกว่าอย่างวัดได้:

• การบีบอัด ในการดาวน์โหลดขั้นสุดท้าย sharp บวก libvips ฝั่งเซิร์ฟเวอร์ผลิตไฟล์ที่ เล็กกว่า 10 ถึง 15% แบบไบต์ต่อไบต์ เมื่อเทียบกับตัวเข้ารหัสของเบราว์เซอร์ที่คุณภาพภาพเดียวกัน และเปิดการปรับแต่งความเร็วและโครมาของ AVIF ที่เบราว์เซอร์ไม่ให้ แถบเลื่อนและตัวอย่างยังคงทำงานในเบราว์เซอร์ของคุณเพื่อให้การปรับแต่งทันใจ มีเพียงการแตะ “ดาวน์โหลด” เท่านั้นที่ผ่านบริการของเรา
• การลบพื้นหลังด้วย AI บนเส้นทางเริ่มต้น โมเดล BiRefNet ที่การแบ่งส่วนภาพของ Cloudflare รัน (สถาปัตยกรรมเดียวกับ remove.bg) ต้องใช้ GPU จริงเพื่อให้เสร็จในหนึ่งถึงสองวินาที เส้นทางสำรองในเบราว์เซอร์ (ISNet ผ่าน ONNX Runtime บวก WebAssembly) ทำงานได้ แต่ใช้เวลานานกว่ามาก และให้ผลการตัดออกที่หยาบกว่าอย่างเห็นได้ชัดในส่วนเส้นผม ขนสัตว์ และขอบที่ละเอียด
• การขยายด้วย AI บนเส้นทางเริ่มต้น super-resolution บนคลาวด์กู้คืนรายละเอียดที่การสุ่มตัวอย่างใหม่ฝั่งเบราว์เซอร์ทำไม่ได้ พร้อมเส้นทางสำรองในเบราว์เซอร์เมื่อไม่สามารถเข้าถึงบริการได้

ต้นทุนที่เรายอมรับจากการอยู่ฝั่งเซิร์ฟเวอร์บนเส้นทางเหล่านั้นคือการเดินทาง ไปกลับหนึ่งครั้งต่อการดำเนินการ ต้นทุนที่เราหลีกเลี่ยงได้โดยอยู่ฝั่งไคลเอนต์ ในที่อื่น ๆ ทั้งหมด คือค่าใช้จ่ายเดียวกันนั้นในส่วนของ workflow ที่ปรับแต่ง บ่อยที่สุด

ไปป์ไลน์ ทีละขั้นตอน

1. คุณเลือกไฟล์

ผ่านตัวเลือกไฟล์ การลากและวาง หรือการวาง เบราว์เซอร์จะส่งออบเจ็กต์ File ให้กับ JavaScript JavaScript อ่านไบต์โดยใช้ FileReader หรือ Blob.arrayBuffer() ในขั้นตอนนี้ไม่มีจุดใดที่ไฟล์ถูกส่งผ่านเครือข่าย ไม่ว่าคุณจะใช้เครื่องมือใดก็ตาม

2. เบราว์เซอร์ถอดรหัสรูปภาพ

เบราว์เซอร์สมัยใหม่ถอดรหัส JPG, PNG, WebP, GIF และ AVIF ได้โดยกำเนิด เราใช้ createImageBitmap() เพื่อแปลงไบต์ดิบเป็น bitmap ที่ GPU ทำงานด้วยได้ นอกเธรดหลัก สำหรับ HEIC บนเบราว์เซอร์ที่ไม่ถอดรหัสได้โดยกำเนิด เราถอยกลับ ไปใช้ตัวถอดรหัส WebAssembly ที่รันในเครื่องในเบราว์เซอร์ของคุณ

3. เครื่องมือทำงานของมัน นี่คือจุดที่เส้นทางแยกออกจากกัน

• เครื่องมือฝั่งเบราว์เซอร์เท่านั้น (การครอบตัด การปรับขนาด ตัวอย่างและแถบเลื่อนของการบีบอัด การประกอบ PDF และการแปลงฟอร์แมตส่วนใหญ่) เครื่องมือเหล่านี้ทำงานในรูปของการแปลงพิกเซล Canvas และการเข้ารหัสใหม่ canvas.toBlob บนเครื่องของคุณโดยตรง กรอบครอบตัดแบบโต้ตอบใช้ Cropper.js ไม่มีอะไรออกจากหน้า
• การดาวน์โหลดบีบอัด เมื่อคุณแตะ “ดาวน์โหลด” รูปภาพจะไปยัง api.araluma.com ครั้งเดียว (บริการ Fastify บน Hostinger VPS ในเยอรมนี Node บวก sharp และ libvips ซึ่งเป็นไลบรารี C เดียวกับที่ Squoosh ใช้บนเส้นทางเซิร์ฟเวอร์ของมัน) มันถูกเข้ารหัสใหม่ด้วยพารามิเตอร์ที่คุณตั้งไว้ในตัวอย่าง และไบต์ถูกสตรีมกลับมา บริการนี้เก็บแคชที่แยกตาม tenant และอ้างอิงเนื้อหา (hash ของไบต์อินพุตบวกพารามิเตอร์) เพื่อให้การดาวน์โหลดรูปเดิมซ้ำด้วยการตั้งค่าเดิมเล่นไบต์ที่แคชไว้ แคชนั้นไม่ถูกจัดทำดัชนีตามตัวคุณ IP ของคุณ หรือชื่อไฟล์ หากบริการไม่สามารถเข้าถึงได้ เครื่องมือจะถอยกลับไปใช้ blob ตัวอย่างในเบราว์เซอร์
• การลบพื้นหลัง เส้นทางคลาวด์เริ่มต้น รูปภาพอัปโหลดครั้งเดียวไปยัง Cloudflare Worker จัดเก็บชั่วคราวในบัคเก็ต R2 ส่วนตัว ประมวลผลโดยการแบ่งส่วนภาพของ Cloudflare ที่รันโมเดล BiRefNet บน GPU ขอบ และผลการตัดออกถูกสตรีมกลับมา ออบเจ็กต์ที่จัดเก็บชั่วคราวจะถูกลบภายในหนึ่งชั่วโมงโดยกฎวงจรชีวิตของ R2 ไม่ว่าผลลัพธ์จะเป็นอย่างไร รูปภาพทั่วไปเสร็จในหนึ่งถึงสองวินาที ขีดจำกัดต่อ IP รายวันและขีดจำกัดขนาดอัปโหลดทำให้ tier ฟรียั่งยืน
• การลบพื้นหลัง เส้นทางสำรอง WebAssembly หาก Worker ไม่สามารถเข้าถึงได้ (เครือข่ายของคุณขาดหาย firewall ที่เข้มงวดบล็อกมัน โควต้ารายวันเต็ม หรือไฟล์ใหญ่เกินขีดจำกัดคลาวด์) เครื่องมือจะสลับอย่างเงียบ ๆ ไปใช้โมเดล ISNet ที่รันในเครื่องผ่าน ONNX Runtime Web ด้วย WebAssembly การรันครั้งแรกจะดาวน์โหลดโมเดลและใช้เวลานานกว่า การรันครั้งต่อไปเร็วกว่า บนเส้นทางนี้ไม่มีการอัปโหลด ตรวจสอบได้ใน DevTools
• การขยายด้วย AI เส้นทางเริ่มต้นส่งรูปภาพครั้งเดียวไปยังบริการ super-resolution บนคลาวด์ และสตรีมผลที่ขยายแล้วกลับมา พร้อมเส้นทางสำรองฝั่งเบราว์เซอร์หากไม่สามารถเข้าถึงบริการได้

4. คุณดาวน์โหลดผลลัพธ์

bitmap เอาต์พุตถูกเข้ารหัสเป็น Blob ห่อด้วย object URL และส่งให้กล่อง โต้ตอบบันทึกไฟล์มาตรฐานของเบราว์เซอร์ ไฟล์ปรากฏบนดิสก์ของคุณ

วิธีตรวจสอบด้วยตัวเอง

เลือกวิธีที่คุณชอบ:

วิธีที่ 1. ดูแท็บ Network

1. เปิด Araluma ในแท็บใหม่และเปิด DevTools แล้วไปที่แผง Network
2. ใช้ เครื่องมือฝั่งเบราว์เซอร์เท่านั้น อย่าง Circle Crop หรือแถบเลื่อนตัวอย่างของ Compress คุณจะเห็นคำขอสำหรับ HTML, CSS, JS และฟอนต์เท่านั้น บวกกับโมดูล WebAssembly ที่เกี่ยวข้องในการใช้ครั้งแรก จะไม่มีคำขอใดนำไบต์รูปภาพของคุณออกไป
3. ตอนนี้ใช้ เครื่องมือฝั่งสัมผัสเซิร์ฟเวอร์ อย่าง Compress ดาวน์โหลด หรือ Remove Background คุณจะเห็น POST เพียงรายการเดียวที่นำรูปภาพของคุณไปยัง endpoint ที่ระบุชื่อ และหนึ่งการตอบสนองที่ส่งผลลัพธ์กลับมา วางเมาส์เหนือคำขอใดก็ได้เพื่ออ่านขนาดและเวลา

คอลัมน์ “Initiator” บอกคุณว่าสคริปต์ใดเรียกใช้คำขอแต่ละรายการ และคอลัมน์ “Type” บอกคุณว่าส่งอะไรไป เราไม่ซ่อนข้อมูลใดในสองอย่างนี้

วิธีที่ 2. ใช้เครื่องมือแบบออฟไลน์

1. โหลดหน้าเครื่องมือ Araluma ใดก็ได้ ใช้ Remove Background หนึ่งครั้งกับรูปภาพขนาดเล็กเพื่อให้โมเดล ISNet ในเบราว์เซอร์ถูกแคช
2. เปิด DevTools ไปที่ Network และทำเครื่องหมายที่ Offline (หรือปิด Wi-Fi)
3. โหลดหน้าใหม่ ทรัพยากรแบบสแตติกถูกแคชไว้ ดังนั้นมันยังคงโหลดได้
4. ลองใช้เครื่องมือ:
   • เครื่องมือฝั่งเบราว์เซอร์เท่านั้น ยังคงทำงานได้ พวกมันไม่เคยต้องการเครือข่าย
   • Compress ดาวน์โหลด ถอยกลับไปใช้ blob ตัวอย่างในเบราว์เซอร์ (การเข้ารหัสมีประสิทธิภาพน้อยกว่าเล็กน้อย แต่ยังใช้งานได้)
   • Remove Background ถอยกลับไปใช้โมเดล ISNet WebAssembly และทำงานได้โดยไม่มีคำขอขาออก

หากเครื่องมือเหล่านั้นทำงานออฟไลน์ได้ (บางตัวลดประสิทธิภาพ ฝั่งเบราว์เซอร์ เท่านั้นเหมือนเดิม) โดยนิยามแล้วไม่มีเซิร์ฟเวอร์ใดเห็นรูปภาพของคุณ

สิ่งที่เราเห็น และสิ่งที่เราไม่เห็น

บนเส้นทาง ฝั่งเบราว์เซอร์เท่านั้น เราไม่เห็นอะไรเกี่ยวกับรูปภาพของคุณเลย ไม่มีคำขอให้ดู ไม่มีแคชให้เก็บมัน ไม่มีบรรทัดล็อกให้ค้นหา

บนเส้นทาง ฝั่งสัมผัสเซิร์ฟเวอร์:

• Compress ดาวน์โหลด เห็นไบต์รูปภาพตลอดระยะเวลาการเข้ารหัส (โดยปกติไม่กี่ร้อยมิลลิวินาที) เก็บรายการแคชที่อ้างอิงเนื้อหาตาม TTL ของมัน และแค่นั้น แคชไม่ถูกจัดทำดัชนีตามผู้ใช้ IP ชื่อไฟล์ หรือตัวระบุใดที่เราสามารถใช้ค้นหารูปภาพ “ของคุณ” เราไม่บันทึกเนื้อหารูปภาพ บริการเข้ารหัสใช้ร่วมกันระหว่าง tenant เดียวกับที่ v1 ให้บริการก่อนการโอนย้าย โดยมี CORS ขีดจำกัดอัตรา และ URL canonical ที่เซ็นด้วย HMAC แยกตาม tenant
• Remove Background เห็นรูปภาพตลอดระยะเวลาการอัปโหลดจัดเก็บชั่วคราวและการเรียก segmentation (โดยปกติหนึ่งถึงสองวินาที) หลังจากนั้นสำเนาที่จัดเก็บชั่วคราวถูกลบโดยกฎวงจรชีวิตของ R2 เราไม่เคยส่งไบต์ของคุณไปยังผู้ให้บริการโมเดลบุคคลที่สาม โมเดล BiRefNet ทำงานภายในโครงสร้างพื้นฐานของ Cloudflare เอง ไม่ใช่บน API ภายนอกแบบ remove.bg, fal.ai หรือ Replicate
• การขยายด้วย AI เห็นรูปภาพตลอดระยะเวลาการเรียก super-resolution ส่งคืนผลลัพธ์ และไม่เก็บอะไรที่ผูกกับคุณ

บนทุกเส้นทาง ผู้ให้บริการ analytics ของเรา (Cloudflare Web Analytics) บันทึกข้อมูลการดูหน้าแบบรวม: URL, ประเทศ, ตระกูลเบราว์เซอร์, Core Web Vitals ไม่มีคุกกี้ ไม่มีตัวระบุถาวร ไม่มีอะไรที่ผูกกับบุคคล

สำหรับเครื่องมือที่ดาวน์โหลดโมดูล WebAssembly ในการใช้ครั้งแรก (ตัวถอดรหัส HEIC โมเดล ONNX ของ ISNet) ผู้ให้บริการโฮสต์ของเราเห็นว่ามีคนดึงโมดูลนั้น เหมือนกับ ที่เห็นว่ามีการดึงไฟล์ CSS โมดูลเองไม่มีข้อมูลใดเกี่ยวกับรูปภาพของคุณ

รายการข้อมูลทั้งหมดอยู่ในนโยบายความเป็นส่วนตัวของเรา

สแต็กเทคโนโลยี

สำหรับผู้ที่อยากรู้:

• Astro ตัวสร้างเว็บไซต์แบบสแตติก ทุกหน้าถูกส่งเป็น HTML ธรรมดาพร้อม JavaScript “islands” แบบ progressive enhancement เฉพาะที่ที่เครื่องมือเชิงโต้ตอบอยู่
• Vanilla CSS พร้อม custom properties ไม่มี Tailwind ไม่มี CSS-in-JS ระบบออกแบบทั้งหมดคือไฟล์ tokens.css ไฟล์เดียว
• canvas.toBlob และ <canvas> การเข้ารหัส JPEG, PNG, WebP และ AVIF สำหรับเครื่องมือและตัวอย่างฝั่งเบราว์เซอร์
• Cropper.js เลเยอร์การโต้ตอบของกรอบครอบตัด
• ONNX Runtime Web รันเส้นทางสำรอง ISNet WebAssembly สำหรับ Remove Background
• Cloudflare โฮสต์ build แบบสแตติกและให้บริการจาก edge และรัน Workers, R2 และไปป์ไลน์การแบ่งส่วนภาพ (BiRefNet) เบื้องหลังเส้นทาง Remove Background เริ่มต้น
• Fastify พร้อม sharp และ libvips บน Node บริการดาวน์โหลดบีบอัดที่ api.araluma.com บน Hostinger VPS ในเยอรมนี
• Cloudflare Web Analytics การนับการดูหน้าแบบรวมโดยไม่มีคุกกี้

การรองรับเบราว์เซอร์

เครื่องมือทุกตัวทำงานบนเวอร์ชันปัจจุบันและเวอร์ชันก่อนหน้าของ Chrome, Firefox, Safari และ Edge ทั้งบนเดสก์ท็อปและมือถือ เว็บไซต์ใช้ progressive enhancement: ที่ใดที่เบราว์เซอร์รองรับ API ที่ใหม่กว่า (เช่น showSaveFilePicker หรือ OffscreenCanvas) เราใช้มัน และที่ใดที่ไม่รองรับ เราถอยกลับไปใช้ตัวเทียบเท่า ที่เก่ากว่า ไม่มีกำแพง “เบราว์เซอร์ของคุณไม่รองรับ”

ข้อกำหนดที่จำเป็นเพียงอย่างเดียวคือ JavaScript (สำหรับเครื่องมือทุกตัว) และ การเชื่อมต่อเครือข่าย (เฉพาะเมื่อใช้เส้นทางที่สัมผัสเซิร์ฟเวอร์ เครื่องมือฝั่ง เบราว์เซอร์เท่านั้นทำงานออฟไลน์ได้อย่างสมบูรณ์หลังจากโหลดหน้าครั้งแรก)

คำถาม

มีอะไรที่เราไม่ได้ครอบคลุม? ส่งอีเมลมาที่ support@araluma.com ยินดีรับคำถามทางเทคนิค