Download the PHP package citomni/image without Composer

On this page you can find all versions of the php package citomni/image. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of citomni/image

Informations about the package image

CitOmni Image

Deterministic, backend-independent image inspection, transformation, compositing, encoding, and file output for CitOmni applications and packages.

citomni/image is the shared image-processing capability for the CitOmni ecosystem. It accepts image files or in-memory image bytes, validates the source before expensive work, applies deterministic geometry, composites overlays such as watermarks, produces one or many derived outputs, verifies the encoded result, and exposes the effective runtime capabilities through one App-aware service.

The package deliberately separates image processing from upload handling, persistence, storage policy, URLs, and application business logic. It knows pixels, formats, geometry, codecs, and output files. It does not need to know why an image exists.

The public contract is backend-independent. Callers work with source paths or bytes, declarative output specifications, and plain result arrays. Native backend objects never leave the package.

In practical terms, citomni/image lets an application turn one source image into a large WebP, a square JPEG thumbnail, or in-memory encoded variants without teaching each consumer the finer points of EXIF orientation, alpha flattening, format limits, truncation checks, or runtime codec support.

Highlights

What this package is

citomni/image is CitOmni's transport-agnostic image-processing package.

Its job is to provide one stable contract for common image work such as:

The package uses a fixed public vocabulary for known image formats, while actual decode and encode support is determined at runtime.

Knowing a format is not the same thing as being able to process it. That distinction is intentional.

What this package provides

Image inspection

inspect() and inspectString() read container-level metadata without decoding the inspected image's pixels. Resolving the reported decoder may run the cached synthetic capability probe the first time a format is seen.

They report:

Inspection is intentionally lighter than a full processing job. It does not promise that the pixel data will decode successfully, and it does not enforce every processing-time guard.

Image processing

save(), saveString(), encode(), and encodeString() process one source into one or many outputs.

Every output may independently define:

The per-output processing order is fixed:

The service computes geometry in display space and maps the work back to stored space so expensive orientation can be applied after resampling where possible.

Runtime capability reporting

capabilities() reports the actual runtime rather than an optimistic feature list.

It includes:

Codec support is probe-verified and memoized per service instance.

Safe file output

save() and saveString() use a two-phase write model.

  1. Every requested output is written to a temporary sibling file and verified.
  2. Only after all outputs pass verification are the temporary files moved into their target paths.

A failure during phase 1 leaves all target files untouched.

Existing targets are not replaced unless an output sets 'overwrite' => true. See Write safety model.

A failure during the commit phase raises ImageWriteException (or ImageTargetExistsException), which reports exactly which outputs were committed and which were left untouched.

What this package owns

citomni/image owns the mechanics and policy of image processing.

That includes:

The package owns the image operation, not the application's reason for performing it.

What this package does not own

citomni/image is intentionally not a media library, upload system, or persistence layer.

It does not own:

Those responsibilities belong to the caller or another package.

No media-library wizard hat is hidden under Image.php.

Relationship to other CitOmni packages

citomni/image is a reusable technical capability that can be consumed by both applications and other CitOmni packages.

Typical relationships may look like this:

An HTTP controller may use the service, but citomni/image does not depend on citomni/http.

A CLI command may use the same service, but citomni/image does not depend on citomni/cli.

A future upload package may delegate image transformations to citomni/image, but image processing remains independently usable outside upload flows.

This is why the service lives in a dedicated package instead of being embedded in an HTTP adapter or one particular application workflow.

Requirements

GD is the baseline image engine. Imagick is used automatically for jobs GD cannot perform, when it is installed.

Codec support inside both engines still depends on how they were compiled. For example, one server may support AVIF through GD while another PHP 8.5 server with GD may not; an older ImageMagick may decode HEIC but mis-handle very small AVIF images.

Use capabilities() when the application needs to know what the current runtime can actually do.

The package does not require citomni/http or citomni/cli.

Installation

Install the package with Composer:

Register the provider in the application's config/providers.php:

The package registers the service in both HTTP and CLI mode:

No routes or CLI commands are contributed by the package.

Quick start

Create a large WebP and a square JPEG thumbnail from one source image:

Example result shape:

The exact proportional height and encoded byte size naturally depend on the source image and encoder.

Public API

The primary service currently exposes:

The public API uses paths, bytes, declarative arrays, and result arrays.

Native backend objects are internal implementation details.

Inspection

Inspect a file

Inspect bytes already in memory

