Color managed cover art?

coverartarchive
cover-art
color-management
Tags: #<Tag:0x00007fe3d479c038> #<Tag:0x00007fe3d47afd18> #<Tag:0x00007fe3d47af9f8>

#1

I found an ICC profile for my scanner (CanoScan 9000F Mk II), which does indeed seem to produce truer colors than my manual adjustments. But that leaves a question, should I upload color-managed images to CAA, or convert them to sRGB?

I uploaded some at http://musicbrainz.org/release/384a5636-9c43-4e0f-b9a4-180465807e40/cover-art

  • Color managed:
  • Advantages: no loss of information. Seems to best fit the archive goal.
  • Disadvantages:
    • CAA downscaling discards color management info. Colors are wrong.
    • Seems Firefox and Chrome are ignoring it too, colors are wrong. (Not sure why; they supposedly support color management, and I fiddled with the Firefox about:config options to no effect);
    • Picard also fails to apply the profile when displaying. Not sure what it does when downscaling.
    • So do a few local image viewers. (But others apply it, and exiftool shows its there…)
    • I’m guessing my music players won’t display it correctly, either.
  • Convert to sRGB
  • Advantages: it works. Everywhere.
  • Disadvantages: possible loss of info if colors are outside of sRGB gamut

Example of differences: (This image is in sRGB; on the left w/o conversion, on the right with GIMP converting).

Personally, I’m leaning towards converting them to sRGB now.


Can't load an album
#2

Nothing, Picard doesn’t downscale :wink:


#3

«Why don't we have both?»


#4

More seriously though, I’m personally uploading the original scans, but try to edit the a copy of the front image more “ready for consumption”, which would probably include colour conversion in a case such as this.


#5

Well, as long as she’s paying for the disk space…

In all seriousness, that would be something pretty reasonable if the computer did it, and if it were integrated right. The CAA would offer both a color managed and an sRGB version, with the default being the sRGB for backwards-compat. CAA would generate the sRGB versions itself, and any app that knows about color management could request the color-managed version…

I can imagine where that is on the priority list, though.

Right now it’d mean me manually (or probably through some scripting) doing a conversion on each image, then having to upload both versions of each, having to put in the metadata twice (thankfully not much on images), everyone who browses the cover art wondering why there are two slightly different (or identical, if their color management works) versions of every image, and Picard putting both in every file, doubling the size.

Seems like the user experience of uploading both would be pretty bad. So really ought to pick one.


#6

This is not what I suggested:

Basically, upload all the original, colour managed scans for archival purposes, and make a copy of the front image and edit that (to sRGB and/or any other changes) and upload that as well and make it the “frontiest” one (mark it as “front” and place it as the first image).

In far most cases, only the front image will be used (e.g., for display purposes on MB or when fetching cover art via Picard or beets or other programs using CAA), and the non-front images will mostly be there for documentation purposes.

Also, at some point CAA/IA may implement support for colour managed images, and then you won’t have to do any additional work.

I’m pretty sure that even if you uploaded all your images twice it wouldn’t make much of a difference to the IA who are hosting them. I tried finding stats on their actual storage, but the closest they seem to have is a mention that «The Internet Archive houses more than 10 petabytes of PetaBox storage technology and is expanding steadily.»


#7

Ok—am I weird that I have Picard set to download and embed all of the cover art, not just the front image? I figured everyone did that. I guess if everyone really only uses the front image, only that one would need duplicating (though it’d break my own use case).

And yeah, I’m sure even if we doubled CAA’s size, it wouldn’t be a huge thing for IA, with all the video they have. Still images are tiny in comparison. The amount of disk space it’d use on my disks, though…

I still need to figure out why Firefox and Chrome ignore the embedded profile; I have a vague worry that the scan program and/or GIMP is somehow generating invalid files. Possibly if that were fixed, a lot of things would suddenly start working. But I haven’t had time to look into it yet.

One other thing to do would be to add an option to Picard to do the colorspace conversion. I guess its an excuse to learn Python, someday.


#8

One of the reasons for uploading original scans, for me, is that I don’t have to worry about keeping them around myself. :wink:


#9

Are you saying your scanning software is not doing any color management? It should be using the scanner’s profile and then convert to an RGB or sRGB working space. If not, you may have to turn color mangement on. I’m sure the software that comes with a scanner like yours can do color management.

You’re not actually supposed to use the input device’s color profile as the working space. Working in a wide gamut space like Adobe RGB could make sense. But since you’re creating an image for the web and all kinds of consumer monitors you might just as well work in sRGB, which probably is the most sensible space to use as a delivery format.

As your images look quite different, you’re not converting from one profile to the other. That would look pretty much the same. You’re assigning a different profile. Big difference.

If your images are not color managed at all you should definitely assign the scanner profile and then convert to your preferred working space.

