getgrav/grav

Consider alternatives to Gregwar/Image for image manipulation

Open

#983 opened on Aug 16, 2016

View on GitHub
 (17 comments) (3 reactions) (0 assignees)PHP (15,491 stars) (1,409 forks)batch import
enhancementhacktoberfesthelp wanted

Description

I'm having a good time working with Grav for a new site! The biggest pain point I've encountered so far (that wasn't fixed in the 1.1 release) is the image processing pipeline. The API that Grav provides with the help of Gregwar/Image is neat, and I realize it's a pretty big selling point for Grav as well. But I've encountered two issues with Gregwar/Image that are kind of blocking for my use case.

Firstly, there's color profile handling. Although Gregwar/Image has an extensible back-end, there's only an implementation for GD. And GD doesn't deal with image metadata, meaning it won't embed any other color profiles than the default sRGB when writing files. Images that were initially rendered with eg. an Adobe RGB color profile loose luster because of this, and while this may seem like just a nuisance, it really is a deal breaker for some people.

Secondly, GD doesn't perform all that well. GraphicsMagick for example should be a better candidate if you want to optimize for performance. Even though the performance of Gregwar/Image isn't the fault of Grav, it affects the perception of Grav's overall performance. I have an image heavy page on the site I'm building (about 70 images á 2500px in width), and when generating that page from scratch, PHP times out with the default execution timeout setting of 30s.

And as an additional note, these issues don't seem to be addressed any time soon, since development on Gregwar/Image seems pretty stale. There isn't much activity in the issue tracker, or on the commit front (the latest commits up until just recently were from November/December last year). The color profile issue has been brought up in https://github.com/Gregwar/Image/issues/101, but no solution has been suggested yet.

I understand that swapping out Gregwar/Image is probably a pretty major decision, but maybe an API compatibility layer could ease such a transition.

I'm not sure what the best alternative is, but avalanche123/Imagine seems like a more mature and capable option. It supports color profiles and has different back-end implementations for GD, ImageMagick and GraphicsMagick.

Contributor guide

Tech stack
None
Domain
backend
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
4
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Grav development setupUnderstanding of Grav's image APIKnowledge of PHP image manipulation
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
20
Research direction
Investigate the current image handling in Grav, particularly the use of Gregwar/Image. Evaluate the Imagine library as a replacement, focusing on color profile support and performance. Check if there are any existing attempts or discussions about this in the repository. Consider creating an abstraction layer to ease migration.