Skip to: Navigation | Content | Sidebar | Footer

Full Archives

Shifting Back

June 18

Colour profiles in imaging applications are a sticky issue at best. The path of least resistance when producing web graphics is turning them off entirely and ignoring the whole mess, which is pretty much what I've been doing for years.

The basic theory is this: a colour profile acts as an interpretation layer, and adjusts the colour values of the pixels you're working with for consistency, richness, and other reasons. The net effect is that your RGB value of 255, 12, 12 might end up being rendered as something closer to 255, 0, 0 on-screen, while still being saved out with the original RGB values. That means if you don't have the benefit of the original colour profile, your output ends up looking a bit different than your working copy; usually with duller colours and a lighter overall tone (or darker, depending on which profile you're using).

This colour shift explains why turning off colour management is generally not a bad strategy when producing output for the web. No browser other than Safari supports colour profiles, so there's no benefit to using them. Not to mention that in many cases you'll find yourself matching RGB values between your image and your CSS, and because CSS isn't profiled it's a more difficult task if you have a colour profile to contend with. The closer you can get to actual RGB values, the saner you'll stay

I'm bringing this up because I've been working off of two computers lately, and until recently I wasn't paying much attention to the fact that the profiles were mismatched between them, thus affecting my source files. Unless I pay meticulous attention to the dialogues that pop up asking me what I want to do about the situation, when I save out graphics I end up with images sitting on top of slightly more vibrant background images, causing visible seams where there's clearly a colour shift occuring.

Googling didn't come up with any solid way to deal with this, so I've had to figure out a way to shift colours back from their profiled version to more accurate RGB values, and then make sure that information gets saved out when I'm creating my final GIFs & JPGs. Here's what I came up with.

No assigned profile

Figure: image with no assigned colour profile, saved to GIF format.

First, I've found some applications in particular (Illustrator, I'm looking your way) seem to have trouble remembering that a colour profile has been assigned. So if I'm working in sRGB space for example, every time I load that document I have to assign the sRGB profile. Annoying.

So that's the first step, making sure that the profile is actually assigned. In most Adobe apps, the action should be found under Edit > Assign Profile. What you assign is up to you, the trick is to make sure that the current profile matches what the document was created with. I'm using sRGB here.

sRGB profile

Figure: image with sRGB profile, saved directly to GIF format. It's effectively identical to the previous image, which had no profile assigned.

Now if I were to just save them at this point, the GIFs and JPGs will have simply discarded the profile during the saving process and I'd end up with an identical result to previously, where I'd saved them without any profile information.

The key lies in conversion. Photoshop has the ability to convert between profiles, and keep colour levels relatively intact when doing so. What we need is to take the now properly-profiled sRGB file and convert it back to raw RGB values. Under Edit > Convert to Profile, you get a "Destination Space" dropdown that will allow you to choose between various profiles. What you want is your monitor's working RGB profile (which is effectively the same as saying "no colour management at all"). On my iMac, the option I select is called "Working RGB - iMac". If you don't see an equivalent for your monitor, you could select "Generic RGB Profile", but it's probably best to first load up Photoshop's global colour settings (Edit > Color Settings) and make sure your default RGB space is set to "Monitor RGB". If it's set as your default, your monitor's profile ought to show up in the destination space dropdown.

After this step, you've now converted the profiled version of your document back to raw RGB, but kept the colour levels similar to what the profile enabled. Save the file, and now you're free to save out to any image format without a colour profile. The result will be much closer to what you originally intended.

No assigned profile sRGB profile converted to monitor colour

Figure: the top image is the same unprofiled example as above, while the bottom image was converted from sRGB to monitor colour and then saved to a GIF file. Note the slight colour difference.

That's Photoshop, but what about Illustrator? No such luck. It allows you to assign a profile, but there's no Convert option in the menu. Illustrator's help file says that conversions can be performed in Photoshop or InDesign, but mentions nothing about doing it directly in Illustrator. The only fix I've found so far is saving out my Illustrator file as a PNG, then loading it in Photoshop and following all the steps above. Not ideal, but it gets me where I need to go in the end.

