Statamic Color Extractor Laravel Package

Product Decisions This Supports

• Image-driven theming and design polish: the addon extracts dominant/accent colors from Statamic assets and stores them as asset metadata, which unblocks features like dynamic color palettes per entry, brand-consistent gradients, tinted overlays, and "match the UI to the hero image" layouts without manual editor input.
• Perceived-performance work: extracted colors feed low-quality image placeholders (LQIP/blur-up), skeleton states, and background fills that render before the full asset loads — a measurable LCP/CLS lever that normally requires custom image-pipeline work.
• Content operations and discovery: color metadata enables filtering/searching or auto-tagging an asset library by palette ("show me warm-toned imagery"), which is a roadmap item most CMS setups defer indefinitely.
• v2.1.0 specifically — automation changes the product promise: the new console command and event listener mean colors can be generated at upload time and backfilled in bulk for existing libraries. That upgrades this from "an editor must remember to click Extract" to "palette data exists for every asset, always." Decisions this now supports:
  • Ship color-dependent features with confidence that coverage is ~100%, including on legacy content migrated in.
  • Commit to "palette available immediately after upload" in specs without budgeting bespoke queue/job work.
  • Treat the bulk command as a one-time migration/backfill step in launch runbooks rather than an ongoing editorial chore.
• Build vs. buy: adopting this is a composer require plus configuration versus roughly several days of engineering to wire an image-color library (ColorThief, league/color-extractor) into Statamic's asset meta pipeline, plus ongoing maintenance. Clear "buy/adopt" for anything short of a bespoke color-science requirement.
• Roadmap sequencing: low-effort enabler that makes visual-polish initiatives (theming, placeholders, color search) cheap to schedule. It also de-risks a later migration to a hosted image CDN, since palette data is already materialized in content rather than computed per request.

When to Consider This Package

Adopt when:

• The product runs on Statamic (the addon is Statamic-specific; it is not a general Laravel package despite living in the Laravel ecosystem).
• Assets are local/native Statamic assets — the extractor needs readable image files, so external DAMs or hot-linked remote URLs are a poor fit unless mirrored locally.
• You need palette data server-side (templates, APIs, search index, email/PDF rendering) rather than only in the browser.
• Your image volume and traffic let you afford one-time or queued extraction; the new command/listener makes this cheap, but a 100k-asset backfill still wants a queue worker and sensible batching.
• You can accept a small, single-maintainer community addon — pin versions, review upgrades, and be prepared to fork if it goes stale. Acceptable for presentation-layer functionality; a harder sell where color is a contractual/accessibility-critical output.
• Required PHP image extensions (GD or Imagick) and reasonable memory limits are available in the runtime.

Look elsewhere when:

• You are not on Statamic — use a standalone PHP color library and your own model/meta plumbing instead.
• You need region-specific or pixel-accurate color (per-crop sampling, product-swatch matching, CMYK/print color management). Dominant-color extraction is a heuristic, not colorimetry.
• You need guaranteed SLAs, vendor support, or accessibility-certified contrast outputs — build or buy commercially.
• Extraction must happen at the edge / at ingest in a CDN pipeline with no PHP worker in the path.
• Your library is small enough that a one-off manual pass (or a designer-supplied palette per brand section) is cheaper than introducing a dependency.

Adoption checklist: verify Statamic major-version compatibility, confirm the listener fires on your upload path (CP, importer, API), run the bulk command against a staging copy first, and record the version pin plus a fork/exit plan in the tech-debt register.

How to Pitch It (Stakeholders)

For executives: This is a small, free, community-built addition to our Statamic stack. The v2.1.0 release adds automation — colors are pulled from images on upload, and existing image libraries can be processed in one batch run. That converts a nice-to-have into a dependable building block: we can promise image-aware theming, faster-feeling pages via color placeholders, and color-based asset search without new headcount or a vendor contract. Cost is effectively engineering hours, not license spend. Main risk is dependency hygiene — it is maintained by one developer, so we pin the version and keep a small exit plan. Recommendation: adopt for presentation-layer features; do not make it a dependency of anything revenue-critical or accessibility-critical without a fallback.

For engineering: composer require aryehraber/statamic-color-extractor, enable the addon, and rely on the new event listener for automatic extraction on asset upload plus the new console command for bulk backfill of the existing library. Extraction writes to asset meta, so templates and queries read cached values — no per-request image decoding. Please: run the backfill on a queue with batching and monitor memory, confirm the listener triggers on every ingestion path we use (CP uploads, importer, API), pin the version, and note that this is a single-maintainer package — treat upgrades as reviewable diffs and keep the extraction call behind a thin internal interface so we can swap in a standalone color library if needed.