The result has this shape:

Some header facts may be null when the format does not expose them reliably.

color_space is always set; untagged images are srgb. See Color management.

Inspection is header-oriented. It does not fully decode the source and should not be treated as proof that later processing will succeed.

Saving files

Use save() when the source is a file:

Use saveString() when the source image already exists as bytes:

Target directories must already exist.

Target paths must be unique within one call. Uniqueness is checked on a canonical identity: the existing directory is resolved with realpath() (so dir/./a.png and dir/a.png collide), and on Windows the comparison is case-insensitive.

An existing target is never replaced unless the output sets 'overwrite' => true.

Encoding to memory

Use encode() when the source is a file but the result should stay in memory:

Use encodeString() when both source and output live in memory:

Encoded result entries contain:

Output specifications

Each output is an associative array.

For save() and saveString(), path is required.

For all processing methods, format is required.

path

Target file path.

Requirements:

overwrite

Whether an existing target may be replaced:

Default:

Target overwrite false overwrite true
Does not exist Written Written
Exists ImageTargetExistsException Atomically replaced

false is a guarantee, not a best-effort check. Targets are checked before any processing (cheap early failure), and the final publish uses an atomic create-if-absent (a hard link from the verified temporary file). A file that another process creates while the job is running is therefore never replaced; the job fails with ImageTargetExistsException instead. See Write safety model.

Used only by save() and saveString().

format

Output format as a string or ImageFormat.

Known format values:

A known format is not automatically an available encoder.

The current runtime must have a configured backend whose codec passes capability verification.

width and height

Optional target dimensions in pixels:

For contain, either dimension may be omitted.

If both are omitted, the selected crop region keeps its size.

cover and fill require both dimensions.

fit

Supported fit modes:

Default:

contain

Preserves aspect ratio and keeps the complete selected image inside the target box.

No pixels are cut away.

With only one target dimension, the other dimension is derived proportionally.

cover

Preserves aspect ratio and fills the target box completely.

Overflow is removed using a centered crop.

fill

Scales each axis independently to the requested dimensions.

This may distort the image when source and target aspect ratios differ.

Use it only when distortion is intentional.

upscale

Whether the image may be enlarged:

Default:

Without upscaling, the service will not enlarge the selected source region merely to satisfy a larger target box.

crop

Explicit crop rectangle in display-space coordinates:

The crop is interpreted after automatic orientation and explicit rotation.

It must lie completely inside the effective image.

rotate

Additional clockwise rotation in degrees:

The value must be an integer multiple of 90.

Negative multiples are accepted.

overlays

Images drawn onto the fitted output, in list order (watermarks, logos, badges):

Each overlay accepts:

Key Type Default Meaning
file string - Overlay source file. Exactly one of file or data.
data string - Overlay source bytes.
anchor string or ImageAnchor center top-left, top, top-right, left, center, right, bottom-left, bottom, bottom-right.
offset [x, y] [0, 0] Added after anchoring; +x right, +y down.
width int native size Overlay width in pixels; height follows the overlay's aspect ratio.
width_percent int 1-100 native size Overlay width relative to this output's width. Mutually exclusive with width.
opacity int 0-100 100 Multiplies the overlay's own alpha.

Behavior:

quality

Lossy quality from 0 to 100:

Applies only to formats that use lossy quality, currently:

When omitted, the package configuration is used.

A runtime may still lack an encoder for one of these known formats.

compression

PNG compression level from 0 to 9:

This is zlib compression for a lossless PNG.

It is deliberately separate from lossy image quality.

background

Flatten background for formats without alpha:

The value must use #rrggbb.

The current package-level output policy flattens JPEG and BMP outputs.

For alpha-preserving formats, background is not an output setting.

Job options

Job options apply to the whole processing call.

auto_orient

Default:

When enabled, the source EXIF orientation is included in the effective transformation.

All eight EXIF orientations are supported, including mirrored variants.

HEIF container transforms (HEIC/AVIF clean aperture, irot, imir) are part of the image definition and are always applied, regardless of auto_orient.

multi_frame

Supported values:

Default:

Multi-frame or animated input is rejected by default rather than silently converted into a still image.

Use:

when the caller explicitly wants the first frame.

Actual first-frame support is backend- and format-dependent. If the active runtime cannot perform it reliably, the service raises ImageCapabilityException.

color

Supported values:

Default: the image.color configuration value, srgb unless changed.

See Color management.

Multiple outputs from one source

