Grafika – An image processing library for PHP

[vatotemking]

Kinda discouraging that everytime I post this lib I am always asked: "there is already imagine, imageXX etc lib out there. why another lib?" I feel like I violated some code of honor or something.

Just to be clear, here's why I made it:

- it aims to be an image processing lib. Not a an image manipulation lib which is just a small subset of image processing. Big difference. Also I fell in love with image processing. :-)

- Smart crop. Not present in other libs. I am surprised that in PHP cropping an image is a fairly common requirement. Yet none of the existing libs have it. I found one from an obscure drupal extension.

- Image compare. Not present in other libs. Fairly important and needed feature esp for CMS yet none existed.

- Advance filters. The default ones provided by GD and Imagick (not ImageMagick) are very basic filters. Right now only Sobel filter is implemented, more will be added in the future.

- Bezier Curves. Imagick is good but GD does not have it so I implemented a bezier curve algorithm manually porting it from a c++ code.

The future

- Seam carving

- More edge filters

- Full anti-aliased shapes and curves in GD. GD does not support anti-aliasing on all its shapes.

- Perhaps face detection but we'll see..

I think this is a worthy library to check out. Might not be for everyone though..

[CiPHPerCoder]

> Kinda discouraging that everytime I post this lib I am always asked: "there is already imagine, imageXX etc lib out there. why another lib?" I feel like I violated some code of honor or something.

Y'know how people say, "Don't reinvent the wheel?" The emphasis should be on the.

Don't reinvent THE wheel.

Feel free to invent a better wheel.

Better here can mean simpler, which allows users to be more productive. As far as I can tell, you've accomplished this much. So, good job, and thanks for sharing.

[tangue]

It's a classic but let's quote Jeff Wood : * Indeed. If anything, "Don't Reinvent The Wheel" should be used as a call to arms for deeply educating yourself about all the existing solutions – not as a bludgeoning tool to undermine those who legitimately want to build something better or improve on what's already out there. In my experience, sadly, it's much more the latter than the former.*

https://blog.codinghorror.com/dont-reinvent-the-wheel-unless...

[jlg23]

If you keep getting asked the same question, why not put this list of reasons on the lib's homepage? What you have on the page now is not convincing (I'd just create a function for your first example and I don't care about the syntax you show off in the second example) - but the points you made here are good selling points!

[pierrej]

Haters gonna hate.

There are a lot of room for new libs. Gfx needs are infinite. No single library can cover all needs fitting everyone requirements.

Interop between each is the key. And competion leads to success.

Stay tuned with gd 2.3 btw from a (much better aa pov along other things:)

[Jemaclus]

Don't listen to the haters. :)

One thing I'm interested in is blurring. Blurring seems to be pretty CPU intensive, but I'm hoping there's a better way to do it. Right now, I'm using Intervention Image, but I routinely have to blur photos which can take upwards of 2-3s per image (especially for larger ones). Maybe that's something you could tackle? :)

[oofoe]

For what it's worth, just being able to chain the calls makes this worthwhile. Thanks for making the effort and taking the time to release it!

[dubcanada]

I know your reasoning is I should make a new library because X and Y don't exist in the existing ones. But really what most people think of is why not just send a pull request to the existing ones with that new functionality?

[pierrej]

Side notes you may update your comparisons using latest GD. imagescale, rotate or affine, which do what you said about 15yo copyresampled

[mitchellmckenna]

I think it would be helpful to include this information on the project website.

[donatj]

Not a big fan of the API here.

I had a teacher that called this "knocking", so that's what I call it. It's better known though as the Sequential Coupling Antipattern[1]. e.g.: Requiring methods to be called in a particular order.

The following works:

  $editor = Grafika\Grafika::createEditor();
  $editor->open( "/Users/jdonat/Desktop/Screen Shot 2016-07-25 at 11.33.53 AM.png" );
  $editor->resizeExact( 200, 200 );
  $editor->save( "edited.jpg", null, 90 );

Whereas this throws `Fatal error: Uncaught exception 'Exception' with message 'No image to edit.' in /private/tmp/grafika/src/Grafika/Gd/Editor.php on line 1056`

  $editor = Grafika\Grafika::createEditor();
  $editor->resizeExact( 200, 200 );
  $editor->open( "/Users/jdonat/Desktop/Screen Shot 2016-07-25 at 11.33.53 AM.png" );
  $editor->save( "edited.jpg", null, 90 );

Required parameters should be required on the constructor, not on a setter. That's basically just requiring someone to know your secret handshake to use your API.

I'd say in general you'd be better off restructuring this to defer GD/ImgMagick selection until it's actually needed, eg: calling save. I'd personally defer applying any of the filters until save.

Also the static factory is gross and old-school php, I'd avoid that.

1. https://en.wikipedia.org/wiki/Sequential_coupling

[ec109685]

RAII is another way of putting this. You could use a builder pattern to setup your class, build it and then start deriving value from the object.

Mutable objects that incorporate behavior are largely evil.

[reitanqild]

What about when you want to resize multilple images using the same editor then?

[philippz]

Does it solve some "harder problems" in image processing (at least regarding PHP) like: WebP & WebM support or resizing animated gifs? What are the supported file formats?

[runamok]

How does one "smart crop"? The crop method only seems to allow you to crop 1 portion of a 3 x 3 grid...

Thanks for your creation!

[xchip]

"Telling a programmer there's already a library to do X is like telling a songwriter there's already a song about love." @counternotions (seen in twitter)

[jasonlotito]

Does it support animated GIFs?

[arash_milani]

I think someone should change the title to indicate that it is a PHP library. "Grafika is an image processing library for PHP"

[Mahn]

Aha, so that's why it made it to the front page. Had it had PHP in the title from the beginning HN would have ignored it completely (sadly).

[bhouston]

Does this support uint16, fp16 and fp32 channel resolution for dealing with hdr, tiff, and exr images?

Can it maintain that bit-depth while applying image operations?

I find this is where ImageMagick and GraphicsMagick falls down (it converts everything to 8bit images upon read) which was fine a decade ago, but not now.

It blows my mind that nearly all image processing libraries in wide usage are uint8 per channel.

[allendoerfer]

> Grafika is an image processing library for PHP. It can be used to resize, crop, compare, and add watermark on images. It can also create texts, geometric shapes, and apply filters. Its built on top of Imagick and GD.

First paragraph.

[gondo]

why yet another image library? what is the difference between existing solutions?

random google search results: http://image.intervention.io/ http://imanee.io/ https://imagine.readthedocs.io/en/latest/ https://packagist.org/search/?tags=image%20manipulation ...

[vatotemking]

It has smart crop based on entropy, ability to compare images, and bezier curves for GD which none of the existing libs have. Other libs are "image manipulation" this one aims to be an "image processing" lib. Also we need libs instead of new programming languages.

[usaphp]

Why yet another commenter who does not bring anything new to the discussion unlike the OP's image library?

[kgabis]

Maybe he didn't like other libraries? There are many reasons why you would want to write a new library. Fun is one of them.