Artwork scans with color references

Lately I’ve been including a color reference with my scans of album artwork. This is primarily for archival purposes, but also to provide a reference if someone wants to take the image, correct the colors and create a high quality cropped image. I’ve tried to remember to not mark any of these as “Front”.

Today I received a “No” vote on one of my submitted scans (see https://musicbrainz.org/edit/53078916).

What are the community’s thoughts on the practice of including things like color references with scans? Should they be included, or should they not? If included, should the image type be set to “Other”? Also, I encourage you to vote on the above edit, with a note indicating why you agree or disagree, so that it’s captured in the database.

I started including the color reference because my understanding is that the primary purpose is to provide an archive of the information, which is why images should not have the edges cropped. If what I’m doing is wrong, then I need to know that so I stop doing it.

Thanks.

Edit: The other ones that received a No vote (with no edit notes) are:

3 Likes

What my local art museum does is to provide the color reference image and a “ready to use” version without that. That would probably be ideal for archival + use purposes, but at the same time I understand it’s extra effort and possibly a pain in the ass (which is ok for them because they’re paid to do this, but MB editors are not).

That said, I don’t see any reason to vote No on this: it’s not like there’s a current back + spine image that could be considered better in any way (since there’s none at all). I’ll comment.

7 Likes

I would generally oppose it because it adds an additional step to anyone wanting to use the artwork, they will have to crop it, etc. The number of people that would actually use it for color correction is probably miniscule. If you want to continue doing it, perhaps add both. One cropped to just the content, and one with the additional color reference.

2 Likes

That’s definitely the case for a front cover. I’m less sure that’s true for any others - I feel these are supposed to be more a reference for the data than an image people will directly use outside MB (unless it is to print pirate editions of an album, which I’m not sure is a use case we need to care to make easier :slight_smile: )

3 Likes

I realise I am not the person that MB is aimed at, but I’ll add some feedback from my viewpoint. I use MB through Picard to tag my music files. This includes adding artwork to the folder (not embedded in the file).

What I see is 20MB of unusable image that will be downloaded by Picard. There are threads elsewhere that talk about how long Picard takes when used with multiple files.

If unusable images like this are added to the covers I suggest more categories are needed. Picard needs to know to avoid this file.

3 Likes

I’d say the image type should be what the image is :slight_smile: One thing that might make sense if this becomes common is to have “color reference” or “uncropped” or something as an additional image type, in the same way we have “watermark”

Why would you set up Picard to download a back cover, and even if you do, why would you not just use 500px or, if that’s too small, the new 1200px option? (note: I’m not sure Picard is already set up to use 1200px - I’d expect that to change in the next few months if it isn’t yet, though!)

4 Likes

High quality artwork is good to see. Picard’s ability to download it means I have it available when I playback my music. For example at this moment I have music playing back through my hifi which comes from my media centre. The artwork is being displayed on a 50" TV screen. So a 500x500 image is already a bit too scruffy.

A category of “uncropped” or “needs processing” or “raw” would help. Though that is something that Picard then needs to handle in an intelligent way.

One of the reasons I joined up over here at MB is due to KODI and its reliance on the quality data here at MB. There is currently an expansion going on of how the music is handled and part of this is stepping into much better artwork handling. So do not be surprised if I am not the only one looking for high-res scans of all parts of a music release.

4 Likes

As an aside, you might want to check out fanart.tv as a source for cover art. All of their album covers are high quality jpg files at a resolution of 1000 x 1000 px, with a maximum file size of 1 MB. There is also a plugin for Picard that searches the fanart site. I use that here, and have it set as the first choice for searching cover art.

1 Like

In case this becomes an accepted option, I just created ticket STYLE-980 in JIRA.

7 Likes

Thanks, an interesting site. I’ll look deeper later to see how well linked it is to specific releases. Though at first glance there doesn’t seem to be any rears, spines, booklets. Just a square image for a front cover.

I like MB and Discogs as these places are full of so many geeks arguing about getting the best quality and making sure it really is the right cover. And then uploading all the other bits and pieces of a release so us users can then compare our releases in detail. Having scans of rear covers is always handy due to that barcode and other details helping us spot one release from another.

2 Likes

This should be mandatory for such pictures because IMHO they are “not ready to use”. There are too many services out there assuming, the CAA delivers read-to-use pictures. With @rdswift’s new type, you introduce a “needs a lot of manual work before it is ready to use” picture type. KODI and many others would display covers in unexpected and most cases unwanted way. Especially for the front and back cover type.

2 Likes

IMO that’s to some degree a problem - for many obscure releases, a blurry back cover photo that can kinda-sorta be read that I find on eBay might actually be the best image we can find (at least until someone comes along with the actual physical release and the time to scan it) and it is still useful for MB (because it allows a user to verify the data) even though it’s probably not good for tagging.

I suspect if use of non-front images becomes more common, the CAA and data users will need to have a discussion about what’s the best way to satisfy both parts.

6 Likes

I voted “no” as I have a simple question. How much more time would it actually take you to provide both images? Both a cropped one that is usable by the majority and then upload your upcropped one for anyone who didn’t like the way you had cropped it and needed to tweak the colours.

I get @reosarevok comment that this is “better than having nothing”, but us Picard users will be swearing if we download 20MB, 60MB, 100MB of images that then turn out that they all need editing before they can be used.

Can I also point towards MusicBrainz own documentation:
https://musicbrainz.org/doc/How_to_Add_Cover_Art

There are comments in there about 300dpi and 15MB “maybe being overkill”.

I’ve always read that page as aimed at making usable images. So lets have both maybe? :slight_smile:

This is a edited version of my vote note.

I was going to vote yes but changes to Abstained. After reading through the responses several times I decided to express my thoughts. The author has made the distinction that the art is for archival purpose and gives the rest of the community the ability to do what they want with it. If I was using this DB as a tagging machine then I may reply no, but tagging is not the authors intent for the art. I will point out it is labeled as “back,spine” and is not what I would expect from “back,spine” art, I would expect something like “other” should be added, that is why I Abstained. IMO it needs a clarification, especially if taggers would bring down a “back,spine” designation.

The problem with this art is the tagging designation, taggers need to be able to avoid this art, but the art should stay with the correct designation. I will say opening the art in a browser window was painfully slow and I have 100Gb internet and a fast machine.

It really depends how many different people I need to satisfy. Some want square cropped front images. Some don’t. Some want the edges cropped. Some want the edges visible. Some want JPG images. Some want PNG or other lossless formats. Some want images processed (e.g.: color correction, blemishes healed, etc.) Others want original images with warts and all. To try to please everybody, that could easily require eight to ten files prepared and uploaded for each image. That’s more time than I have available, and more effort than I am prepared to contribute. Especially when there’s always going to be someone who isn’t satisfied because they want something a bit different. I’m sorry if that sounds selfish or non-community spirited. By providing a high resolution scan with color reference information, I am ENABLING all of those preferred options, in addition to providing information that can be used in ways that we may not have even thought of. Isn’t that what archives are for?

I hear and agree with your concerns about others using the images for other purposes, but I was (more than) once told that MusicBrainz was primarily about archiving information and not about image tagging. At least that was my understanding.

As for file sizes and such, there have been a number of discussions since that “How to Add Cover Art” page was posted, and I believe that the consensus was that 600 dpi was preferred. As was mentioned earlier, if you’re concerned with large file sizes, you can set Picard to download the images converted to 1200 px JPG files.

5 Likes

There is tension and significant incompatibility (at least until AI can take a colour-referenced image and crop and colour balance it automagically) between “Archive purposes” and “Display for pleasure”.
A check-box to distinguish between the two seems a good idea.

Integrating fanart.tv into Picard>Options>Options…>Cover Art: Cover Art Providers would seem useful too. Then Picard users could choose images that are optimized for display purposes and that won’t have the messy edges that should be a feature of every CAArchive scan of physical CA.
(Without those messy edges there is destructive cropping being done.)

2 Likes

There is a fanart.tv plugin available :wink:

3 Likes

Is this a stated policy or your personal preference?

I feel that insisting on arbitrary levels of correctness in CAA uploads is a good way to discourage anything from getting uploaded to CAA at all.

2 Likes

Neither.
Simple fact.
Pieces of paper very rarely have perfectly straight and unblemished edges.
And scanned edges are very very unlikely to correspond exactly with the pixels in a photodetector.
If the edge of the image is perfectly straight and without blemish and finishes smack damn on a straight line of pixels then the image has pretty much for certain been altered.

An alternative which inspires some confidence that the image has’t been altered is a raw scan with border of background showing right round the CA.

Probably another aspect to the tension between “Archive Purposes” and “Display for Pleasure”.
And one that will slowly be resolved.
EDIT: Been thinking about my personal preference around CA images.
And think that being able to choose whether I get an “Archive Purposes”, “Display Near Original for Pleasure”, “Fan-Art” or even an “AI generated Poster-sized Blow-up” would suit me.

2 Likes

I think it’s a good thing to have images with color reference, and i see no reason to vote No.
But please, also upload images without color reference, properly cropped, and placed before those with color reference.
Until we have some “color reference” type, please mention it in the image comment.

6 Likes