One source may produce many independent outputs in the same job:

The service sees the complete job before decoding.

That allows it to:

A variant is always planned from the source image contract, not produced by resizing another requested variant.

That costs a little more than a cascading thumbnail chain and buys much better determinism.

Runtime capabilities

Never assume codec support from the PHP version alone.

Use:

The result has this general shape:

The values above are illustrative.

color_management names the first configured backend whose ICC conversion is verified with a real Display P3 sample, or null.

The actual report depends on the current runtime.

The package does not silently replace a requested format with another format when support is missing.

If the caller requests AVIF and no configured backend can encode verified AVIF output, the operation fails explicitly.

Backends

The package ships two backends:

The public service contract is not tied to either. The internal backend seam is marked @internal and is not a public extension contract.

One job runs on one backend: the first configured backend that can decode every input (source and overlays) and encode every requested output format. With the default order ['gd', 'imagick'], ordinary JPEG/PNG/WebP work runs on GD and Imagick takes over only when a job needs it.

Output semantics are package rules, not backend properties. Both backends produce the same geometry, orientation, alpha behavior, flattening, metadata stripping, and 8-bit output; only codec bytes differ. The parity is covered by the regression suite.

Format support by backend

Format GD decode GD encode Imagick decode Imagick encode First frame
JPEG Yes Yes Yes Yes n/a
PNG Yes Yes Yes Yes GD, Imagick (APNG: default image)
GIF Yes No Yes Yes GD, Imagick
WebP Build-dependent Build-dependent Yes Yes Imagick
AVIF Build-dependent Build-dependent Build-dependent Build-dependent No
BMP Yes Yes Yes Yes n/a
TIFF No No Yes Yes Imagick (first page)
HEIC No No Build-dependent Build-dependent No

The runtime capability report remains authoritative. A build that lists a format but fails the package's codec probe is treated as unsupported.

Output rules shared by both backends

Imagick specifics

Capability verification

citomni/image does not consider a codec healthy merely because:

Decode, encode, and first-frame support are verified separately:

An encoder that writes the right format and size but drops alpha is therefore reported as unsupported for that format instead of silently producing opaque output. A round trip cannot tell encoder from decoder, so alpha or color loss withdraws encode support only.

The same probe logic runs for every backend; backends only supply the probe image and pixel reads.

Processing uses the same verified capability state.

Every encoded output is additionally checked for expected format and exact dimensions.

AVIF and HEIC outputs receive an additional decode verification because some codec stacks can produce container geometry that looks correct while decoded pixel geometry is not. ImageMagick 6.9.11, for example, decodes its own 8x8 AVIF output as 4x5; such an output fails with ImageCapabilityException instead of being written.

Capability results are cached per Image service instance.

Source validation

Image input should be treated as untrusted content.

Before expensive processing, the service performs relevant checks such as:

After decode, the pixel dimensions must agree with the source header.

A mismatch is rejected rather than silently accepted.

For HEIC and AVIF the package parses the container itself (primary item, ispe, clap, irot, imir), so inspection, the pixel budget, and the geometry check work without any backend and do not depend on getimagesize() support for HEIF.

Truncated JPEG and GIF

Some image engines can successfully decode truncated JPEG or GIF input.

citomni/image therefore performs additional structural checks for these formats before accepting them for processing.

The goal is not to turn the package into a forensic file parser.

The goal is to avoid treating obviously incomplete image data as a successful source merely because a tolerant decoder returned pixels.

Pixel limits

The default package policy is:

The limit applies to source images, overlay sources, and planned outputs.

For a source image:

must stay within the configured budget. For HEIC and AVIF this is the coded frame (what a decoder allocates), not only the clean aperture, which can be much smaller.

The same applies to derived output geometry. The check is computed without multiplying, so it cannot overflow.

HEIC and AVIF data larger than the uncompressed primary image (4 bytes per coded pixel plus 1 MiB of metadata) is rejected before decoding. Such files are pathological, and some engines decode HEIF from memory.

Container sizes and rationals are treated as untrusted integers: HEIF boxes may not extend beyond the actual data, metadata reads are capped at 1 MiB, clean-aperture arithmetic is range-checked, and file reads are clamped to the file size.

Known format-specific dimension limits are also enforced where relevant.

The pixel limit is a guard against unreasonable image buffers and pathological input. It is not a promise that every image below the limit will fit into every possible PHP runtime memory budget.

EXIF orientation

