Cover Art is pink

[archrival]

For some album art, the resized version is pink. When zooming, the album art looks fine. Any idea why this would be occurring?

[thomasbruce]

i have the same problem with some of my cover art. some are grey and other ones are black and white.....

[archrival]

I did some research into this and it appears the cover art that is showing up strange have bad JPEG headers. Using a tool like ExifTool http://www.sno.phy.queensu.ca/~phil/exiftool/ to add/edit EXIF headers actually rewrites the JPEG header in a way that Java ImageIO reads it properly (it does so losslessly). I took a look at the code and it appears to be a problem with the way Java reads the JPEG and not Subsonic. I tried different ways of reading the JPEG and they all did the same thing. Although still feel free to try to fix it.

[Toddler]

Darn it, I have this problem as well. Nearly my entire collection is black and white, some are pink, and some are fine. My album art is embedded. It shows up fine in other apps though such as WMP or on my Android. No fix for this I guess?

[supra92]

I've found that cover art jpegs being "bad"/"pink" happen every so often, maybe 1 in 30 or so. I watch for that when I'm assigning cover art, and if one shows up as pink or screwed-up when i view the album in SS, I just hit the Change link and choose a different image from the Google Images result. 99 times out of 100 the next image I pick is fine. A minor nuisance, to be sure, especially since images either work or they don't --- if it shows up correctly when you look at it the first time, it'll be fine ad infinitum.

Supra92

[Toddler]

Yeah, but I have 254,232 mp3 files with artwork already embedded which work fine in every other application. That's a lot of work to clean up the entire collection when the real fix must be somewhere in the code.

[tenzip]

I've noticed this also, actually just got a screenshot, and was going to post a thread, but searched first, and found this.

It actually looks like a color photo negative version for me, the thumb, that is. The zoom looks fine.

As far as the problem being in the code, I agree, but it also depends on the way you want to look at it. The code in the picture header is bad, and should not be. Most viewers "overlook" the problem, and let you see the art anyway, without any warning or notification that something is wrong. This is not the way it should work.

Another example of the same kind of thing is Internet Explorer. It will let you view a web page that is, code-wise, quite broken, and it looks and works fine, because IE will "interpret" to try to show what the web "designer" wanted you to see. Other browsers, Firefox, for one, will either warn of errors, or not render the broken parts of the code. (This being one of the reasons I won't use IE.)

Running/rendering broken code, without any indication that it is broken, is a good way to either screw things up, or get a virus/malware. Sloppy coding is encouraged by IE, and, evidently, by most album art viewers.

So, I guess I'm thankful to Subsonic for pointing out these errors. My library is not so huge that I can't fix the ones that are bad, as supra92 said, it's a fairly small proportion of the total for me.

[Toddler]

It actually looks like a color photo negative version for me, the thumb, that is. The zoom looks fine.

As far as the problem being in the code, I agree, but it also depends on the way you want to look at it. The code in the picture header is bad, and should not be.

The thing is, the thumbs are being generated by Subsonic in my case. They are all embedded in the mp3 files in my collection, with no .jpg files present at all. It is only when Subsonic indexes my collection and generates all the thumbs it uses that things get screwed up. So if the code in the thumbnail picture header is bad, and given that Subsonic is generating those thumbnails from the embedded .jpg files, it is isolated to Subsonic.

Strangely, after deleting Subsonic's thumbnails and manually reindexing my collection without making any changes, some of the albums which were displaying incorrectly are now fine, and others are not. Curiouser and curiouser.

[starnostar]

For anyone having this issues (I am), this can fixed....

For any album art you download from now and into the future, just install jhead (should be in your repo) and run

$ jhead -purejpg img.jpg

Where "img.jpg" is your yet-to-be-embedded album art
This strips the jpg header off entirely, and makes whatever image you choose, no matter where you get it, work every time...be warned though, if you care about ANY metadata in the image, this will strip it off (also handy for stripping metadata for craigslist photos, etc...)

And for anyone using Thunar, and want a custom-action for this...
# Name - Whatever you want...
# Command - jhead -purejpg %F
# File pattern - *
# Appears if selections contains - "image files"
Now right click image, choose action, image is processed....if you picky like me, you can string in an imagemagik command to make the image perfectly square first...right click for perfect album art

-purejpg
Delete all JPEG sections that aren't necessary for rendering the image. Strips any metadata that various applications may have left in the image. A combination of the -de -dc and -du options.

[BKKKPewsey]

FYI -Windows users http://www.yafla.com/papers/purejpeg/filter_unnecessary_jpeg_info_such_as_exif.htm

[Exrace]

Nice fix.

[starnostar]

My previous fix STILL did not work for a select few images....

-purejpg still leaves a few other fields, but to fix the images that -purejpg didnt fix, this worked

jhead -dc -de -di - dx - du img.jpg;jhead -mkexif img.jpg

or

jhead -dc -de -di - dx - du img.jpg
jhead -mkexif img.jpg

instead of just "deleteing exif data not necessary for rendering the image", this just deleted the whole %$*# thing and re-writes it (the exif data that is...all of it).

[configX]

Add me to the list of people experiencing this.