AstroBaaS

Content & editorial

Image Resizing on Upload

Free — GPL coresize Splanned, not built

Generated from docs/plan/core/image-resizing-on-upload/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Image Resizing on Upload automatically resizes uploaded images to specified dimensions (e.g., 500×500 for product detail, 150×150 for thumbnail). Merchants upload an image at any size; the system auto-resizes to standard dimensions and stores variants. This is core GPL functionality: infrastructure, honest resize logic, no credential or per-country obligation.

The problem

Merchants must resize images in Photoshop before upload. Non-technical team members can’t do it and upload at wrong dimensions (400×800 when 500×500 expected), breaking gallery layouts or storefront responsive design. Auto-resize removes the friction and prevents layout breaks.

What it does

  • Dimension templates: define standard sizes per collection (e.g., Product: 500×500, 150×150, 1200×1200)
  • Auto-crop on mismatch: if uploaded image 600×800 (aspect 3:4), resize to 500×500 (aspect 1:1) by cropping center
  • Preserve aspect ratio: if no cropping specified, letterbox with background color (or skip if orientation differs too much)
  • Quality preservation: use high-quality resize algorithm (Lanczos, not nearest-neighbor) to avoid pixelation
  • Batch resize: if merchant uploads 100 images, resize all in parallel
  • Fallback on error: if resize fails (corrupted JPEG), skip variant and log error, don’t break import
  • Admin preview: show before/after comparison (original 600×800 → resized 500×500)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

  • Smart cropping (detect product and zoom in) — scope is center-crop only; smart crop is separate ML feature
  • Custom dimensions per product — scope is collection-level templates only; per-product sizing is admin burden
  • Aspect ratio preservation (no cropping) — scope is auto-crop; preservation is storefront responsibility

Data model

Extend collection schema: add imageVariants config = [{name: ‘thumbnail’, width: 150, height: 150, mode: ‘crop’}, …]. No schema migration if using extension.

API

  • POST /api/assets/upload — auto-resize to collection-defined dimensions
  • GET /api/collections/:collection/image-variants — fetch variant config

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Collection settings: Image Variants section lists templates (Thumbnail 150×150, Detail 500×500). Add Variant button. Product upload preview shows original dimensions and resized variants (before/after).

The seam — why this is core

Core owns: image resize algorithm, variant storage, batch processing, error handling. No paid pack owns this; it’s infrastructure.

Core owns the interface + honest resize-on-upload; image processing is infrastructure, not a credential or support commitment.

Dependencies

  • image-optimization (works with optimizer to reduce file size post-resize)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

  • Upload 600×800 image to product collection with variant config 500×500 (crop mode)
  • Auto-resize crops center 500×500 section; result is 500×500
  • Admin preview shows original 600×800 and resized 500×500 side-by-side
  • Batch upload 50 images: all resized in parallel in <10 seconds
  • Corrupted JPEG fails resize; error logged, variant skipped, product still imports successfully

Risks

Aggressive crop removes important product details; center-crop not suitable for all images (crop might hide key feature). Memory spike on batch resize of large images; must stream or chunk. Aspect ratio mismatch causes letterboxing (white bars) on final image; users expect crop, not bars.

Commercial context

Suggested pricefree (core)
Rival anchorShopify: included; Magento: included

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.


Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.