Currently, there is no way to tell Picard what kind of image to use for the front cover art, and then it always uses the first cover marked ‘front’, nevermind it’s a front+stickers or front+obi one [[kenobi ? sorry about that ^^]]
So I’d like to propose a new setting in the cover art archives configuration, to give the choice of what kind of image is prefered (Front, Front+Stickers and Front+Obi).
I would imagine the setting like this:
In this example, the “Front” only is prefered, and then is there’s no 'Front only", the “Front+Obi” is returned. If there is a “Front+Stickers” it’s always ignored. I think it can suits all needs.
The more choice in Picard to handle the artwork the better.
For example - some releases will have Front, Back, Booklet, Medium and all kinds of artwork. (I know I upload a everything I can once I scan a release) But Picard just blindly looses all the differences and calls every image “cover.jpg”, “Cover(1).jpg” and so on. (Or am I missing something?)
The more we can select this in Picard the better.
Also remember - an expansion to your request would need to cover the BACK option. Some people want the BACK image with the Spines, other prefer a back without Spines.
So that would be a second setting: “Use Back Cover Prefered Order” with the same set of options, once again to cover all use cases. Maybe some will want “Front+Obi” and “Back+Stickers” first (strange configuration but why not )
First, thanks to people who expressed their opinion for this idea. As it seems it can be usefull, I went into the code and here is a quick report of my firsts findings.
Things are a bit more difficult than I would expect, because it’s my first contact with Picard code, but not impossible at all.
What’s need to be done, in order:
Add the new fields to the user interface, and save the settings in the picard.ini file ; For this, I need to understand better how this part works, as for now I didn’t watch this portion of code deeply.
Rework the “_has_suitable_artwork” property: If some fronts/backs are excluded, it may be possible no artwork needs to be downloaded. If I’m correct, that’s very important for release group covers fallback, and of course to avoid processing unwanted data.
Rework the “_caa_json_downloaded” method, to download only the requiried fronts and backs.
IMO, the two reworks needs the creation of a new function to sort and select the requiried cover arts, and then download only the list of requirieds ones. That will implies adding a second loop, and increase a bit the memory consuption. I’ll try to make it as small as possible, and will also try to maintain only one request to the JSON CAA list.
I have no due time for the job yet, and was slowed down by a nasty bug with python under windows 10 april update.
Also, should anyone be willing to get involved in this imporvement, please let me know in order to coordinate our efforts.
Of course, i’ll keep you posted about the progression!
If you need any help testing any of this, just let me know. This topic popped up again in another thread in the past weeks where 20MB “raw” scans were being uploaded along with a colour reference chart. That was triggering conversations about including a few more categories. Artwork scans with color references - #2 by reosarevok
Thanks for the proposal @IvanDobsky, I’ll keep it in mind.
For now, there’s no progress on this topic mostly because of a debug bug in Picard V2 (yes sounds weird but that’s possible), plus those possible extra categories are not making things easier, as currently I have no idea how to deal with then So for now, the concept is back on the “drawing table”, but far from being implemented, sadly.
)
So for now, the concept is back on the “drawing table”, but far from being implemented, sadly.