Fetchart: taming cover art resolution


I can’t get fetchart / imagemagick to get cover art of a desired resolution.

My goal is to get cover art

  • 500–1,000 px wide; and
  • as close to square as possible but where the height may be 20% less that the width.

So, I configure the plugin like this:

    auto: yes
    cautious: no
    cover_names: cover front art album folder
    minwidth: 500
    maxwidth: 1000
    enforce_ratio: 20%
    sources: filesystem *
    google_key: <censored>

And yet I get these images:

  • 1,000 × 1,003 px
  • 1,000 × 1,004 px
  • 1,000 × 1,004 px
  • 1,001 × 1,000 px
  • 1,008 × 1,000 px
  • 1,012 × 1,000 px
  • 1,017 × 1,000 px
  • 1,062 × 1,000 px
  • 1,071 × 1,000 px
  • 1,114 × 1,000 px
  • 1,121 × 1,000 px
  • 1,135 × 1,000 px

What am I doing wrong? Does imagemagick leave those extra pixels when downsizing big images? Will I be alright if I do maxwidth: 950?

That seems very plausible! May I recommend giving 950px a try and seeing what you end up with?

Strangely, maxwidth: 900 returned an image 900px tall and 1060px wide. Shouldn’t 900px apply to the width? Now trying maxwidth:750 to leave a sufficient error margin.

Hmm; that is strange! Here’s our invocation of ImageMagick. In particular, it looks like this:

convert INFILE -resize MAXWIDTHx^> OUTFILE

Maybe it’s worth double-checking that that’s the right syntax for resizing to a maximum width?

Does the width value need to be in quotes? Here’s the imagemagick documentation.

By the way, here’s the image that gives me trouble. I’ve just fetched it with maxwidth: 750 and enforce_ratio: 20% and got this:


Interesting! Any chance you could try running a few different convert commands manually to see if the same dimensions result?

Hi Adrian.

Manual convert works as expected:

convert beatles.jpg -resize 1000 1000.jpg

= 1,000 × 845

convert beatles.jpg -resize 750 750.jpg

= 750 × 633

convert beatles.jpg -resize 500 500.jpg

= 500 × 422

convert beatles.jpg -resize 125 125.jpg

= 125 × 106

Looks like fetchart confuses height with width.

Sure—as I mentioned above, the invocation we’re using is like this:

convert INFILE -resize MAXWIDTHx^> OUTFILE

That is, concretely, something like:

convert beatles.jpg -resize '1000x^>' 1000.jpg

Does that seem to produce reliably incorrect outputs?

Alas. :slightly_frowning_face:

Sorry, I’m not sure I understand—does that format work as intended?

Apologies for my earlier reply, Adrian – I misunderstood the question. :blush:

No, MAXWIDTHx^> doesn’t work as intended:

convert beatles.jpg -resize 1000 1000.jpg

= 1,000 × 845, as intended, but

convert beatles.jpg -resize '1000x^>' 1000.jpg

= 1,184 × 1,000.

Aha! I suppose that means we found our culprit. Woohoo! :tada:

It looks like we were using the syntax that tells IM to resize the largest dimension down to 1000 pixels instead of the width. As the docs clearly say, the funky > syntax does exactly that. So the solution is probably to change our invocation in artresizer.py to use the simpler syntax.

Would you mind opening a pull request so we can get this fixed?

Will do. Thanks for guiding me through this.