This is a good read on color management: http://www.gballard.net/psd/cmstheory.html

The white levels of your scans differ a lot. On page 2 and 3 the highlights are clipping badly. Was this some auto adjustment? You should turn them off or the colors will never be accurate.

Also, you’re producing quite a nasty moiré pattern there. I guess sharpening is activated in your scan software?
You should definitely turn sharpening off and you may want to turn descreening on, but it will probably make the scan blurrier than it needs to be. Unfortunately proper descreening in Gimp is quite a pain… https://www.youtube.com/watch?v=3137dDa6P4s

Alternatively, you could scan at 600dpi to capture the screen pattern cleanly.

Another problem with your scans is the print on the back of the scanned page shining through. This is easy to reduce by placing a black piece of construction paper behind the page you’re scanning.


#10

Well, that’s the question I was asking—I can either upload images in sRGB (after conversion) or upload them in the scanner’s native color space w/ an attached profile (so whatever is displaying them can do the conversion). (But as noted, for some reason the browsers aren’t doing so—even though they’re supposed to.)

Indeed. GIMP doesn’t work right when I try to work in the scanner’s color space. Or at least, it works weirdly.

… that was the point, to show how different they look.

pp. 2–3 is a page of black & white text. The clipped whites (and blacks too, actually) are on purpose.

No, I don’t have any sharpening enabled. The cover was done at 1200 + an FFT-based descreen + downscaled. The others were just done at 300, I believe. Could you point out which nasty moiré pattern you’re seeing? I don’t notice it (at least at full-size).

Oh, that’s a good idea! I’ll have to give it a try, at least where it’s possible. Could be hard on the books as I’m not un-binding them. (Now, to go get a sheet of construction paper…)


#11

Well, that’s the question I was asking—I can either upload images in sRGB (after conversion) or upload them in the scanner’s native color space w/ an attached profile (so whatever is displaying them can do the conversion). (But as noted, for some reason the browsers aren’t doing so—even though they’re supposed to.)

You should definitely convert them to sRGB.

But the important question is: How do the images come out of your scanner? Not color managed at all? With the scanner’s profile? Or with a different profile?

In my opinion, the left sample image looks slightly better. It’s a bit undersaturated, but the colors seem to be more neutral. The shadows have a red hue in the one on the right.

Indeed. GIMP doesn’t work right when I try to work in the scanner’s color space. Or at least, it works weirdly.

I’ve had problems with color management in GIMP before. For some reason my images look overly saturated when I set the monitor space correctly. Maybe it’s just buggy?

… that was the point, to show how different they look.

Yeah. But there’s a big difference between assigning a profile and converting to a profile and I hope you understand this difference.

pp. 2–3 is a page of black & white text. The clipped whites (and blacks too, actually) are on purpose.

Sorry to say, but it doesn’t look all that good.
You could either clip the highlights all the way until the background is white or don’t clip them at all - In this case I think the latter may be preferable as you can’t clip the other page’s backgrounds to white without messing up the photos. Not clipping them would keep the look consistent over all pages.

No, I don’t have any sharpening enabled. The cover was done at 1200 + an FFT-based descreen + downscaled. The others were just done at 300, I believe. Could you point out which nasty moiré pattern you’re seeing? I don’t notice it (at least at full-size).

Ah, right. I can see some slight descreening artefacts on the cover. You didn’t manage to get rid of the screen pattern completly (don’t worry about that - FFT descreening in GIMP sure has its limitations), but it looks much better than the Marin Alsop photo on page 4, which is the one with the nasty moire.
You’ll probably get a much smoother image just by scanning at a higher resolutioin and then downscaling manually.

Interestingly, I can’t seem to produce a moiré like this with my scanner. Maybe it scans at a higher resolution and then downsamples internally… :confused:

Oh, that’s a good idea! I’ll have to give it a try, at least where it’s possible. Could be hard on the books as I’m not un-binding them. (Now, to go get a sheet of construction paper…)

Best Euro you’ll ever spend! :smiley:


#12

As has already been said should not be uploading images that are not colour managed, or only have a device CMYK profile. However for the ultimate image quality using sRGB isnt neccessarily the best option. sRGB isnt able to represent highly saturated colours particularly well and the AdobeRGB colour space is better for that. The PhotoPro colour space can represent almost any colour but to use it well you need to use a 16bit colour space such as TIFF rather than an 8bit colour space like jpeg.

Adobe Lightroom (and other photo editors) have a tool that can highlight the pixels of a raw image that cant be accurately represented by a particular color space, you might also want to consider whether to use Pereptual or Relative rendering when converting to a colour space.


#13

sRGB certainly isn’t the best for quality, but for end user compatibility it’s probably the most sensible choice.


#14

Yes sure, but if he wanted to load second version then photopro rgb would seem to make more sense then uploading with the scanners profile