Automatic orientation is enabled by default.

The package handles EXIF orientation values 1 through 8, including mirrored orientations.

Geometry is planned in display space.

This means a caller can think in terms of the image as it should appear rather than the source file's raw stored axes.

Example:

If the JPEG source is physically stored sideways with EXIF orientation 6, the resulting geometry is still based on the correctly oriented display image.

HEIC/HEIF container transforms

HEIC and AVIF store orientation in the container rather than in EXIF. Phones commonly store the coded image sideways plus an irot rotation, and encoders add a clap clean aperture to remove codec padding.

The package reads these transforms from the container and applies them in the order the HEIF specification defines (clean aperture, rotation, mirroring). inspect() reports the clean-aperture size as width/height and the container rotation/mirroring as orientation.

Mirroring follows the HEIF 2nd-edition definition as decoded by libheif and libavif 1.x: imir mode 0 flips top-bottom, mode 1 flips left-right. EXIF orientation inside HEIF files is informational per the specification and is ignored.

Whether a backend applies the transforms while decoding (Imagick/libheif does) or the package applies them afterwards (GD) does not change the result.

Other HEIF metadata reported by inspect():

Metadata policy

Encoded outputs do not retain source EXIF, XMP, or GPS metadata.

This is deliberate.

Automatic orientation is applied to the pixels instead of requiring the original orientation tag to survive.

That makes derived output safer for ordinary web/application use and avoids accidentally publishing source GPS information.

Color profiles are not metadata in this sense: they are applied (see Color management), and outputs are written as untagged sRGB.

Color management

The package treats color as part of correct output, not as optional metadata.

Policy

With the default policy srgb (option color, configuration image.color), every source and overlay ends up as sRGB pixel values:

Source Handling
Untagged Assumed sRGB (the web convention). No conversion.
sRGB-equivalent ICC profile No conversion; works on every backend, including GD.
Display P3, Adobe RGB, ProPhoto, Rec. 2020, other RGB profiles Converted to sRGB from the embedded profile.
Grayscale profile with a non-sRGB curve Converted to sRGB.
CMYK with an ICC profile Converted to sRGB from the profile.
HEIF nclx primaries 1 (BT.709/sRGB), transfer 13 (sRGB) sRGB. No conversion.
HEIF nclx primaries 12 (P3, D65), transfer 13 Display P3: converted with the package's Display P3 profile.
HEIF nclx with unspecified (2) primaries or transfer Treated like an untagged image: the missing part is assumed to be sRGB's (ITU-T H.273 leaves unspecified values to the application).
HEIF nclx, anything else: transfer 1 (BT.709), BT.2020, PQ, HLG, ... Rejected under srgb (ImageCapabilityException). BT.709's transfer curve is not sRGB's, so it is not relabeled as sRGB.
Unreadable or oversized profile (above 4 MiB), Lab profiles Rejected under srgb (ImageCapabilityException).
sRGB matrix tags plus a device-to-PCS LUT (A2B0-A2B2, D2B0-D2B2) Not treated as sRGB; converted, because a color engine uses the LUT, not the matrix.
Untagged CMYK Converted by the working-colorspace step without a profile (approximate) under either policy.

A job whose inputs need conversion runs only on a backend with verified color management; if the first configured backend has none, the next one that does is used. If no backend can convert, the job fails with ImageCapabilityException naming the color space and the ignore opt-out. The package never pretends to have converted.

With ignore, pixel values are used as they are and profiles are discarded.

Recognizing sRGB

Whether a profile is sRGB-equivalent is decided without a color engine (Color/IccProfile): RGB matrix profiles are compared on their D50 colorants and on all three tone curves. Both must match; sRGB colorants with a linear curve (scRGB) are not sRGB. Profiles with a device-to-PCS LUT (A2B0-A2B2, D2B0-D2B2) are never assumed to be sRGB, even when their matrix tags look like sRGB, because a color engine uses the LUT instead. The tolerances are derived from independent sRGB profiles (IEC 61966-2.1 derivatives, Ghostscript, LittleCMS, Compact ICC), which differ by at most about 0.0002.

Conversion

Output

Outputs contain sRGB pixel values and never describe another color space:

Capability

capabilities()['color_management'] names the first backend whose conversion is verified with a real Display P3 sample (rgb(200, 60, 60) in P3 must become rgb(217, 42, 52) in sRGB, the LittleCMS reference). An engine that lists a color delegate but ignores profiles fails this check. GD has no color management.

