बैकएंड में user image upload लेते समय कुछ समस्याएं चुपचाप साथ आ जाती हैं.

  • JPEG में GPS coordinates, device model name, और capture time EXIF में शामिल हो सकते हैं
  • ICC profile जैसे color metadata भी वैसे ही store और distribute हो सकते हैं
  • अगर JPEG, PNG, GIF, WebP मिले-जुले रूप में आएं, तो storage/CDN/rendering pipeline जटिल हो जाती है
  • सिर्फ EXIF orientation को गलत handle करने पर भी image 90° घूमी हुई अवस्था में store हो सकती है

smol-image-processor इन समस्याओं को एक साथ संभालने वाला single-purpose माइक्रोसर्विस है.

काम करने का तरीका

POST /process पर multipart/form-data के रूप में image upload करने पर response में हमेशा WebP
वापस मिलता है. यह Sharp के default output behavior का सीधा उपयोग करता है, जिसमें source EXIF, ICC profile आदि metadata हट जाते हैं. हालांकि, EXIF orientation को metadata हटाने से
पहले .rotate() से pixel पर लागू किया जाता है, ताकि image direction सुरक्षित रहे.

defense layer दो हैं.

  • pixel count limit (MAX_PIXELS): file size छोटी होने पर भी decode करते समय सैकड़ों millions pixels तक
    फैलने वाली image (decompression bomb) को Sharp के limitInputPixels से रोका जाता है.
  • frame count limit (MAX_PAGES): सैकड़ों या हजारों frames वाले animated GIF/WebP से memory·CPU
    खत्म कर देने वाले DoS को रोका जाता है.

animated GIF/WebP को animated WebP में बदला जाता है, और frame delay तथा loop count
सुरक्षित रहते हैं. PNG का alpha channel भी जस का तस बना रहता है.

response header में processed image की width, height, size, animated है या नहीं, page count शामिल
होते हैं, इसलिए अलग metadata extraction step के बिना इन्हें सीधे DB में store किया जा सकता है.

स्टैक

  • Runtime: Bun, HTTP framework: Elysia
  • image processing: Sharp (libvips wrapper)
  • Docker image उपलब्ध (GHCR)

त्वरित शुरुआत

docker run --rm -p 6701:6701 ghcr.io/levish0/smol-image-processor
curl -F file=@photo.jpg http://localhost:6701/process -o clean.webp

https://github.com/levish0/smol-image-processor

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.