Dadlab
December 8, 2025, 6:07pm
1
I’ve only recently started using Picard and it’s been working wonderfully so far.
However, I’m running into an issue with fetching high resolution cover art for my albums. Here are my settings :
This works as expected for most releases.
The issue I have happens when the highest available resolution for a cover (the original size) is lower than 1200px. Let’s say my album’s cover highest available size is 1000px. To my understanding, Picard would then fall back to the next lower thumbnail size available (500px) without comparing it to the original size.
It would be nice to have an option to set a “target” cover size to make sure that covers across the board are as close to the desired resolution as possible.
1 Like
Zas
December 9, 2025, 4:36pm
2
It is implemented already in Picard 3 (not yet released), along a lot of improvements in this field.
master ← twodoorcoupe:image_filtering
opened 10:08AM - 30 May 24 UTC
# Summary
* This is a…
* [ ] Bug fix
* [x] Feature addition
* [ … ] Refactoring
* [ ] Minor / simple change (like a typo)
* [ ] Other
* **Describe this change in 1-2 sentences**:
Adds a setting to discard downloaded cover art images if they are below a given width and height.
# Problem
* JIRA ticket (_optional_): PICARD-2926
# Solution
The options page looks like this:
I plan to add settings for resizing and converting formats also to this page.
I created an extension point for adding image filters. I'm aware this is bound to change for Picard 3, but I was thinking that I can use this for now, until the new plugin apis are defined, and change it later in the last couple of weeks of gsoc.
I'm still working on adding another extension point for filtering functions that use the image metadata, since outsidecontext suggested I should add a way for providers to filter images before actually downloading them, if they can.
# Action
Additional actions required:
* [ ] Update Picard [documentation](https://github.com/metabrainz/picard-docs) (please include a reference to this PR)
* [ ] Other (please specify below)
master ← twodoorcoupe:image_processing
opened 02:39PM - 07 Jun 24 UTC
# Summary
* This is a…
* [ ] Bug fix
* [x] Feature addition
* [ … ] Refactoring
* [ ] Minor / simple change (like a typo)
* [ ] Other
* **Describe this change in 1-2 sentences**:
Adds an option resize downloaded images down to a given width and height, if they are above the given size.
# Problem
* JIRA ticket (_optional_): PICARD-1241
Also these tickets are similar PICARD-237, PICARD-1663, PICARD-2783
# Solution
The feature is fully functional, I was planning to add multi-threading and other optimizations later.
The processing options page looks like this as of now, let me know if it's too cluttered.
The image processors extension point is a bit more complicated than the filters one, because we need to know if it's running for either embedded images or ones saved to an external file. We also need to know whether it's running for both with the same settings, in order to avoid running the same processor twice.
My idea was for new image processors to inherit from the `ImageProcessor` class and redefine its methods, similar to how new `OptionPage`s are handled.
Also, the `coverartimage` now has a `external_file_coverart` to store the image meant to be saved to an external file. This is necessary when the processing options for the two targets are different.
# Action
Additional actions required:
* [x] Update Picard [documentation](https://github.com/metabrainz/picard-docs) (please include a reference to this PR)
* [ ] Other (please specify below)
master ← twodoorcoupe:dont_replace_bigger_images
opened 02:19PM - 04 Jul 24 UTC
# Summary
* This is a…
* [ ] Bug fix
* [x] Feature addition
* [ … ] Refactoring
* [ ] Minor / simple change (like a typo)
* [ ] Other
* **Describe this change in 1-2 sentences**:
Adds an option in the "Cover Art" options page to never replace embedded cover art with smaller images of the same type.
# Problem
* JIRA ticket (_optional_): PICARD-1477
# Solution
At first I tried to implement this as a filter, but I hit a wall. So I had to move the logic inside `coverart/__init__.py`. Now when an image is downloaded, it checks if there was an image of the same type embedded into tags and if it was bigger.
I'm not entirely convinced by this solution either, in fact I'm still not sure how multiple images of the same type should be handled. For example, if a file has multiple "booklet" type images embedded, what size should I compare the downloaded image with? Maybe the minimum among images of the same type?
# Action
Additional actions required:
* [x] Update Picard [documentation](https://github.com/metabrainz/picard-docs) (please include a reference to this PR)
* [ ] Other (please specify below)
Plus few other changes.
Picard 3 should reach alpha stage soon.
8 Likes
