jwagner / smartcrop.js

Content aware image cropping
http://29a.ch/2014/04/03/smartcrop-content-aware-image-cropping
MIT License
12.84k stars 577 forks source link

Smartcrop is failing in latest ImageMagick #139

Open contactsmrajesh opened 1 month ago

contactsmrajesh commented 1 month ago

smartcrop is working fine if we are using ImageMagick version 7.1.1-15, but with latest versions 7.1.1-36/7.1.1-38 it is failing with below error,

Error: Stream yields empty buffer at Socket. (C:\smart\smartcrop\node_modules\gm\lib\command.js:57:17) at Socket.emit (node:events:531:35) at endReadableNT (node:internal/streams/readable:1696:12) at process.processTicksAndRejections (node:internal/process/task_queues:82:21)

There were some earlier issues addressed as below, not sure whether it is related to this new one, https://github.com/jwagner/smartcrop-cli/issues/13

jwagner commented 1 month ago

Please include all the steps necessary to reproduce the issue you are reporting. If the issue depends on the environment the code is running in and not just on the smartcrop code please include a Dockerfile to reproduce the issue.

contactsmrajesh commented 1 month ago

Thanks for looking into this issue.

Please find details below,

Node: 20.15.1 Smartcrop cli: 2.0.3 ImageMagick: 7.1.1.36 Operating System: Windows 11

Steps to reproduce the issue in windows,

  1. Navigate to folder in where node/smartcrop is installed, ex: C:\work\node\node_modules\smartcrop\node_modules\smartcrop-cli
  2. Run command, "node smartcrop-cli.js C:\work\testdata\images\test1.jpg"

with magick version: 7.1.1-15 (working)

cmd: node smartcrop-cli.js C:\test\images\test1.jpg

{ "topCrop": { "x": 0, "y": 1992, "width": 4000, "height": 4000, "score": { "detail": 1427.5076370436789, "saturation": 1273.325115335588, "skin": 480.27623705773163, "boost": 0, "total": 0.00009574976804458306 } } }

with magick version: 7.1.1-36 (failing)

cmd: node smartcrop-cli.js C:\test\images\test1.jpg

Error: Stream yields empty buffer at Socket. (C:\work\smartcrop\node_modules\gm\lib\command.js:57:17) at Socket.emit (events.js:327:22) at endReadableNT (_stream_readable.js:1220:12) at processTicksAndRejections (internal/process/task_queues.js:84:21)

contactsmrajesh commented 1 month ago

In addition, I am not sure whether below is full equivalent of smartcrop command to imagemagick, but when I try below using the latest imagemagick as standalone command it works fine,

magick convert C:\work\testdata\images\test1.jpg -crop 4000x4000+0+1992 -resize 4000x4000 -unsharp 2x0.5+1+0.008 -colorspace sRGB -auto-orient -strip -quality 90 C:\work\testdata\images\test1_cropped.jpg

contactsmrajesh commented 1 month ago

The problem is, latest image magick versions removed support to legacy "convert" command, it expects command to be "magick".

To fix this, performed below actions,

  1. Force gm to use "magick" comand, this is done by modifying to below code in, smarcrop-cli.js, index.js(smartcrop-gm), example.js(smartcrop-gm) var gm = require('gm').subClass({ imageMagick: '7+' });
  2. Upgraded gm to latest version 1.25.0 and also its corresponding dependencies.

After above 2 fixes, it is working fine.

Request to review whether these changes can be implemented.

jwagner commented 1 month ago

The issue with setting imageMagick to 7+ is that it will likely break for a lot of users. Debian (other than experimental) is still on magick 7.

As a short term remedy I added a comment to smartcrop-cli clarifying that it requires imagemagick 6.

I think longer term the dependency on imagemagick/gm probably just isn't a good idea.

The main alternative would be sharp. But even after v0.33 there is no 1.x release of sharp with a stable api (according to semver).

The canvas package could be an option but it's dependencies make it a bit of a pain for users as well.

Jimp would be nice because it is pure JS, but it's performance is a concern.

None of these seem like nice options to me. I'm open for suggestions.

contactsmrajesh commented 1 month ago

I agree with your point that short term continue with imagemagick/gm. But long term believe migrating to sharp would be better given its performance advantage and large user base.