Alpha and flattening

Alpha-preserving formats keep transparency according to the package's output contract.

Formats without alpha are flattened onto a configured background.

The default background is:

An output may override it when the selected output format does not preserve alpha:

The package normalizes backend-specific transparency state before transformations so palette transparency and hidden color-key behavior do not leak into public output semantics.

Multi-frame and animated images

Multi-frame content is detected where the package can determine it reliably from the source container.

The current header logic covers relevant cases such as:

Default behavior is conservative:

The caller must explicitly request first-frame rendering.

This prevents an animated image from quietly becoming a still image because a backend happened to expose only one frame.

The package does not currently provide full animation-preserving transformation.

Write safety model

save() and saveString() separate image production from target commit.

Phase 1

For every requested output:

If any output fails during this phase:

Temporary files are removed on every exit before publishing has completed, independently of how the failure arose. Releasing engine resources is best-effort and never throws, so cleanup cannot mask the original failure.

Temporary files are named .{target}.{random}.tmp next to their target. Removal is best effort: if the filesystem refuses an unlink, the file stays behind and is safe to delete. This also applies to the temporary name of a no-clobber output after publishing, which is a second hard link to the published file.

Before phase 1

Phase 2

After every output is complete and verified, targets are published:

  1. Outputs with 'overwrite' => false first, in output order. Each is published with an atomic create-if-absent (link() from the temporary file, then the temporary name is removed). A target created by another process after the early check is detected here and never replaced.
  2. Outputs with 'overwrite' => true next, in output order, each with an atomic rename() over the target.

If publishing fails:

Because no-clobber outputs are published first, a target conflict never leaves an already replaced existing file behind.

Atomic no-clobber publishing requires hard-link support in the target filesystem (ext4, XFS, NTFS, and most others). Without it, no-clobber outputs fail with ImageWriteException rather than silently degrading to a racy existence check.

The exception exposes:

so the caller knows exactly what happened.

Directory behavior

The package does not create target directory trees automatically.

The caller owns filesystem layout and must ensure the destination directory exists.

That keeps image processing separate from application storage policy.

Errors and exceptions

The package distinguishes bad image input, missing runtime capability, partial file commits, developer misuse, and ordinary runtime/IO failure.

ImageInputException

Use this for image content that is rejected.

Typical causes include:

This is the exception most likely to be translated into a validation error when the source came from an untrusted user.

ImageCapabilityException

Signals that the current runtime cannot satisfy the requested image contract.

Typical causes include:

The package never silently substitutes another format.

ImageWriteException

Signals that finished outputs could not all be published to their targets.

It exposes:

Remaining temporary files are removed before it is thrown (best effort; see Write safety model).

If save() throws any exception other than ImageWriteException (or its subclass), no target file was touched.

ImageTargetExistsException

Extends ImageWriteException. Signals that an output with 'overwrite' => false found its target occupied.

When detected before processing, nothing was written. When detected at publish time (another process created the target meanwhile), committed() lists only newly created no-clobber targets; no existing file was replaced.

InvalidArgumentException

Used for developer misuse such as:

RuntimeException

Used for ordinary IO or backend failures that are not rejected image content or capability mismatches.

CitOmni's normal fail-fast policy applies.

Configuration

The provider contributes baseline configuration under:

Current defaults:

Host applications may override these values through the normal CitOmni configuration merge.

backends

Ordered list of backend identifiers.

The first available backend able to decode every input and encode every requested output format handles the job. Unavailable backends are skipped.

The built-in value is:

Use ['imagick', 'gd'] to prefer Imagick, or ['gd'] to disable it.

The backend list is a list value and should be treated as a replacement when overridden, not as a list to be deep-merged item by item.

max_pixels

Maximum allowed source or output pixel area.

Default:

background

Default flatten color for output formats without alpha.

Default:

color

Default color policy for every call: srgb (convert to sRGB with color management) or ignore (keep pixel values). The per-call option color overrides it. See Color management.

JPEG

Defaults:

PNG

Default lossless zlib compression:

WebP

Default lossy quality:

AVIF

Defaults:

These defaults do not make AVIF available.

Actual AVIF support still depends on the active backend and runtime codec verification.

speed ranges from 0 (slowest, smallest) to 9 (fastest), the range every backend honors (libaom cpu-used, ImageMagick heic:speed). It is honored where the encoder supports it.

HEIC

Default lossy quality:

