Photoshop CS4 Color Settings
Posted by René | Filed under Color Management, Photoshop, introduction, software
Once, and for all
Never thought I’d blog about something as individual as PS Color Settings… Then again, there is so much conflicting, incomplete or downright inaccurate info on the web, I thought it might be time to set the record straight.
Individual
First of: Like more things in photography life there is no “Magic Bullet”. If that’s what you are looking for, better get used to this idea: You need a basic understanding of Color Management.
On the bright side: The settings in the Color Settings dialog box affect a number of things. However, unless done totally wrong, how your images are displayed is not one of those things.
Settings nobody should use
There is no “Magic Bullet”, but there is a “one size fits no-one”: The setting called “Monitor Color”.
What does it do? Let’s go through the main problems step by step:
It sets your monitor profile as default working space. So every time you calibrate your monitor (you do that regularly, right?) your default working space changes. And your default working space is limited to your monitors gamut. Not good if you are on a laptop for instance.
One additional problem is that equal values for R, G and B might not give a neutral gray. And there are other problems.
One of those problems is, that it sets all color management policies to “off”. Note that, contrary to popular belief, setting “monitor profile” does not turn off color management altogether: The one good thing in all this mess is that you are presented with this dialogue box when opening an image with an embedded profile:
Damage
The damage you can do here is very real:
If you tick the top option (“Use the embedded profile”), no damage is done. The image will be shown correct, and all data is retained. Not bad at all.
If you pick option #2 (“Convert to working space”), irreversible damage is done: The pixels in the image will be converted (changed!) to your monitor profile. Color numbers are converted (so colors will display correctly), but all colors out of your monitors gamut will be clipped. Poof! Gone. Forever.
If you pick option #3 (“Discard the embedded profile”), at least you won’t be damaging the file on import as in option #2 (it’s reversible by assigning the correct profile). But you will not be seeing the image correctly. So any “color correction” you do will be incorrect. The fact that the color numbers aren’t changed is a moot point because of this: What you see definitely will not be what others see.
Other problems
Yet another problem is that, even if you use embedded profiles, you will get no warning when you copy-paste an image into a new document (which by default will not have an embedded profile), or into an image with a different working space: The colors will change. See option #3 above.
So, I see no reason for anyone to use it. Not even web designers. Yes, I know that lots of browsers are not color managed. However, there are not lots of people using your screen, are there?
The only reason to temporarily set it, is when you need to check whether Photoshop is using the correct monitor profile.
Better
Just about any of the other “presets” is better. These presets are grouped in a few categories. When you scroll trough them, you might notice a few things:
There are settings for Europe and North America. And in every region there are 3 settings: for “General Purpose”, “Prepress” and “Web/Internet”. When you tick “more options” Japan appears, which has the same trio but adds “Color For Newspaper” and “Japan Magazine Advertisement Color”. There also appear a few other “international” presets.
Rather then going into each one in depth, I’ll generally explain some differences and possible pitfalls: They are “presets”, but IMO none is perfect. You can use them as a starting point however.
I start of with “more options” unchecked. And the screenshots are for the European presets. However, the comments I give are the same for the other localisations.
General Purpose
It Isn’t. It’s really that simple. Like I said: There’s no magic bullet.
Main drawback is that you get no warning whatsoever for profile mismatches: When you open two images in a different working space, and paste one into the other, colors will be converted. Which, as said, is irreversible and might give irreversible damage. If I’m going to damage my image, I damn well want to be notified.
Prepress
Is quite a decent choice if you are doing prepress work. Profiles are preserved, you are warned when you get a mismatch, and reasonable profiles are chosen for CMYK, gray and spot. (depending on the area you chose, CMYK and dot gain are different.) Then again, if you are doing prepress work, I’d hope that you know enough about color management that you don’t need to read my thoughts on it…
Web/Internet
This is the only preset where converting to working space might make sense in my opinion: If you are just doing work for internet, anything should be sRGB. If you have to ask why: Read my blogpost on the subject. Then again, I’d like a warning if an image has no embedded profile: In some cases it might be because someone screwed up. This is largely a personal preference however.
Other presets
Are “more of the same” (two other Japanese presets only differ in CMYK, gray and spot from Japan Prepress2). The “Phase One” workflow is the odd one out: It sets a gray profile of Gray Gamma 2.2 which is quite sensible. Then again, the CMYK profile is “Euro-Catalog”, which I never need.
The other options (Colorsync (mac only), PS5) are obsolete legacy.
Create your own
Since everybody’s needs are different, it makes sense to make your own preset then, doesn’t it? Sure! But you need to know what each setting does. Some things are pretty straight forward, others not so much.
Default working spaces: RGB
Pretty much up to personal preference. The question “what RGB color space is best” I’ll leave be for now. Use whatever working space you use in your raw converter of choice. Two points I do want to make: If you don’t understand color management, do yourself a favor and use sRGB as a working space everywhere. On the other hand, if you are using a wide gamut color space (anything larger then AdobeRGB) do so in 16 bit per channel only!
Settings never to use are AppleRGB, ColorMatchRGB or GenericRGB. These are based on monitors that went the way of the dodo…
CMYK and others
For CMYK working space: Most people won’t ever print something on an offset press, so won’t ever be needing CMYK. When you do need it, make sure the printer tells you what profile to use, and set that as the default: It has some impact further down the road in PSCS4.
Don’t ever use GenericCMYK or one of the “old” Photoshop CMYK settings here: No good reason to. When in doubt, you probably won’t ever need it, so pick the “default” for your region.
Same goes for Gray and Spot working space. If you do a lot of grayscale images for web, gamma 2.2 is the best setting. If you print them to a specific Offsetpress and you know what dot gain to use, by all means do. But in that case you probably wouldn’t be reading this article… For same reasons as above never, ever use Gamma 1.8. It’s obsolete.
Policies and Notifications
Choose “Preserve Embedded Profiles”, unless as explained above, you are a web designer and have thought about the subject a bit.
I don’t see the need to tick the “Profile mismatch: Ask when opening” box, since I edit images from a known source, and the embedded profiles are what they are for a reason. So YMMV. I do tick the “Ask when pasting” and “missing profiles” boxes. The first because I want to be notified if an image profile is converted, the second because if there is no profile embedded, someone screwed up.
Note that if you choose “Discard the embedded profile (do not color manage)” here, the image will be shown as if it had the default working space embedded. This has the same effect as assigning your default working space: The image won’t display accurate, but it is reversible (by assigning the proper profile).
Another note (a big one) is that PS somehow doesn’t display this warning when pasting an image without profile into a document with an embedded color space! Colors will change.
Advanced: Conversion options
Engine: Leave at “Adobe (ACE)”. It’s the best choice, and if you have a specific reason why you would want to use another, you would not need my advice.
Rendering intent: Either perceptual or relative colorimetric for photographic images. Which is best will depend on the image. Not that this setting matters much: This is the rendering intent used by default when you go Image > Convert to profile (where you can change it in the dialog box) and it is used when going Image > Mode > CMYK for instance (which I would strongly advise against, since it offers no preview and no direct control)
The description says it all:
Always tick “Use Black point compensation” and also “Use Dither”: It makes banding or posterization much less likely.
The last option “Compensate for Screen -referred profiles” is only important if you make documents for Adobe After Effects. In that case: Tick it. Otherwise: Tick it as well, since it won’t matter then.
Advanced, but not to be used
“Desaturate Monitor Colors By” and “Blend RGB Colors Using Gamma”: Easy: Don’t tick those. They are not meant for photographers. Again: Read the description:
Possible pitfalls
As already mentioned, the settings set in the “Conversion options” will be used when changing from one color space to the next by going Image > Mode. So do not go there. Use Edit > Convert to profile instead. Yes you can also use it to convert from RGB to CMYK…
Another, less well known fact, is that the default profile is what determines the values in the info palette (Color picker) for anything but the color space the image is in. So if you use a CMYK or grayscale color picker on an RGB image, the readout will be for your current default CMYK or gray working space!
Another of the stupid less-then-brilliant decisions on Adobes part was to have the Select > Color Range > Out of Gamut selection be based on the default CMYK working space. Makes no sense whatsoever and makes the tool all but unusable for anyone who prints at home, but there it is…
Here is an sRGB image, softproofed for my Epson R2880, using glossy paper. The Gamut warning is on and shows no out of gamut colors. Notice the selection?
Conclusion
After reading this, you should know enough about the subject to create your own settings. After you did, save them as your own preset. It might also be a good idea to add a description.
Here’s mine:
Tags: Color Management, PhotoshopCS4, WYSIWYG
Canon DPP or Adobe Lightroom?
Posted by René | Filed under DPP, LightRoom, Problems, software
Or: Why I shoot Raw
I shoot a lot of Performing Arts. That often involves “difficult” lighting: Different light sources, with different color temperatures. And to make matters worse, they are fitted with colored gels most of the time.
While I mostly try to go for “pleasing color”, rather then “neutral skintone” (the lighting was done a specific color for a reason I think), this still poses some challenges every now and then.
Simply setting ‘tungsten’ white balance is an okay starting point, but with certain types or colors of lighting, I need to do quite a bit of tweaking to get the image where I want it.
For that reason, I choose to shoot Raw: Gives me the most flexibility, and allows me to change whitebalance without causing too much harm.
Raw converters
Most of the time, I use Lightroom 2 for editing these images: I prefer the workflow over using the combination of DPP and Photoshop: I can do local edits on the Raw file in LR, and I can save the DNG with all edits included. With DPP/PS, I have to save a layered psd file of each image (which might be about 100Mb or so. With hundreds of images, that eats up HDD space rather fast).
This might not make sense to everybody, but makes sense to me.
DPP offers better noise reduction and sharpening in my opinion, but most of the time LightRoom is good enough for the intended purpose (images for the web).
Sometimes not
Occasionally however, I come across an image that simply will not give decent results in LightRoom. Blue gelled lights often give problems: For one: No way to reduce noise without obliterating all detail on the process. A while back I processed one of those images.
Here’s what it looked like in LightRoom at my default settings (Camera Neutral):
Not the best rendering. Obviously, the purple causes some problems by “blocking up”, and the blue does horrid things as well: Details and sharpness are gone. (notice the faces? A bit further down are the images up close.)
One thing that might help some colors (but not blues in my experience) is switching the camera profile. In this case, “Adobe Standard” didn’t exactly help, and the ACR4.4 profile was so bad I won’t even bother posting the screenshot…
Adjusting white balance and using specific HSL adjustments helped the image quite a bit, but still, the details in the shadow stayed absent.
Time to try a different Raw converter…
DPP
Canon’s own DPP is a very different piece of software then LightRoom: It has no DAM capabilities, and only offers global adjustments. So any local editing must be done in Photoshop. For instance by doing multiple conversions and use masks in PS.
Also, the user interface is very different and seems to be a case of “you love it or you hate it”.
Most importantly however, it rendered this image quite different from LightRoom
DPP “As shot” looks quite “neon”, but it clearly contains more detail:
The lack of detail in LR is not caused by noise reduction: If NR in LR is set to 0, the difference is still apparent. Setting Color NR higher then about 7 does obliterate any detail that was left however. Clearly, LR Color NR is not just targeting color noise… Luminance NR doesn’t help the image, but doesn’t destroy it either.
In comparison, DPP does much different: you can set a fairly high amount of Chroma NR before you start losing detail, and it actually removes color noise. However, setting a Luminance NR of something as low as 2 visibly removes detail: Avoid this like the plague.
Finishing up
Setting a higher color temperature, different color tone, and using “tune” to shift the image toward green/yellowish helps colors in DPP, although some transitions in the beams of light still look quite harsh. LightRoom does better in that respect.
The most striking difference (apart from the loss of detail in LR) is that the smoke appears to be almost gone in DPP!
Sometimes neither works alone
So, this appears to be a case were neither Raw converter gives satisfactory results… DPP gives detail, but no smoke. LightRoom gives smoke, better transitions, yet no detail. RIT handles the image like DPP does, apart from the fact that is seems to do some noise reduction by default, with no (working) option to turn it off. So no sense in going that route: RIT is a bit more constricting then DPP (you can only adjust what you could adjust on the camera) and the user interface is horrid.
I finally decided to open both the LR and DPP conversion in Photoshop, and blend them together, thus getting an image that contained both detail and smoke:
If anyone wants to give this image a try, the Raw file can be downloaded from here.
Please respect my copyright, and only use the image for evaluation purposes.
Tags: DPP, LightRoom, software
Printing to an Epson R2880. Theory and practice
Posted by René | Filed under Color Management, Epson, Photoshop, printing
The “5-95%” rule
In a thread on Photography-on-the.net a while ago, someone mentioned reading some advise to set black and white point to 5% and 95% respectively. That’s approximately RGB values (12,12,12) and (242,242,242). Otherwise, shadow and highlight detail would be lost in print.
My first thought was “no way”. After all, white is 255, right? I’d say that’s what printing colormanaged and .icc profiles are for.
I’d accept a bit of a loss, but not thàt much…
So I started to search the web.
Whàt?
One source of the advise was at www.lynda.com: Prepress Essentials by Taz Tally.
He was talking about offset printing. There was also an example about Newsprint. According to that, for a (hypothetical) example where the newspaper press could print a minimum white highlight dot of 20% and a maximum shadow below 80%. The tutorial proceeded to adjust output levels similar to this:
According to the tutorial, you’d be preserving highlight and shadow detail as much as possible for those particular presses.
Yeah, right. What highlights and shadows? They all became midtones…
Gray
I’ve taken a black and white image of mine, since that tutorial was also using a b&w image, and adjusted the shadow and highlight values according to that tutorial. The red dots in the middle image represent the picked black and white point.
Negative scan of Popa Chubby in Atak, 1995. Left to right: Original, for “commercial press” and for “newspaper press”:
If I softproof the rightmost image for “Japan Color 2000 Newspaper” (the only “newspaper” profile I could find in PSCS4), it goes to hell in a handbasket…
Frankly, my first thought was the author went nuts.
Then again, this is Lynda.com, right? Maybe I just misunderstood. Or the file was sent straight to the newspaper press? (without color management)
Another tutorial
“Desktop Printing Techniques” by Chris Orwig, also on Lynda.com, made one point clearer: The 5 and 95% figures are a starting point, and you should test with your own printer / paper / profile. That makes perfect sense.
He also mentioned “accurate detail” and “relevant white / black detail”, where Taz Tally mentions it, but then sets black and white points that I would let clip: Mr. Orwig is more rational in picking the points he chooses for the color sampler tool. (Not the first highlight appearing, but actually something that you want detail in.)
Okay. Obvious: If you have blown whites, then guess what: They are not meant to show detail. No point in setting a white highlight at (242,242,242) nor a deep black shadow at (12,12,12). But that makes it quite personal: What is “meaningful detail”?
A few “Gotcha’s”
The tutorial then goes on to set the color sampler values to read out as grayscale.
No idea why, and not the best option IMO, since the “gray” readout in the info palette is dependant on the settings in the PS color settings for “Gray”.
And guess what: “Europe general purpose” uses Dot gain 15% where “North America general purpose” uses Dot gain 20% for gray working space. Not a huge difference in this case, but one to know.
Also, why not just use the RGB (or HSB) values? They remain constant whatever color settings. Better yet, use LAB values: They change as the luminance changes: quite a difference between (12,12,12) in sRGB and the same value in AdobeRGB (Give it a try)! So keep in mind your document color space!
The “Gotcha’s” visualised
To demonstrate those issues, here are a few screenshots of 4 color samplers I placed in 4 neutral gray patches of a document (the test print I’ll use later on).
All this also speaks in favour of doing your own tests: Your workflow is probably different from mine, or that of the Lynda.com instructors for that matter. As is your definition of “meaningfull detail”.
Let’s stop theorising already!
As easy said as done.
So off to search the web for a test image.
I found this nice test image (and description how to evaluate the print) here
Test print: some thoughts.
I usually use AdobeRGB.
The image is in ProPhotoRGB, which gives the “number” patches a little different meaning: A ProPhotoRGB value of (6,6,6) I can distinguish quite well from pure black. In an AdobeRGB document, I have to look hard. In an sRGB document, it’s quite obvious. Similar, ProPhotoRGB (253,253,253) is less easy to distinguish from pure white to me then the same value in AdobeRGB, while sRGB is easiest. The differences are quite subtle though.
The LAB color pickers came in handy here: I wasn’t going nuts, there is a slight difference.
Now that is cleared up…
Lets get printing
I used the Epson R2880 with Epson Premium Glossy Photo Paper.
Color settings in PSCS2 printing dialog:
Colormanagement off in the printer driver of course.
I used the .icc profile downloaded from the Epson website.
There is one profile provided for that paper. The printer driver however, has a few settings that might influence how much ink is laid down on paper:
Photo – 1440dpi vs. SuperPhoto – 5760dpi and “high speed” on or off.
I decided to use an extra sheer of paper to see what the differences were.
I first printed 5760dpi with High Speed on (since I never turn that off anyway) using Relative colorimetric and Perceptual. Black Point Compensation was turned on.
Relative Colorimetric vs. Perceptual
In this test image, the biggest difference is that Relative Colorimetric was a bit more saturated in red and green, but showed blue a bit more purple. Maybe because of that, purples also look a bit more saturated. Unexpected (to me) was that oranges seemed actually more saturated using Perceptual.
Relative colorimetric (with BPC) has a touch less separation between absolute black and (6,6,6)
The softproof showed all of these differences as well.
So I decided to use Perceptual for the second set of prints: 1440dpi with High Speed on and off.
What were the differences?
Not a heck of a lot. In all “Perceptual” prints (6,6,6) is barely visible. And I do mean barely. Relative colorimetric is a touch darker even: It’s more of a “I think I might see a difference” there. I cannot see (4,4,4) in any of them.
I don’t think I see a visible difference between 1440dpi and 5760 dpi, nor between high speed on or off. Yes, I did use a loupe.
Maybe the absolute black is a tiny bit denser if 5760 or “High Speed off” is used, but frankly, I’m not sure (comparing the two absolute black patches in the top right, holding them right next to each other in good light).
A measuring device would be needed to make sure. This is also the “I think I might want to see a difference” category.
The grayscale image is neutral to my eye. There might be tiny color shifts in the dark patches, but that could be my eyes playing tricks. If you need absolute neutrality you might want to test, but for my uses, the B&W is excellent.
No use in posting (scans of) prints, since you really need to see this for yourself. Take my word on this.
So. What did I learn?
The softproof is surprisingly accurate.
I cannot distinguish anything darker then L=1 (LAB color picker) in print.
I cannot distinguish anything lighter then L=99 (LAB color picker) in print.
That is ProPhotoRGB (6,6,6) and ProPhotoRGB (252,252,252) respectively.
That’s fairly close to what I see on screen on my CRT in the highlights, with a bit loss of detail in the shadows. I might want to compensate for that.
A good way to do that is described in this video by John Paul Caponigro.
If I have an image with very deep and important shadows, I might try a test print. But for my normal (even critical) printing, I can trust the softproof: If I see detail on screen, I’ll see it in print. And I’m not all that concerned about the absolute deepest maximum black. Since I don’t consistently see the difference anyway.
Conclusion
I certainly do not want to limit myself to a brightest highlight of 95% for my inkjet printing. So I’ll take the 95% in the tutorials with a grain of salt. I did find, when examining a random bunch of images I processed using my normal workflow, that most images have meaningful detail at about that value. So the tutorials at Lynda.com are right in a way, but could be more accurate.
I’m still very much in doubt on the “Newspaper Press” image that more or less caused this blogpost however…
If anyone has good info on that, I’m all ears.
Further reading
Some excellent resources on printing and related stuff:
http://www.johnpaulcaponigro.com/downloads/technique/technique.php#printing
http://www.northlight-images.co.uk/article_pages/black_and_white_test.html
http://www.northlight-images.co.uk/article_pages/test_images.html
http://www.outbackprint.com/printinginsights/pi049/essay.html
http://homepage.mac.com/billatkinson/FileSharing2.html
Tags: Color Management, Epson, Preview, printing, WYSIWYG
Clipping Warnings in Lightroom
Posted by René | Filed under Color Management, LightRoom, Problem, software, web
And why they deceive you
Adobe Photoshop Lightroom, like many other Raw converters, has a clipping warning.
The purpose of it is to give you a visual warning (apart from the histogram) of what parts of an image might be clipping.
What is clipping?
A pixel is clipping when it reaches a value of 0 or 255 in one or more channels, and “should have gone further”. Since it cannot go lower then 0 or go higher then 255, it remains at those values: Detail is lost if one or two color channels clip, part of the image is solid black or white if all 3 channels clip.
The effect of color space
As with anything in digital imaging, the color space used has a big influence: A wide gamut color space (such as ProPhotoRGB) will have lower values for the same color then for instance sRGB. So a color that is clipping in sRGB, need not be clipping in ProPhotoRGB!
This color for instance, has sRGB values of (250,40,30). The ProPhotoRGB values are (177,76,36) for the exact same color.
This means that you have a lot more “headroom” in ProPhotoRGB before you hit the “clipping wall”.
So what?
Lightroom uses MelissaRGB internally (ProPhoto RGB with sRGB Tone Response Curve).
The histogram in Lightroom is based on its internal working space. So when you are exporting images for a web gallery, the images might be clipping big time while Lightroom is not warning you!
An example
I opened a DNG file in Lightroom 2.4 and in ACR 5.4. These have basically the same raw conversion engine. The exact same settings were used in both Raw converters.
Here is the image, histogram and clipping warning in Lightroom. (click image to open bigger).
Almost no clipping indicated (It makes no difference what output color space you choose): Just a bit in the lower right that goes almost black, and absolutely no clipping highlights according to Lightroom:
Here is the image in ACR 5.4. Output color space is ProPhotoRGB: About the same clipping warning Lightroom is giving.
Here is the same image in ACR 5.4. Output color space is sRGB: major clipping!
For reference: Here is the image exported out of Lightroom: Clipping indeed:
Workaround
Is there a workaround? No (except using ACR that is).
Simply sad said, the only thing you can do is watch the histogram, guess, and use your eyes. If your screen has close to sRGB gamut, clipping in sRGB might also be visible on screen (as can be seen from the above screenshots in Lightroom).
If you use a wide gamut screen however, you might see quite a difference between the Lightroom “Develop” module and the actual exported image…
Tags: Color Management, LightRoom, Preview, WYSIWYG
Color management
Posted by René | Filed under Color Management, introduction
An introduction
In the “analog” days, it used to be simple: You had a slide looking like you wanted, and that was a fixed reference point. So it was “somebody else’s problem” to make a print that matched the slide: WYSIWYG. Simple. Or at least: Not your responsibility. Negatives were a bit more complicated, but still: S.E.P.
Nowadays, you’ll have a file that looks good on your screen. Since you probably don’t want to lug your computer and monitor with you anytime you want to make a print, only to be able to show what you think the print should look like, how do you manage to get a print that looks like the image on your screen?
The keyword
…of course, is “manage”. As in: Color manage: “Out of the box” every monitor will display an image different. Ever seen a store with 20 televisions in a row? All TVs looking different? Same will be the case with computer monitors if you don’t take countermeasures.
While the TVs pretty much boil down to “personal preference”, with digital imaging it’s about accuracy.
How to be accurate?
That is your responsibility: You need to make sure your display looks the same as everybody else’s. To do that you calibrate and profile it: Calibration makes sure your screen is at a fixed state. Profiling creates an .icc profile and makes sure a certain color is displayed exactly so. The best way to do this, is to use a hardware device, such as for instance Spyder3, iOne Display or ColorMunki.
The managing
…of the colors is then done by your (color managed) software, such as Photoshop for instance.
It looks at the images .icc profile and at your display profile, and does a conversion between the two. Thus making sure that the colors are shown as they should.
The beauty of it
…is that the printer also has should have a calibrated screen, so will see the image exactly as you do. So he can see what he should get. If he then also correctly uses the software to print color managed, you’ll get a print that’s as close to the view on screen as possible. In fact, in that case it’s even easier then it used to be in the analog days!
Only remaining difference is caused by the fact that your screen is a device emitting light, while the print is reflecting light, and the fact that there are some colors that can be displayed but simply cannot be printed (and vice-versa).
That’s where softproofing comes in… But more on that in a future blog post.
Tags: Color Management, WYSIWYG
Firefox 3.5.1
Posted by René | Filed under Color Management, Problem
and LUT profiles
In my previous post, I wrote about Firefox 3.5 “better wait for version 3.5.1″
That version was released today, and I’m sorry to say, It still has its problems:
For one thing, it still doesn’t support ICC V4 profiles.
For another, by default it color manages like Safari does: Wonky: Only images with embedded profile are managed. So you could get problems as described on this page: The image looks different from the background.
On my Mac, it didn’t. What the heck? I hadn’t changed it from the default setting…
No matter what I set in the “gfx.color_management.mode”, it looked like the thing kept managing everything (except when setting “0″ off course). No way to get the images on that page to look different from the background. “Here be dragons” indeed.
But wait, there’s more
The background looked different from the background of the same page opened in (fully colormanaged) Flock 2.5. In fact, the background looks like the page opened in Safari. Yet there was no change on the images with and without profile. Another “what the heck”? I’d already checked that images with embedded profile were color managed…
At first I thought that FF 3.5.1 might be doing a perceptual rendering for screen. That would explain why for instance on my laptop the image I used in the previous post doesn’t clip in FF3.5.1, but clips like mad in Flock 2.5. It should clip; it’s way out of the laptops gamut. However, a perceptual rendering should not be possible from an sRGB V2 profile, and even if it were, it would probably be visible on series of the same image with different color spaces: the Perceptual rendering would be different for each color space… Yet the tagged images here all looked the same. (And all undersaturated)
What’s going on then?
Then I found out (using the OSX DigitalColor Meter) that the image in FF3 measured the exact value of the sRGB original in Photoshops info palette. So here’s what I think was happening:
FF 3.5.1 converts tagged images (so that part is color managed), then doesn’t use the monitor profile (byebye color management). Manually setting the correct display profile didn’t help either.
Cause of the problem
Since it looked like the problem was related to my Monitor Profile, I tried calibrating anew. Bingo! FF 3.5.1 does work as expected as long as I create a “standard” (Matrix based) monitor profile: My previous profile was created using the setting “Create Table-Based (3D) Profile” of my Monaco Optix XR-Pro software, since that gave more accurate results… No idea why FF 3.5.1 won’t use it. This is a V2 profile as far as I know.
Needless to say, there’s a bug report on the way…
Tags: browser, bug, Color Management, firefox
The world wide web
Posted by René | Filed under Color Management, web
and color management
A lot of people are confused the first time they save an image for web display: The image looks different in a non color managed browser then it did in Lightroom or Photoshop. One “solution” was to view the image in Photoshop like it would appear in a non color managed application, by going View > Proof setup > Monitor RGB. This would show you how the image would look in a non color managed application on your screen. Still a guess what anybody else would see though, since you’re seeing the difference between the monitor profile and sRGB…
Better
A much better option would be for everybody to browse color managed.
Up until recently, most browsers were not color managed. Safari changed that, and was the first color managed browser for PC. Internet Explorer had provided a color managed browser for Mac OSX before that, but it is discontinued now.
A few new options arrived lately
FireFox 3 is color managed, though the feature is disabled by default. If you enable it, it’s a heck of a lot better then Safari in my opinion, since it fully color manages: It rightly assumes sRGB on untagged images (Safari stupidly assumes Monitor RGB, except on Vista), and it does so for backgrounds as well. So no more Safari Wonkiness…
Firefox gets even better tomorrow, when version 3.5 is introduced. It has color management enabled by default.. There is a bug however when using wide gamut monitors. So those of you on a wide gamut screen, better wait for version 3.5.1…
Easiest way to enable color management in FF3.0, is to use the Add-On. Nice to note that this Add-On also works for Flock, the browser I’m currently using.
OmniWeb 5.1.3 is color managed when set to be in the prefs.
Another color managed browser will be the upcoming version of Google Chrome. Yay!
Join the majority
Looking at the statistics of this blog, about 53% of the visitors use Firefox, 21% use Safari, 19% use IE and 3% use Chrome. So chances are that a whopping three quarters of you could be browsing color managed! That’s a big majority.
Since more and more people will be browsing color managed, the last part of the advise many times given in the past; “web images should be sRGB, without embedded profile“, is no longer valid in my opinion. Also, a lot more people use wide gamut screens, on which non color managed browsing is a horridly over-saturated experience.
Where does Photoshops “Save for web” fit in?
The save for web dialog box changed a bit after CS2, and now also gives you the option to convert to sRGB. In PSCS2, you had to do that manually. It still gives you four different ways to preview your image: The same options you get when you go View > Proof Setup.
What a lot of people don’t realize is that these viewing options can be set for each window separately.
First, let’s see what each option does:
“Monitor Color“: As a non color managed application would show it on your screen.
“Macintosh (No color management)” As a non color managed application would show it on a monitor with gamma 1.8 (ancient): The image appears lighter.
“Windows (No color management)“: As a non color managed application would show it on an sRGB monitor. An sRGB image will look the same here as in the last option. An AdobeRGB or ProPhotoRGB image will appear less saturated.
“Use document profile“: As a color managed application would display it.
What does it look like
For demo purposes, I used an image in ProPhotoRGB that shows a massive amount of clipping in sRGB. I also used my laptop, which has a rather crappy screen, so the differences between the monitor profile and sRGB are obvious.
The window showing the “Original” is set to “Document profile” in all screenshots. Again: You can set the view for all windows separately. So when using “4-Up”, you can compare the original to an approximation a wild guess of what non-colormanaged browsers might show other users.
First screenshot: ProPhotoRGB, without converting to sRGB, Preview set to “Monitor Color”. Horrid, and the reason for many posts on photography forums.
Second screenshot: converted to sRGB, Preview set to “Monitor Color”. Quite a bit off, but does show why you should use sRGB for the web.
Third screenshot: converted to sRGB, Preview set to “Document Profile”. Nice Match.
Note that the image is way out of the Powerbooks gamut. So it appears a lot less saturated in that color space, because it’s clipping like crazy. (Naturally, the screenshots were converted from the powerbook profile to sRGB before posting) Compare the sRGB version below with the one restricted to the Powerbooks displays gamut in the above screenshots.
Additionally, the clipping that’s occurring while converting to sRGB doesn’t show on the Powerbook, since the monitor gamut is smaller then sRGB. On my desktop with LaCie CRT, I can clearly see the clipping when toggling the “convert to sRGB” tickbox. If I were to post this image, I’d correct for that clipping before converting…
So, all in all “Save for web” is a very useful tool that provides not only “WYSIWYG” , but also provides a guess to what others might see.
Lastly, for those interested: Here’s a screenshot of the difference between Gamma 1.8 and 2.2. A good reason to use Gamma 2.2 and I’m glad to say the next version OSX will finally ship with Gamma 2.2 set as default, instead of the legacy Gamma 1.8.
Tags: browser, firefox, Save for web
PSCS4, OsX and Epson…
Posted by René | Filed under Color Management, Problem
part 2, not the best news
In my previous blog post about the subject, I mentioned a workaround for the bug, and also said I didn’t like the idea of converting to GenericRGB somewhere in the process since it might clip colors…
Gave it a quick try today, and yeah, it does clip “somewhat”…
Same image as last time. Original is AdobeRGB. In this image, some purples and dark blues are out of gamut for the R2880, using Epson Premium Glossy paper. Admittedly, not your “average” color palette, but one that does show problems if they are there.
Softproofed
Let’s start by showing the original converted to sRGB;
(again: all screenshots converted to sRGB for web display)
Nice and colorful. Not that big a difference from the AdobeRGB original. (It’s only slightly out of sRGB gamut in the shadow areas.)
When softproofing for the Epson Glossy Paper profile, you see a difference, but about what’s expected. Purples turn a bit blue-ish. Not a huge problem in this case I’d say. Not worth a screenshot. If it were a problem, I’d correct it while softproofing.
Okay, so far so good.
Now apply the workaround: Convert to the paper profile. No change obviously, since I was already softproofing. Then assign Generic RGB. Totally whacked colors. Also to be expected and also not worth a screenshot.
If the workaround were without drawbacks, the image would be sent to the printer and be converted from paper profile to GenericRGB somewhere along the lines. But since we “compensated” for that by assigning the GenericRGB profile beforehand, you’d expect the results to be the same: The printer gets the right “numbers” sent… But are the numbers the same?
Timeline, step by step.
This is what the image goes through:
- Open original in PSCS4. Softproof & edit as needed
- Convert to printer profile (workaround step 1)
- Assign GenericRGB (workaround step 2)
- Press “print” in PSCS4
- Convert to printer profile (by PSCS4s print engine)
- Convert to GenericRGB (done by OSX because of this bug)
- Assume printer profile. (by the R2880, because it knows nothing about color management, and just prints the data it gets)
The problem lies in step 6: (For those interested: It’s easily reproducible by doing the same steps manually in Photoshop.)
The image after step 5 is massively out of the GenericRGB gamut, as shown here:
The funky colors are the result of assigning GenericRGB in step 3 obviously.
This results in clipping. Big time.
The result…
…is a print that is way less saturated then it should have been: Top left would be like printed from PSCS4 using the “workaround”, bottom right is the print that PSCS2 would produce:
I hope that this bug gets fixed pronto. I know I’ll keep using PSCS2 for printing in the meantime… Which sucks is a bit of a drawback quite frankly.
(Again: Apple and Epson: Are you reading this?)
Tags: bug, Color Management, Epson, OSX10.4.11, PhotoshopCS4, printing, workaround
PSCS4, OsX and Epson…
Posted by René | Filed under Color Management, Problem
don’t seem to play nice together.
When testing my Epson R2880 on PSCS4, it was quite obvious that something was off; The print came out looking nothing like the softproof on screen.
To give an indication of what it looked like: Here is a splitscreen: Top left is the softproofed image, bottom right is what the print looked like:
(screenshot converted to sRGB for web display: The difference is bigger in print)
The same image printed from PSCS2 was a perfect match to the softproof. Very weird.
I remembered that another photographer had complained to me about similar issues, and showed me some pdf files in preview. (In OSX you can preview a print as pdf file in Preview).
So I tried that. What a surprise: pdf generated when printing from PSCS2 was entirely different from the one using PSCS4. Same printer driver, same settings in Photoshop, same everything.
Neither of the pdfs looked even remotely like the respective prints by the way. The PSCS4 pdf looked like the softproof (as did the PSCS2 print).
Getting weirder by the minute.
A search on the net only brought up a “Double profiling” issue in OSX 10.5.something. Not what I was experiencing. Also, I’m running 10.4.11.
So, I decided to investigate further.
The pdf generated when printing from PSCS2, has an AdobeRGB1998 profile embedded. No idea why, since it is obvious the wrong profile (should be the paper specific profile for the R2880 I’d think, but that also isn’t the case)
Even weirder, the PSCS4 pdf, had a GenericRGB profile. What? Why on earth… That one has an even slightly smaller gamut then sRGB as far as I know…
Workaround
Some messing about testing with profiles followed.
It turned out that converting the PSCS2 pdf to GenericRGB, then assigning the paper profile, gave two identical images (easier to compare that way around, since the pdf coming out of the PSCS2 print path was very saturated and weird looking because of the wrong profile). Both were now again looking like the softproof in Photoshop.
So, doing the reverse (Convert to paper profile, assign GenericRGB) should give a decent print out of PSCS4. (at least, looking at the pdf. Haven’t wasted any paper on it yet).
So far for a workaround, now for the explanation…
Including “GenericRGB” in the search term proved to be a good idea. On the Adobe Forums I found a thread about grayscale printing (no wonder I hadn’t found it earlier).
In that thread Eric Chan explains how OSX Leopard will convert the image data to Generic Gray or Generic RGB before handing it off to the driver. So, yeah. That’s likely to screw things up…
I’m still not sure why or where the PDF out of PSCS2 gets an AdobeRGB profile. Seems rather silly if you ask me.
I might use the workaround when in PSCS4, or print from PSCS2 until this issue gets fixed… I think I’ll mostly use the latter, since I don’t like the idea of converting to GenericRGB somewhere in the process; it might clip colors without me having any control…
Have to compare a few prints, to see if there are differences.
Edit: The workaround does have its drawbacks: See my next blog post.
(Apple and Epson: Are you reading this?)
Tags: bug, Color Management, Epson, OSX10.4.11, PhotoshopCS4, printing, workaround
Hello world!
Posted by René | Filed under Color Management, General, introduction
First blog post.
Ever.
At least, on my own blog (to be).
I’ve commented a fair bit on other people’s blogs, when the subject was Colormanagement, and someone presented wrong facts. For instance if it was recommended to set Photoshop to use “Monitor color” as working space, since then anything would look the same in Photoshop and the (not color managed) browser. Color management just went right out the window, as well as any chance at consistency…
Therefore, I believe this to be *bad* advice, so often I’d comment something along those lines, or sent the poster an email. I can’t stand misinformation. I’m kinda funny that way.
Because I’m kinda funny in other ways as well, I also like to know how stuff works. (And if possible, also why)
That sometimes leads to hours of searching as to why something doesn’t work as expected, instead of just accepting the fact and get on with what you were doing… So probably not the best practice, both for your social life, and in the business kind of way. For the last, I couldn’t care less, and my social life is okay, thanks very much. Also, it is satisfying my curiosity has the added advantage of getting to understand the problem better, which gives an advantage when you engage other (peoples) “irrational” problems.
So, what to expect here then?
I have no idea yet. I don’t even know if it’s going to be a regularly updated blog, or more “website-like, static” approach. I’m not completely without a clue however:
First, I plan to post a few simple posts on the “how and why” of color management. Just to cover the basics. I’ve posted the same (or similar) on POTN.
Incidentally, that forum is probably what inspired me to start all this: I started a thread there a few years back about color problems. Due to my lack of organisation, limited knowledge at the time (and not locking the thread), it became what was lately accurately referred to, a “Huge meandering thread”. This blog is my penance, and an effort to bring some order to that chaos.
Later on (when I get comfortable with blogging), I’ll probably also post solutions whenever I encounter a problem (For instance: PSCS4 seems to have a bug regarding color managed printing, looking in to that as I have time to spare, I’m using PSCS2 until then)
I sincerely hope that later posts gain in structure compared to this one, and also are a bit more relevant. But this is at least better then the default “Welcome” post by Wordpress… (And there’s no-one around to see it anyway).
