Skip to: Navigation | Content | Sidebar | Footer

Full Archives

Shifting Back

June 18


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


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.


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


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


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

Canadian Mobile Data Rates chart


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.



Example Spam Links


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



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.


  • 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.


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