Backend model

Backends are internal implementation seams.

The public service selects one configured backend that can perform the complete job:

A single job is not split across several backends.

That keeps one source decode, one pixel model, and one deterministic processing path for the complete output set.

The backend interface is intentionally marked @internal.

External applications and packages should depend on:

not on backend classes or native engine handles.

Determinism

For the same source bytes, same options, same configuration, and same relevant backend/runtime versions, the package aims for deterministic processing semantics.

That includes:

Byte-identical output across unrelated codec/library versions is not guaranteed.

Codec implementations are allowed to evolve. Geometry and public semantics are not allowed to become vibes.

Performance notes

Image processing is CPU- and memory-intensive by nature, so the package deliberately avoids unnecessary work.

Current design choices include:

JPEG shrink-on-load (decoding at 1/2, 1/4, or 1/8 scale) is intentionally not used yet: choosing one decode scale for the whole job would make a thumbnail's pixels depend on which larger siblings were requested. It can be added per output scale without breaking sibling independence.

This favors low runtime overhead without making one output depend on which sibling outputs happened to be requested.

Current limitations

The implementation intentionally stays narrower than a full imaging suite.

Not currently provided:

Known edge behavior:

The public API is backend-independent so additional engines and capabilities can be introduced without exposing their native objects to callers.

Testing

Run the regression suite with:

The current Composer test script runs:

service_test.php and write_test.php pin the GD backend. imagick_test.php covers the Imagick backend and GD/Imagick parity, and skips itself when ext-imagick is not loaded. Its HEIC container tests use the runtime's HEIC encoder when present and the embedded HEIC sample on decode-only builds. color_test.php covers ICC classification, profile extraction for every container, the color policy on GD, and conversions on Imagick checked against LittleCMS reference values; its Imagick part skips without ext-imagick or LittleCMS.

The suite covers areas including:

Diagnostic capability probes live separately under:

They are useful for understanding a concrete server's image stack and are not a replacement for regression tests.

tests/probes/imagick-heif-stream-probe.php answers one specific question for the current runtime: can ImageMagick decode HEIC/AVIF from a PHP stream? Neither ImageMagick 6 nor 7 can (verified on 6.9.12 and 7.1.1: the HEIF coder opens the file by name), which is why the Imagick backend reads HEIF files into memory first.

Running the suite on a server without shell access

tests/probes/run-tests.php runs the real regression scripts through the web server, so the server's actual GD/ImageMagick build is tested through the package code:

  1. Upload the package's src/ and tests/ directories (tests are not part of the Composer dist archive) to a non-public or temporary web directory.
  2. Set RUNNER_ENABLED to true in the runner.
  3. Open run-tests.php?test=imagick (or geometry, header, service, write).
  4. Set RUNNER_ENABLED back to false and delete the uploaded files.

The runner refuses to run while disabled, accepts only the five known test names, and prints the failing check with its location.

For syntax validation during development:

On Windows .cmd or .bat files, use %%f instead of %f.

Internal structure

Current source layout:

The boundaries are intentional:

There is no Repository layer because this package has no SQL.

There are no Controllers or Commands because transport adapters are outside the package's responsibility.

Coding and architectural principles

citomni/image follows CitOmni's normal architecture and coding discipline.

In particular:

Coding & Documentation Conventions

All CitOmni projects follow the shared conventions documented here:

CitOmni Coding & Documentation Conventions

License

CitOmni Image is open-source under the MIT License.

See LICENSE.

Trademark notice: "CitOmni" and the CitOmni logo are trademarks of Lars Grove Mortensen. Usage of the name or logo must follow the policy in NOTICE. Do not imply endorsement or affiliation without prior written permission.

Trademarks

"CitOmni" and the CitOmni logo are trademarks of Lars Grove Mortensen.

You may make factual references to "CitOmni", but do not modify the marks, create confusingly similar logos, or imply sponsorship, endorsement, or affiliation without prior written permission.

Do not register or use "citomni" or confusingly similar terms in company names, domains, social handles, or top-level vendor/package names.

For details, see NOTICE.

Author

Developed by Lars Grove Mortensen (c) 2012-present.

CitOmni - low overhead, high performance, ready for anything.

All versions of image with dependencies

PHP Build Version
Package Version
Requires php Version ^8.5
ext-gd Version *
ext-zlib Version *
citomni/kernel Version ^1.0.2.2
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package citomni/image contains the following files

Loading the files please wait ...