Uploading squared images to CAA

Huh? https://musicbrainz.org/search/edits?auto_edit_filter=&order=desc&negation=0&combinator=and&conditions.0.field=editor&conditions.0.operator=%3D&conditions.0.name=rdswift&conditions.0.args.0=1399353&conditions.2.field=type&conditions.2.operator=%3D&conditions.2.args=314&conditions.3.field=open_time&conditions.3.operator=>&conditions.3.args.0=2017-05-09&conditions.3.args.1= suggests otherwise… ?

1 Like

Thanks @Freso. I must admit that I was somewhat annoyed when I saw @aerozol’s comment, especially when I’ve gone out of my way since the start of this discussion to upload the complete digipak scans (front, back, spine, inside and tray) in high resolution (600 dpi) lossless (PNG) files. What more do you need for archival purposes? Furthermore, I’ve placed these images at the front of the queue so they would be served up before any square cover images that I may have included.

My patience is starting to wear a bit thin on this whole discussion. If you don’t like the stuff I scan and upload, just let me know and I’ll stop. All I’ve been doing is trying to help contribute to the database and the end users. I’m beginning to wonder if it’s worth the grief.

3 Likes

I would appreciate if you continue this. Scans of this type is exactly what we need more. I haven’t contributed many scans myself, but when I did I took great care of scanning all booklet pages and cropping everything cleanly, so I know the amount of work involved. And I have a bunch of releases I want to do at some point.

I also don’t consider having square images in addition to the correct aspect ratio a big deals. As long as it adds value to the database I think we should have it. There are other odd things that can be added, like detail scans of stickers or photos, which often are no perfect quality but add value to the dataset by providing additional information.

8 Likes

I don’t see a non-square front image?
Maybe you mean front + spine + back?

Honestly, it’s just a discussion, nobody’s been downvoting or removing your additions, and I think it’s a bit patronizing for me to have to say again that I REALLY value your additions.

I’ve also tried to be very patient, off the bat you talked about me in bold and caps after I asked you to please stop doing something, and then implied I wasn’t being courteous?
I know discussing things on the internet is hard, because you lose out on all the social cues and context - but let me reassure you again that you need only feel good about your contributions and that nobody is saying you’re doing a bad job![quote=“aerozol, post:12, topic:265031”]
so don’t worry about it :stuck_out_tongue_winking_eye:
[/quote]

1 Like

As I read your original comment, I understood that you suggested that they had not uploaded anything but front cover images that had been squared, while I saw plenty of non-front images that had been uploaded. I didn’t understand that you only talked about front images, and not all uploaded images. (But yes, I do consider front+spine+etc. valid non-square front images. You’re free to fetch those images and crop them so only the front-front part of is in the image and upload that to CAA yourself, if you want/need it.)

2 Likes

Sorry to bump here but it’s the most appropriate topic title for this.
In the end, do we allow uploading of square cropped images?
It does not look like we have any kind of altered type — STYLE-845 from another topic — (yet) to mark them as such so I tend to think we don’t allow them when we know they’re incorrect.

1 Like

My opinion is still the same - for tagging purposes that user can set one of six square covers from the release group as the RG image and tag using that. I don’t see the benefit in uploading a edited cover in this case.

If anything should change it’s that we could default to using the RG picture (assuming it’s what most basic users want) and allow uploading user-edited/fan covers directly to the RG (not to any release) if necessary.

2 Likes

That’s not universally applicable, though, as it relies on there being at least one release with square uncropped cover art.

That seems to me needlessly complicated and confusing. It would require changes at the RG level (since you can’t upload any cover art there now) which would open up the possibility of release-specific art getting uploaded only to the RG.

It seems much simpler to me to just ask editors to (a) mark any square-cropped images as such, via comment unless and until we get some more structured option; and (b) also upload a version in the original aspect ratio.

2 Likes

I have never seen this not be the case in practice/when someone has uploaded cropped art. But that hypothetical case is the only reason I even suggested the second part (uploading to RG).

Uploading an extra image for every single release is more complicated and confusing than just doing it once. If someone is after the best quality image for tagging, then why duplicate the same image (eg the best one for tagging) across every release? And you’d still need code changes on MB and Picard to allow users to choose to use/not use those images - or another big debate as to which image should go first/get used. Using the RG image is pretty much perfectly set up to handle this already.

1 Like

Well, off the top of my head, here’s one that I did last spring. (I would probably do it differently today, and put the uncropped version first).

Except that there’s no way to upload an image directly to the RG. Also, as I believe rdswift noted on the ticket, cover art from different releases within the same group may be entirely different. For my own selfish purposes I’d like to have a front cover that’s square(ish) but also reflects my actual CD.

I just don’t see what the harm is in having a cropped version of the artwork, labelled as such, attached to an MB release.

2 Likes

MP3 version with square cover*:
https://www.amazon.com/Himself-Dennis-McGee/dp/B0045DEY5U

I know there’s no way to upload an image to the RG, but I think it would be a good addition. I don’t see the harm in uploading the cropped version, but it doesn’t represent the release, and MB is a release database foremost, so it shouldn’t be the first image (so we can identify it from others) and thus wont be automatically tagged with anyway.

