WAIT — Stale — last commit 3y ago

• 13 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Concentrated ownership — top contributor handles 65% of recent commits
• ⚠ Scorecard: marked unmaintained (0/10)
• ⚠ Scorecard: default branch unprotected (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

Imaging is a Go image processing library that provides a unified API for common operations (resize, rotate, crop, brightness/contrast adjustment, etc.) on any image type implementing the image.Image interface, returning processed results as image.NRGBA. It includes 14+ resampling filters (Lanczos, CatmullRom, Gaussian, etc.) optimized for both quality and performance, with support for EXIF orientation correction via the io.go module. Flat single-package structure: core processing logic in adjust.go (brightness/contrast/gamma), convolution.go (blur/sharpen kernels), resize.go (resampling), effects.go (color shifts/saturation), histogram.go (analysis), io.go (EXIF/encoding), and scanner.go (pixel iteration utilities). Tests are co-located (_test.go files) with their subjects, and testdata/ contains golden PNG/JPG files for regression validation.

Go backend developers and CLI tool authors building image processing pipelines who need production-grade resizing and filtering without external C dependencies or ImageMagick bindings; particularly those handling web uploads, thumbnail generation, or batch image transformations.

Production-ready and stable. The codebase has comprehensive test coverage (adjust_test.go, convolution_test.go, resize_test.go, etc.) with golden-file validation in testdata/, Travis CI configured (.travis.yml), and appears well-maintained with no signs of abandonment. The lack of recent commit information suggests it's stable rather than actively evolved, which is appropriate for a mature utility library.

Very low risk. Single dependency on golang.org/x/image (a stable, official Go project), no version constraints beyond that, clean Go module setup (go.mod/go.sum present). Main risk is single-maintainer dependency (disintegration org), but the codebase is self-contained and unlikely to require frequent updates. No breaking changes visible in the file structure.

No active development visible from the file list. This is a stable, feature-complete library in maintenance mode. The test suite and golden files (out_*.png) suggest past iterations of filter tuning, but no pending work is evident.

go get -u github.com/disintegration/imaging
cd $(go list -m -json github.com/disintegration/imaging | jq -r .Dir)
go test ./...

Daily commands: This is a library, not a runnable application. Use it as a dependency: go get github.com/disintegration/imaging, then import and call functions like imaging.Resize(src, w, h, imaging.Lanczos). Run tests with go test ./... from the repo root.

• resize.go — Core resizing engine with multiple filter algorithms (Lanczos, CatmullRom, Linear, Nearest); fundamental to the package's image processing pipeline.
• transform.go — Implements rotation, flipping, and cropping transformations; essential geometric operations used across the codebase.
• convolution.go — Kernel-based image processing (blur, sharpen); implements the mathematical foundation for many effects.
• adjust.go — Brightness, contrast, saturation, hue, and gamma adjustments; core color space manipulation functions.
• io.go — Image I/O operations including EXIF orientation handling; entry point for loading/saving images with format detection.
• scanner.go — Efficient pixel-level iteration abstraction; enables high-performance traversal needed by all processing functions.

• io.go (Image I/O) (image/png, image/jpeg, image/gif, x/image/bmp) — Load images from disk, detect format, apply EXIF orientation, save to disk
  • Failure mode: Corrupted output if EXIF orientation is misread; silent lossy conversion if format is unknown
• resize.go (Resampling Engine) (Float64 kernel weights, bounds checking, interpolation math) — Resample images using Lanczos, CatmullRom, Linear, or Nearest-Neighbor filters
  • Failure mode: Visible artifacts at image edges; aliasing if filter is too aggressive; blurring if too conservative
• transform.go (Geometric Transforms) (Matrix math, coordinate remapping, canvas filling) — Rotate, flip, crop, and fill images with specified dimensions and anchor points
  • Failure mode: Off-by-one errors in crop boundaries; incorrect rotation origin; edge pixels discarded
• convolution.go (Kernel Filters) (Kernel definitions (tools.go), neighborhood sampling, edge clamping) — Apply 2D convolution kernels for blur, sharpen, and edge detection
  • Failure mode: Ringing artifacts at high frequencies; oversaturation of edges; slow for large kernels
• adjust.go (Color Adjustments) (RGB↔HSV color space conversion, lookup tables, channel arithmetic) — Modify brightness, contrast, saturation, hue, and gamma across pixel channels
  • Failure mode: Hue wraparound at 0°/360°; gamma inversion artifacts; clipping in highlight/shadow recovery
• scanner.go (Pixel Iteration) (Memory-aligned scanning, bounds checking) — Efficient row and column iteration patterns for pixel-level operations
  • Failure mode: Incorrect bounds if width/height is 0; memory overflow if coordinates exceed image dimensions

• Disk (PNG/JPEG/GIF file) → io.Open() — Read encoded image file and decode using x/image codec
• io.Open() → NRGBA conversion — Convert decoded image.Image to 32-bit non-premultiplied NRGBA

Add a new image filter or effect

1. Add the filter logic to effects.go or create a new file (e.g., filters.go). Follow the pattern of existing functions like Blur, Sharpen, or Sepia. (effects.go)
2. If your filter uses a convolution kernel, define it in tools.go or add helper math functions to utils.go. (tools.go)
3. Create unit tests in effects_test.go with at least one golden file comparison in the testdata directory. (effects_test.go)
4. Export your function as a public API in doc.go with a brief doc comment. (doc.go)

Add a new geometric transformation

1. Implement the transformation in transform.go following the pattern of Rotate, Flip, or Crop functions. (transform.go)
2. Use scanner.go utilities (e.g., ScanLines) for efficient pixel iteration if needed. (scanner.go)
3. Add comprehensive tests to transform_test.go with edge cases (e.g., rotation angles, crop boundaries). (transform_test.go)

Add support for a new image format or I/O feature

1. Extend io.go to detect and handle the new format in Open() and Save() functions. (io.go)
2. Add test cases in io_test.go with sample files in the testdata directory. (io_test.go)

• golang.org/x/image — Provides image decoding/encoding and color space primitives (YCbCr, NRGBA) used throughout the pipeline
• NRGBA color model — Non-premultiplied alpha avoids color bleeding artifacts and simplifies channel math in adjustments
• Kernel-based convolution — Unifies blur, sharpen, and edge detection under a single efficient mathematical framework
• image.Image interface — Allows zero-copy acceptance of any image type (JPEG, PNG, GIF, etc.) without conversion

• *Always output image.NRGBA (32-bit RGBA)

  • Why: Simplifies the API and guarantees consistent behavior across all filters
  • Consequence: Memory overhead for indexed or grayscale inputs; users cannot preserve original format or bit depth

• Lanczos and CatmullRom resampling via 4×4 kernels

  • Why: High quality resizing for both enlargement and reduction with acceptable CPU cost
  • Consequence: Slower than nearest-neighbor; not suitable for real-time video; edge pixels handled with clamping (potential artifacts)

• Scan-line based pixel iteration (scanner.go)

  • Why: Better cache locality and reduced function call overhead for row-major processing
  • Consequence: Architectural constraint; some algorithms harder to parallelize; sequential by design

• No premultiplied alpha channel support

  • Why: Simplifies color math and avoids common alpha-blending bugs
  • Consequence: Cannot process images with premultiplied alpha without conversion; incompatible with some professional pipelines

• Real-time video processing (no streaming, frame-by-frame only)
• Parallel or GPU acceleration (single-threaded CPU operations)
• Preserving image metadata beyond EXIF orientation
• 16-bit or floating-point color depth (32-bit NRGBA only)
• Advanced image composition or blending modes
• Support for animated image formats (GIF, APNG)
• Color profile or ICC calibration handling

No environment variables or external service dependencies. Watch out for: (1) EXIF orientation is only applied by io.Open(), not when using image.Decode() directly—users must use the library's io module for correct orientation; (2) resampling filters have different computational costs (Lanczos is ~100x slower than NearestNeighbor), so filter choice heavily impacts throughput in batch pipelines; (3) all operations return new *image.NRGBA even for no-op transformations, creating memory pressure on large images or tight loops—callers should consider pooling if memory-critical.

• Resampling filters (Lanczos, CatmullRom, Gaussian) — The library's core value proposition—understanding filter trade-offs (quality vs. speed) is essential for choosing resize parameters appropriately in real pipelines
• Convolution kernels — Powers blur, sharpen, and edge detection; understanding how kernels slide over pixels explains the convolution.go implementation and allows custom filters
• EXIF orientation metadata — Real smartphone/camera images include EXIF Orientation tags that must be applied post-load; io.go handles this correctly but direct image.Decode() does not—critical for correctness
• Non-premultiplied alpha (NRGBA) — All operations return *image.NRGBA explicitly; understanding why (premultiplied math breaks color adjustments) is key to avoiding alpha blending bugs when compositing results
• Cubic interpolation (Mitchell-Netravali, CatmullRom) — Mid-tier resampling quality between linear and Lanczos; understanding cubic spline math helps tune filter selection for specific image types
• Hue-Saturation-Value (HSV) color space conversion — effects.go implements color shifts via HSV rotation; understanding RGB↔HSV conversion is needed to modify or extend color adjustment functions

• h2non/bimg — Alternative Go image library backed by libvips C bindings; much faster for heavy lifting but heavier weight and external dependencies—compare if performance critical
• kolesa-team/go-psd — Photoshop PSD file parser for Go; complementary if pipeline needs to read PSD inputs before processing with imaging
• davidbyttow/govips — Modern Go wrapper around libvips with similar high-level API to imaging but C-backed performance; closest alternative for production imaging pipelines
• golang/image — Official Go standard library package that imaging extends; provides base image.Image interface, color models, and JPEG/PNG codecs that this library depends on

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add EXIF orientation auto-correction in io.go

The testdata directory contains orientation_0.jpg through orientation_8.jpg, suggesting EXIF orientation support exists or is planned. However, io.go likely doesn't automatically apply EXIF orientation corrections when loading images. This is a common user pain point - photos loaded from cameras appear rotated incorrectly. Adding auto-correction based on EXIF Orientation tag would be high-value for real-world usage.

• [ ] Examine io.go to understand current image loading implementation
• [ ] Add EXIF orientation detection using golang.org/x/image/tiff or similar
• [ ] Implement auto-rotation in the image loading path based on EXIF Orientation tag (1-8)
• [ ] Add unit tests in io_test.go covering all 8 EXIF orientations using existing testdata files
• [ ] Update README.md with example of EXIF orientation handling

Add comprehensive edge case tests for resize.go with various aspect ratios

The testdata includes out_fill_center.png, out_fill_left.png, out_fill_right.png, and various out_resize_*.png files, but resize_test.go likely lacks exhaustive coverage of edge cases. Testing extreme aspect ratios (very wide/tall images), single-pixel dimensions, and combinations with different resample filters would catch subtle bugs and regressions.

• [ ] Review resize_test.go to identify missing edge case coverage
• [ ] Add test cases for extreme aspect ratios (e.g., 1000x1 resized to 100x100)
• [ ] Add test cases for very small target dimensions (e.g., resize to 1x1, 2x2)
• [ ] Add parameterized tests combining all resample filters (Nearest, Linear, Catrom, Lanczos) with edge case dimensions
• [ ] Add golden file comparisons for regressions using testdata reference images

Migrate .travis.yml to GitHub Actions workflow for modern CI/CD

The repo uses Travis CI (.travis.yml), which is legacy. GitHub Actions is the modern standard for GitHub-hosted projects and provides better integration, faster builds, and no external service dependency. This improves maintainability and reduces CI friction for contributors.

• [ ] Create .github/workflows/test.yml with Go matrix testing (1.13+, latest stable versions)
• [ ] Add test coverage reporting step with codecov or coveralls integration
• [ ] Add Go linting step using golangci-lint for code quality checks
• [ ] Ensure workflow tests against golang.org/x/image dependency versions from go.mod
• [ ] Remove .travis.yml and update README.md to reference GitHub Actions badge instead

• Add histogram equalization function in histogram.go: The histogram module exists but only provides analysis (Min, Max, Mean). Implement an Equalize() function matching the public API pattern and add golden-file tests in testdata/out_equalize_*.png.
• Extend convolution.go to support custom kernels: Users can only use predefined Blur/Sharpen. Add a ConvolveCustom(img image.Image, kernel [][]float32) *image.NRGBA function and test it with a simple edge-detection kernel like Sobel.
• Document filter performance trade-offs: The README mentions 14 filters but doesn't benchmark them or explain when to use each. Add a doc.go section or new performance_notes.md with concrete timings for resizing a 2000x2000px image with each filter, helping users choose appropriately.

The disintegration/imaging package is a pure image processing library with relatively low attack surface, but has significant security concerns centered around outdated dependencies and potential denial of service risks. The primary vulnerability is the use of golang.org/x/image from September 2019, which is severely outdated. Additionally, image processing operations on untrusted input require explicit safeguards against resource exhaustion attacks. No hardcoded secrets, injection vulnerabilities, or infrastructure misconfigurations were detected. Immediate action should be taken to update dependencies and add input validation and resource limiting mechanisms.

• High · Outdated Dependency with Known Vulnerabilities — go.mod. The golang.org/x/image dependency is pinned to version v0.0.0-20191009234506-e7c1f5e7dbb8, which is from September 2019. This is over 4 years old and may contain known security vulnerabilities. The x/image package handles image decoding and processing, which could be susceptible to denial of service attacks through malformed image files. Fix: Update golang.org/x/image to the latest stable version using 'go get -u golang.org/x/image@latest' and run 'go mod tidy'. Test thoroughly with the existing test suite to ensure compatibility.
• Medium · Potential Denial of Service via Image Processing — resize.go, transform.go, effects.go, io.go. The imaging package processes arbitrary image files from user input. Without explicit safeguards visible in the file structure, malformed or extremely large image files could cause excessive memory consumption or CPU usage, leading to denial of service. Image decoding operations in resize.go, transform.go, and effects.go may not have input validation or resource limits. Fix: Implement input validation including: maximum image dimensions checks, file size limits, memory allocation guards, and timeout mechanisms for long-running operations. Add explicit error handling for malformed images.
• Medium · No Visible Input Validation in IO Operations — io.go. The io.go file likely handles image file operations. Without visible input validation or sanitization in the file structure, the package may be vulnerable to path traversal or other file operation attacks if used in web contexts where user input directly influences file paths. Fix: Implement strict input validation for all file paths. Use filepath.Clean() and verify that resolved paths are within expected directories. Avoid accepting user input directly as file paths. Document security constraints for users of the package.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/disintegration/imaging shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live disintegration/imaging repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/disintegration/imaging.

What it runs against: a local clone of disintegration/imaging — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in disintegration/imaging | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 994 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of disintegration/imaging. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/disintegration/imaging.git
#   cd imaging
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of disintegration/imaging and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "disintegration/imaging(\\.git)?\\b" \\
  && ok "origin remote is disintegration/imaging" \\
  || miss "origin remote is not disintegration/imaging (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "resize.go" \\
  && ok "resize.go" \\
  || miss "missing critical file: resize.go"
test -f "transform.go" \\
  && ok "transform.go" \\
  || miss "missing critical file: transform.go"
test -f "convolution.go" \\
  && ok "convolution.go" \\
  || miss "missing critical file: convolution.go"
test -f "adjust.go" \\
  && ok "adjust.go" \\
  || miss "missing critical file: adjust.go"
test -f "io.go" \\
  && ok "io.go" \\
  || miss "missing critical file: io.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 994 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~964d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/disintegration/imaging"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.