Note that this is all written while using Adobe's CS2 suite; I'm not sure how CS3 changes things, but in particular, I'd certainly hope that Illustrator CS3 has taken a few steps forward in the way it handles colour profiles.

Permalink › | 25 comments

iPhone Apps

June 14

There's been a lot of talk about the recent WWDC announcement that iPhone applications are going to be entirely run through Safari at this point.

I present one very simple reason why this just isn't good enough:

Canadian Mobile Data Rates chart

Figure: Chart of Canadian mobile data rates. Credit: Boris Mann

Update: A few people have said in the comments now that it will be possible to store the applications locally and run them without incurring airtime charges. In the WWDC keynote, I saw Safari bookmarks being used as the method for launching an app, but it's possible I dozed off during the part where this local-access method was explained. Given there won't be an SDK, I'm also curious how the UI will enable this.

If you can link up somewhere on Apple's site that explains how this is supposed to work, leave it in the comments. Thanks!

Permalink › | 58 comments

A Subpixel Safari

June 12

Safari for Windows? Sure, why not. May as well ride the popularity wave and see if you can't get another product or two into the hands of the masses.

Of course, we all know by now the only way to get massive amounts of users to use a particular browser is to bundle it. For all the pubilicity and popular opinion, Firefox is still sitting at what, 15%? Good luck climbing that hill without force-installing Safari during an iTunes upgrade. It can't hurt to have another browser on Windows, but I don't exactly see a major revolution happening here. (Jon Hicks and Jonathan Snook have a few more thoughts on yesterday's Safari news.)

But what really caught my eye though is the trouble to which Apple has gone in order to mimic the OS X Safari experience on Windows. Everything from window sizing controls to scrollbars to font smoothing. There's an ironic point to be made here about how much complaining is directed at applications that don't make an effort to be Mac native when run on OS X...

Joel Spolsky took particular issue to the font rendering, using the release of Safari to rant at length about the philosophy difference between Apple and Microsoft when it comes to displaying on-screen fonts. He's absolutely right about familiarity affecting judgment, to the point where simple unqualified statements like "I prefer OS X's font rendering" are fairly useless in a debate about any relative merits between the two operating systems.

What I really wanted to respond to are two points in particular from Joel's post. One, the bit where he says, "Microsoft pragmatically decided that the design of the typeface is not so holy, and that sharp on-screen text that's comfortable to read is more important than the typeface designer's idea of how light or dark an entire block of text should feel." Marginalizing type designers is a pretty poor way to make any sort of point about typography, given that entire careers are based on an understanding of legibility and facilitating ease of reading. A statement like that one almost veers into dangerous "programmers knowing better than experts in their respective fields" territory, which I can't imagine was his goal. Joel's a smart guy, I'm sure it was unintended.

However, lest the larger issue go unheeded, that brings us to the second point. Joel talks about the pixel grid, and how Microsoft's type rendering pays more attention to it. Speaking as someone who thinks a lot about the pixel grid, I have to say I think I'm coming around to the idea that Microsoft's ClearType simply works better.

Alright, I'd better qualify that quickly. Think about it this way — as a designer, you don't just set type in Photoshop and let it go, right? You tweak. You kern. You attempt to match the letters to the pixel grid as closely as possible to reduce the blurriness. Sometimes spacing suffers, and you have to choose between a slightly blurry letter with perfect spacing, or a more precise fit within the pixel grid with just slightly off spacing. I can't be the only one that leans toward the latter most times.

And that's the difference here. ClearType is a closer match to what I do manually already. Yes, I prefer the way type on OS X looks; ClearType seems too sharp and overly blocky, the subtleties of the curves are lost and it's overly chunky. But, for the medium in which it's being rendered, it seems like a more ideal solution.

Here's the caveat though — high resolution displays. At 100dpi, ClearType wins out, but we're not going to be stuck here much longer. Give it a few years, let's do this comparison again when 200dpi is standard. I suspect the pixel grid won't matter nearly so much then.

Permalink › | 41 comments


June 5

Like watching a random stranger going through your personal belongings in the customs line, it's a fairly unsettling feeling knowing that someone else has been able to make changes in your own markup under your nose. Here's what happened, best as I can tell.

A bit more than a week ago, tired and jetlagged, I received an email that my site had a bunch of hidden links at the footer of every page. Links that looked suspiciously like spam. My immediate reaction was incredulity, and sure enough when I looked, no such thing existed. I wrote off that complaint as someone getting caught in a frame, or browsing with a spyware-infested PC, and forgot about it.

Then a few days later, I received a similar message from someone else. One was easy to dismiss, two was curious. I viewed source again, but this time, there they were. A series of a few dozen links to otherwise innocuous sites, with obviously spammy drug-related keywords. All wrapped up in a <u style=display:none>. Presumably the invalid code is how people were stumbling across them.

Example Spam Links

Figure: Screenshot of the server version of a page with the spam links in question (with absolute paths to included files intentionally obscured).

After some digging, here are the bits I've managed to piece together:

  • The links the first person saw were different from those the second person and myself saw afterward. That they changed, combined with the fact they only appeared to be visible at certain times of the day, leads me to believe that the links were inserted multiple times. It seems like someone had a script doing this automatically, because...
  • The links were inserted directly into the files sitting on the server. There was a clear pattern: any file named index.php or index.html had them appended to the end, after everything else in the file. The script started from the very root of my user account on my web server, and went four levels deep. Since I host multiple sites on the same server, every single site on this server was affected.

That left two questions. One, how did this happen? And two, how do I fix it? The second question was easy enough: manually recurse through every file affected and delete the links one by one. A huge time-waster, and it killed an entire afternoon last week, but it worked. That bought me some temporary relief, but given the already-observed recurrence of these links, I had to dig deeper and get to the root of the problem.

After a few emails with my host, they were pointing the finger at unspecified PHP security holes. There's probably no way to tell specifically how this happened, they say; the log files would be a nightmare to sift through.

Since this site does use PHP in a few spots, I only had a few guesses about where I should be looking to fix the problem:

  • First thing I did was change my password, naturally.
  • Then I upgraded to the latest version of Movable Type. Previously I was on 3.2, now I'm up to 3.35
  • And then, armed with tutorials and books I started guessing at where my PHP might be in error. This felt like stabbing in the dark, especially because the user-facing scripts I've written already had a bunch of data-checking built in. But there are a few other low impact uses of PHP along the way which didn't necessarily seem to need the extra scrutiny at the time; those I've gone back and tightened up quite a bit.

Cumulatively, that may have worked. A week later I haven't seen another recurrence. I don't feel out of the woods quite yet, but I'm crossing my fingers.

So let this be a cautionary tale for anyone using any sort of dynamic code or CMS on their site: security matters. Stay on top of updates. Change passwords regularly. All that stuff they tell you to do, it's for good reason.

Update: From the comments, it appears that numerous people are experiencing this problem. It also appears that there are two common threads amongst those who have suffered it: they host with Dreamhost, and/or they use Wordpress. It's not exclusive; some who host with Dreamhost don't use Wordpress, and some host elsewhere but do use Wordpress.

For those who host with Dreamhost: I received a confirmation email from them at 8:27pm PST on June 5th that yes indeed, something in the neighbourhood of 3,500 FTP accounts have been compromised. If you're on Dreamhost, time to change all your passwords, and check your sites for mischief. They haven't posted an official announcement anywhere so I can't link to it, however they recommend keeping an eye on their status blog for updates as they come in.

So in the end, it looks like there was nothing I could have done to prevent this one aside from host elsewhere. Just goes to show how important backup is, local and remote. Here's how to use rsync to back up your entire web server, from a few years back.

Permalink › | 109 comments