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.
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”.
Read the rest of this entry »
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.
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).
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.
Read the rest of this entry »
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.
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…
Read the rest of this entry »
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! Read the rest of this entry »
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?
…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.
Read the rest of this entry »
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… Read the rest of this entry »
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…
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.
Read the rest of this entry »
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.
Let’s start by showing the original converted to sRGB; Read the rest of this entry »
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…
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?)
First blog post.
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).