- How do I install mike42/gfx-php in a Laravel application?
- Install it with composer require mike42/gfx-php; note the README shows composer install, but require is the command you want for adding the dependency. It requires PHP 7.0 or newer and the zlib extension for PNG reading, both of which are typically already present. There is no service provider shipped with the package, so you bind your own adapter or facade if you want container resolution. A small wrapper class plus a config entry is usually enough for a working integration.
- Does mike42/gfx-php require the GD or Imagick extension?
- No. gfx-php is a pure PHP implementation of raster input, output and processing, so it works without GD, ImageMagick or GraphicsMagick being loaded. The only hard requirement beyond PHP itself is zlib for PNG decompression. That makes it useful on locked-down shared hosting, distroless or slim containers, and air-gapped deployments where you cannot install image extensions. On a normal runtime that already has GD or Imagick, the package adds little over the platform.
- Which image formats can gfx-php read and write?
- It supports PNG, GIF, BMP and the Netpbm formats (PPM, PGM, PBM), plus WBMP writing. That Netpbm coverage is the genuine differentiator, since GD and Imagick handle BMP and PNG comfortably already. Operations include scaling, cropping, format conversion and colorspace transforms. Vector formats such as SVG, PDF and EPS are explicitly out of scope and will never be supported.
- Is mike42/gfx-php compatible with PHP 8.2 and Laravel 10 or 11?
- The documented floor is PHP 7.0 and the changelog still references HHVM 3.21 and 3.27, with no evidence of validation on PHP 8.1 through 8.3. Deprecations such as dynamic properties and implicit nullable parameters may surface or fatal under strict deprecation handling. Before adopting, run the suite in a PHP 8.3 matrix with deprecations escalated to exceptions. If you run PHPStan or Larastan at level 6 or above, expect to add a baseline for the loosely typed API.
- Why does my PNG lose transparency when converting with gfx-php?
- The PNG reader composites transparent pixels onto a white background and the output is always 24-bit RGB, so alpha is discarded silently. Logos, watermarks and overlays will ship with visible white boxes even though the format is reported as supported. This is not configurable, so treat it as a product-level constraint. Route alpha-bearing assets to GD or Imagick and restrict gfx-php to opaque images.
- How do I use gfx-php inside a Laravel service layer?
- Wrap it the same way you would any standalone library: bind an interface in a service provider, inject it where needed, and keep the imperative calls such as Image::fromFile(), write(), scale(), crop() and convert() behind that boundary. The package has no framework coupling, no container usage and no I/O assumptions beyond the filesystem, so there is no architectural conflict. The natural fit is a queue-driven offline batch path for format conversion, thumbnail synthesis or archive normalization, not the request and response path. An adapter usually takes one to two engineer-days plus a benchmark spike.
- How much memory does gfx-php use when processing large images?
- Pure PHP pixel buffers backed by PHP arrays and zend values typically run 10 to 50 times the size of the raw bitmap, so a 24MP image can plausibly exceed 1 to 2 GB. Exhaustion produces a fatal error rather than a catchable exception, so there is no graceful degradation in a worker. Cap dimensions by reading headers before decoding, set memory_limit per worker, and isolate processing in a child process with a timeout. Benchmark against representative production images before committing to the dependency.
- Can I safely use gfx-php for untrusted user uploads in Laravel?
- The pure PHP decoder removes CVE-class buffer overflow risk from libgd and libpng, which is a real plus, but resource exhaustion remains. Decompression bombs and pathological LZW streams can consume unbounded CPU and memory. Validate dimensions from file headers before decoding, cap upload size, and run the work on an isolated queue with a hard timeout. Never decode user uploads synchronously in the request path.
- What are good alternatives to mike42/gfx-php for image handling in Laravel?
- For typical Laravel applications, GD or Imagick via intervention/image or spatie/image is the pragmatic default: faster, alpha-aware, and backed by an active ecosystem. Because PHP's GD has included imagecreatefrombmp() and imagebmp() since 7.2, and Imagick handles BMP well, the portability argument for gfx-php is weaker than older write-ups suggest. Choose gfx-php only when Netpbm formats are in scope or the runtime genuinely cannot load an image extension.
- Is mike42/gfx-php actively maintained and what license does it use?
- It is a single-maintainer project with a small star count, no dependents and sparse releases, so plan for the possibility that you end up owning a fork. Release metadata on the registry appears inconsistent with the changelog, which stops at v0.6, so treat version listings as unverified. The license is declared LGPL-2.1 while the contributing section says LGPLv3 or later, an inconsistency legal counsel will flag. Keep it as an unmodified Composer dependency rather than vendor-patching it, and budget a short legal sign-off.