Product Decisions This Supports
- Feature prototyping before infrastructure investment. A PM can validate demand for face-aware features — auto-cropped avatars, "blur faces before publishing," profile photo moderation, photo tagging UX — in days rather than quarters, without standing up an ML service or negotiating a vision API contract. The 0.1.0
cropFaceToJpeg helper now returns a ready-to-use cropped face image in a single call, which removes the last hand-written step from the "detect + crop" prototype loop.
- Build vs. buy analysis for computer vision. This package establishes the cheapest possible baseline (pure PHP, GD-only, zero dependencies). If the prototype clears the accuracy bar for your use case, you have evidence that a heavier vendor commitment isn't justified yet; if it fails, you have a documented accuracy benchmark to take to vendors. The new crop output makes that benchmark directly inspectable by non-engineers — you can hand stakeholders a folder of actual cropped faces rather than bounding-box coordinates.
- Privacy and data-residency decisions. Because detection and cropping run entirely in-process on your own servers, no image ever leaves your infrastructure. This is a genuine product differentiator for healthcare, legal, education, and EU-facing products where uploading user photos to a third-party API triggers DPA review or blocks the feature outright.
- Roadmap sequencing for photo/media products. Helps answer "do we need a real CV pipeline this quarter or next?" — the answer depends on volume and accuracy tolerance, both of which this package lets you measure cheaply. Derived-asset storage (the cropped avatars themselves) is now part of the estimate you can scope, since the package produces them rather than requiring a custom image pipeline.
- Deployment-constrained segments. Shared hosting, air-gapped on-prem installs, and legacy PHP environments where you cannot install OpenCV, Python, or a sidecar service. This is the narrow but real case where the package has no drop-in substitute.
- Scope negotiation with engineering. A concrete, low-cost spike gives the team something to critique, which surfaces the real cost of the production path (accuracy tuning, queueing, storage of derived assets, avatar framing/quality rules) far earlier than a spec document would.
When to Consider This Package
Adopt it when all of the following hold:
- Your project's license is compatible with GPL-2.0. For a proprietary or SaaS product, this is usually a hard stop — GPL is copyleft and viral, and bundling it into a closed-source codebase creates real legal exposure. Get counsel involved before, not after. The 0.1.0 feature release does not change this; adding surface area to a GPL dependency does not dilute the obligation.
- Volume is low and latency is not user-facing. Pure-PHP Haar cascade scanning is orders of magnitude slower than native implementations. It is acceptable for a nightly batch job, an admin-side tool, or a queue worker with a generous timeout. It is not acceptable inline in an upload request at any meaningful scale — and
cropFaceToJpeg now adds a per-face re-encode and JPEG write on top of the scan, so budget for that in the same job.
- You can absorb maintenance risk. The project was archived in 2016; 0.1.0 is a fresh functional release, which is a mild positive signal but does not restore a maintenance guarantee. Treat it as vendored source you own, not a maintained dependency.
- Accuracy requirements are modest. Frontal, well-lit, reasonably sized faces in ordinary photos. If you need profile views, occlusion handling, small faces in group shots, or video frames, look elsewhere. Note that a cropped output makes detection errors more visible to stakeholders than a bounding box ever did — a bad crop is a bad avatar.
- You want zero Composer/binary footprint. No autoloading, no version constraints, no extension installs beyond GD — attractive for constrained or legacy environments.
cropFaceToJpeg keeps this property: the crop is produced with GD, no new dependency.
Look elsewhere when:
- You need production-grade accuracy or throughput — use a managed vision API (AWS Rekognition, Google Cloud Vision, Azure AI Vision) or a native stack (OpenCV, dlib, a Python/ONNX microservice).
- You need face recognition or identity, not just detection. This library returns bounding boxes and, as of 0.1.0, cropped face images; it still does not identify or compare faces. Don't let stakeholders conflate the two — a folder of cropped faces looks a lot like a face-recognition demo to a non-technical audience.
- You need polished avatar framing.
cropFaceToJpeg is a rectangular cut of the detected region; it does not centre, pad, square, or apply safe-area rules. If your product spec has a circular avatar with consistent headroom, you still own that post-processing.
- License hygiene matters — prefer a permissively licensed alternative (MIT/Apache) even at higher integration cost.
- You need ongoing security patching, PHP 8+ guarantees, or vendor support. One feature release does not establish a support commitment; verify PHP-version compatibility yourself.
- You're building a differentiator. Your face-detection capability is not a competitive advantage if it's built on a decade-old library; it's a liability with a countdown clock.
How to Pitch It (Stakeholders)
For executives: This is a zero-cost, zero-vendor way to test whether face-aware features are worth investing in. It now goes as far as producing the actual cropped face image, so we can show real output — not just technical feasibility — in a short spike. It runs entirely on our own servers, so no customer photos leave our infrastructure: a meaningful privacy and compliance advantage, and a strong story for regulated customers. The trade-offs are unchanged: the library is GPL-licensed and has no support commitment, so it is a prototype and internal-tooling asset, not a production foundation. The recommendation is a bounded spike (days, not weeks) to validate the feature and produce a benchmark, with a pre-agreed decision point on whether to buy a managed vision API or build a native pipeline. Treat the new crop feature as a prototyping accelerator, not as evidence the library is now production-ready.
For engineering: 0.1.0 adds cropFaceToJpeg, which returns the detected face as a JPEG — useful for prototypes, but it is a plain rectangular cut with no padding, squaring, or quality controls, so plan your own framing logic for avatars. The rest of the constraints stand: single-class API, GD-only, no Composer or binaries — integration cost is measured in hours. Run it in a queue, cap input resolution via the built-in image scaling option, tune sensitivity against a labelled sample of your real images, and consider whether writing cropped faces to disk creates a new data-retention and storage surface you need to govern. Be explicit about GPL-2.0 licensing, archived upstream, and Haar cascade performance that rules out synchronous use. Assume you will replace it: keep the detector behind an interface, and make the crop a separate, swappable step so a future vendor or native pipeline can drop in without touching callers.