There’s definitely edge cases (as you say, for instance different reissue covers in a RG). If there is a checkbox for it, and Picard handles it fine, why not… but I do think there must be a better way to do it.

*bonus ‘see the top of his pants’ edition :grinning:

2 Likes

I also think there is always either a digital edition or a vinyl edition with square cover.
I don’t think we should enable RG image upload, it would be redundant with “set RG cover art” that encourage people to add that square edition instead of uploading random image.

2 Likes

I agree that allowing uploading of RG artwork will lead to confusion. Lets not go there please.

I can also see the need for some people to have square art at release level. I have a number of copies of Dark Side of the Moon which all have different artwork for the different releases. This means if I was a Square Art Man I’d also need separate Square Art.

But MB is more about accurate data. In a consistent manner. Personally I think accurate artwork should always be the priority. Too often I see a random square image get uploaded from somewhere without notes.

It is also noticeable that many people don’t understand MB or Picard and just “want to tag their files”. So you see someone upload another copy of The Wall, label the CD as 1979, and attach a random image to it. That leaves us to run around and tidy up after them. That will get ten times worse if any old cropped images are allowed to be uploaded.

Yes, I see the sense to have a “Front” image which is cropped to the CD size. If it came from a fatbox so naturally would have the spines attached, then an image cropped without the spines should be uploaded. But that is it - nothing deeper.

I’d rather stick to the quality. Stick to the 100% real artwork. If someone needs customised artwork for their Media Centre then it seems more sense to direct them to the custom artists at places like https://fanart.tv/ or The AudioDB who already link into the MB data.

(I am a KODI user and the main reason I am here at MB is due to wanting to see better artwork appear in my edition of KODI… but that starts from having an ACCURATE database to work from. MB should stay focused on that accuracy)

7 Likes

Silly question - but what is the difference? Is it just that one is 1107x1000 and the other is exact 1000x1000?

Errr… but the square isn’t a square. It is 1001 x 998. :wink:

So this is a good example. This attempted to give someone a “square” image, but didn’t quite get it right. IMHO the 1107x1000 is close enough to a square already. Any Media Centre attempting to display that image in a square box is going to get a good quality result anyway.

(Oh - and @highstrung I’d go and swap those images now. Easy enough to do the swap to put the real one up front… otherwise my OCD will jump on it and jiggle the order myself…)

I think the best quality most accurate and usable front image should be first. Then if there is also a squared off prettified version as well it won’t disrupt the majority of users.

I think our fundamental difference is that I don’t see this as misrepresenting the release (as long as it’s clearly identified) any more than a detail of the Bayeux Tapestry misrepresents the whole, or, closer to home, the close-up views of CD inner rings common at discogs misrepresent those discs.

So clearly you are further along the OCD spectrum than I. :slight_smile: I wanted something to look decent on my phone, without visible letterboxing. 1100x1000 gives noticeable letterboxing but 10001x998 doesn’t.

I prefer a “yes, and” approach; encourage people to upload their cropped images, and also the original aspect ratio. I feel that a policy saying “no cropped images” is just going to discourage users and lead to fewer contributions to MB overall.

2 Likes

Sorry, I didn’t express myself well - I want to see exactly what a release looks like, for instance if an release is a Digipak version, by looking at the cover on MB. If they’re all squared it’s no longer as helpful for identifying a release/it might lead me to think that it’s a different release.

2 Likes

I yet have to find a release group with no existing square cover edition so I prefer allowing only correct covers.
Even the example you gave had an easy to find MP3 edition with square cover, so it just needs to add this edition with its cover.
I think it is already the implicit rule anyway, quite obviously.
Maybe it should be more explicit in the Add Cover Art page itself?

2 Likes

I can’t see a problem of having an extra image here or there. What would concern me is if someone thought it was “useful” to start uploading cropped images everywhere. Or used as an excuse to upload a 50MB uncropped 1200dpi front cover scan with an extremely cropped one alongside it. If a few hundred covers also had a cropped image in the list as a second front then it shouldn’t be a hanging offence.

I’ve been uploading a number of book bound special editions lately ( https://musicbrainz.org/release/fa431dbe-9a8b-40f6-9b6b-a1ddcdfb8712/cover-art ) and they look slightly odd on some media players. Depends if they attempt to crop the rectangular image - or as Picard does, puts the rectangle into a square with blank space around it.

Just because my media player can’t display it does not give me a reason to upload a modified image here at MB. The first reason for these images is identification purposes. Would cropped images be the start of a wobbly downward path towards animated cover gifs with flashing lights…

( And yes - I am way too far down a bizarre side road of OCD that also leads me to arguing both side of the same discussion. :rofl: )

3 Likes

I did understand that, and I think a guideline saying that uncropped images should always be first in order would address that concern.

Maybe somebody can find a square version of this one… https://musicbrainz.org/release/06fcf42e-a3ea-453d-bb60-4b83b5bb48cc

“Implicit” and “obvious” rarely go well together. :slight_smile:

1 Like