TV version (Display Regular Site)

Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

GIF Hacking

September 08, 2004

Common knowledge says that modifying a compressed image is a bad idea. Not always, though.

A somewhat bad habit I’ve fallen into over time is making an adjustment to a GIF file without modifying the Photoshop source. I open a GIF directly, edit the pixels in situ, and then overwrite the original. The GIF becomes my source, as the original PSD file that it was generated from falls further out of synch.

Of course, the classic wisdom of common web file formats is that if you’re going to edit an image, you have to re-create it from a master. Because web compression tends to be lossy, having the source PSD on hand is a must.

…but that’s not always the case. JPG files are lossy, sure, and you’d never want to use a JPG as your master if it can be helped. But theoretically GIF is a lossless format, once you get around the 256 colour limitation. Provided you save the file with the same colour index each time, you won’t lose any detail after each edit.

Take the following image for example. Let’s say you’ve started with an overly large corner for your rounded boxes.

Original image on left, three variations on right.

There’s probably no need for such a large image, so by cropping to look like the top right ‘after’ result, you can save a few bytes. Or if you need just the edge pieces, a quick crop can pull out the top and left edges as separate images, as shown in the bottom two ‘after’ results.

Point being, you’ve already optimized the larger image — you could go back to the original PSD and re-save, or you could drop it into Photoshop and just crop the smaller images out. They’ll be (mostly) optimized, and you’ve saved about 3 steps in the middle between flattening your layer effects, cropping, optimizing and saving.

In fact, if all you’re doing is cropping, resizing or the occasional pixel-level tweak, you don’t even need to go through the whole File → Save For Web dialogue either. Open the GIF, modify the pixels without first converting to another colour space like RGB Mode, and then re-save using File → Save. If you haven’t changed colour modes, the color index is preserved, your compression tweaks are re-calculated automatically, and you don’t lose any detail because no new colour information has been added on top of the original GIF.

What if you’ve spent time applying a dither mask, or enabled lossy GIF compression, or a number of other variations that will affect the file size and quality of the original image? That’s where it becomes muddy — if the starting GIF isn’t of reasonable quality, you probably wouldn’t want to use it on your site anyway, but there may be times when a GIF shouldn’t be manipulated this way.

Assuming the starting image is workable though, the compression algorithm WILL pick up these effects on re-save and you won’t have to spend time applying them again. Compression is applied after all other effects like dither and lossiness have worked their magic, so a dithered GIF will always be compressed the same way. (Try it if you don’t believe me — dither a high-colour GIF, save, and then open and re-save without dither… if your colour settings match, the resulting files will be the same size.)

The big problem with working this way is source control; over time, the images for your site fall further and further out of synch with the master Photoshop files. I’m not actually convinced most designers could refer back to a contained set of source PSD files for all graphics anyway, especially later on in the course of a site’s life… but that’s another thought for another day.

Addendum: And all this applies to PNG too, of course.

Reader Comments

September 08, 02h


This post brings up a question you may want to answer in a future post: what’s your typical web development process? How do you go about designing, slicing, optimizing, placing, etc. your web graphics?

Is Photoshop your only tool? What screenshot utility to you use? What about large batch processes — what do you do for those? Do you keep separate source files for each step/version of your concept design? Do you even MAKE a concept design?

Perhaps it could even be a community-affair (show-and-tell of the web’s best designers)?

September 08, 06h

Dave: Based on the information you’ve given me, I took a moment to run some tests to see for myself. I appreciate the care by which you chose your words, by the way.

I have an internal-only site that uses transparent .pngs generated with a version 4 of Photoshop (the latest I have :), and they display just fine in Safari, but the transparency is, of course, lost in IE/Mac.

You’ve indicated that Fireworks might have done things differently, so I went to download a trial version and generate a .png to see for myself if a Fireworks-flavoured .png would work in IE/Mac.

It didn’t.

At any rate, this doesn’t really prove anything, except maybe the impossibility of getting IE to render the gamma channel if some other program encoded that data differently. I certainly know next to nothing about the particulars of the png specification, and it may very well be that there is no way of adding gamma that IE will like, because IE will flat-out refuse to render gamma under normal circumstances.

Was it wasted time? No. Knowing what doesn’t work is, in this industry anyway, as important as knowing what does work.

Apologies if anyone felt this post was off topic, however I feel justified knowing that the loop is somewhat closed with this mini-investigation and followup. I would hate for someone to surf through this a month from now and start a meme based on misinterpreted information.

Tobin Jones says:
September 08, 07h

Actually, I think that editing the GIF rather than the PSD has one major advantage that no-one else has pointed out: Color matching. If I edit the original source and then re-save it, depending on how much I’ve changed it, there are no guarantees that Photoshop/Fireworks will choose *exactly* the same color table and dithering pattern. This is particularly important if, for example, the corner of a subtly shaded box has to match up with its top. Small discrepancies in the encoding are often horribly apparent. Editing the GIF (and keeping the color table unchanged) this problem is guaranteed to just go away!

Dave S. says:
September 08, 08h

Robert: “the transparency is, of course, lost in IE/Mac.”

Whoa, you went left after I went right. Gamma isn’t the same thing as tranparency. Gamma is hard to succinctly define - - but it’s basically about the brightness of an image on a screen. Gamma within PNG is a setting that affects the brightness on the destination monitor, which is where IE has trouble.

My previous comments don’t apply to transparency issues at all, and in fact, IE5/Mac seems to do fine with PNGs with alpha transparency — for example. (I’m checking IE5.2 on OS X; you may be using an older version.)

AkaXakA says:
September 08, 08h

It is indeed tempting to just directly adjust the images used on the site, instead of going back to the photoshop file.

However, using the psd (either original, or a copy) isn’t just good for source controll, it makes it easy to see how the change will reflect on the rest of the site.

Of course, when all you want to do is change one pixel, changing the gif/png/whatever will allways be too tempting to resist.

September 08, 08h

i prefer to do all my work on PSD format and export to JPG or PNG, better than use GIF format.

Dave S. says:
September 08, 08h

“it makes it easy to see how the change will reflect on the rest of the site.”

Ah, but that’s what screenshots are for! The other half of the equation, for me anyway, is gratuitous use of screenshots. Perhaps I should write that up too.

September 08, 08h

You assume that all web authors use Photoshop :-) My master files are .PNG which I open with Fireworks and then I might optimize them… usually the gain is minimal since I rarely use layers or other fancy stuff that would require of Fireworks to store a lot of metadata in the .PNG.

As a programmer, when I work on large projects, I might use a command-line PNG optimizer as part of the project’s build script.

I don’t want to start a “holy war” on this issue, but 8bit PNG is overall better than .GIFa.

Dave S. says:
September 08, 08h

“You assume that all web authors use Photoshop”

Not at all, but the article was tailored toward the ones that do.

“8bit PNG is overall better than .GIFa.”

In most ways, but I’ve long preferred GIF due to IE/Win having problems with the gamma in PNGs that come from Photoshop. It’s been a long while since I’ve tested this, but I believe it even holds true in IE6.

seth says:
September 08, 08h

I’ve done this from time-to-time, and find it to be perfectly suitable. Unless you are putting something out to a “designer” audience, the vast majority of your users will overlook any imperfections you get as a result.

September 08, 08h

“The other half of the equation, for me anyway, is gratuitous use of screenshots.”

Likewise here, Dave. I’m constantly taking screengrabs, then bringing them back into PS for slight little tweaks, etc.

I’m thinking this has much to do with the switch from “slicing up” PSD files for a table-based layout, to using CSS and creative placement of background images.

Somehow for me, the PSD is always the starting point, but then completely falls out of synch as the design and code are finalized. I don’t particularly like that it happens, but it always ends up that way.

Josh says:
September 08, 09h

It gets even worse: Safari screws up PNGs when there is no gamma information or an embedded color profile (see , ). Of course, IE displays those PNGs just fine. :\

PNG is lossless and has full alpha transparency, but since about 3% of your audience will have a browser that ‘gets it right’ (read: a Gecko-based browser), you just may want to stick to GIF a while longer.

Joshua Woodcook says:
September 08, 09h

I’m a screenshot culprit as well…only thing is I often end up with a frankenstein-ish psd file built out of chopped up screenshots and all my little tweaks….

It would probably be easier to keep the original psd all along!

Luke Shingles says:
September 08, 09h

Josh - “but since about 3% of your audience will have a browser that ‘gets it right’ (read: a Gecko-based browser)”

It’s closer to 15% now depending on where you get your stats. Opera and KHTML (and most likely every other modern browser) also work fine with 32-bit PNGs.

Bryan says:
September 08, 09h

I guess it depends on who the site is for. If its personal, then sure, your not going to hand over the site and all its contents to some person. But if its a client, for example, you may want to keep that source file around in case people have to leave, change business’s,etc…

If you run a website and need to sell it, then providing the new owner with your source photoshop file could be beneficial to them.

I think, if anything, its good form and habit to do your “best” to keep the source file as close to the main set of elements that represent your website.

No one is perfect, but I think as long as the source doesn’t stray too far from the current copy, then its ok.

My site looks quite different then my source, so I am not really practicing what I preach :)

Nyxen says:
September 08, 09h

I had problem with alpha stuffs in PNG, and with Windows NT (at university) computers displayed a grey color instead of transparency. I finally solved my problem by using gif web dither but it’s a bad thing that IE, or at least older versions can’t understand PNG transparency. Even if most users use IE as web browser, I prefer Safari ‘cause it looks like IE is slowing web development…

September 08, 10h

Dave: You said something in a very interesting way: “I’ve long preferred GIF due to IE/Win having problems with the gamma in PNGs that come from Photoshop.”

Are you saying that IE/Win *won’t* have problems with the gamma if the PNG was created in another program? If so, what programs would those be?

Dave S. says:
September 08, 10h

“Are you saying that IE/Win *won’t* have problems with the gamma if the PNG was created in another program?”

As I said, it has been a while since I’ve looked into this, but I believe at the time of comparison, Fireworks handled the gamma issue differently than Photoshop.

Because gamma is a value that can be adjusted, it’s not inconceivable that two software packages will produce different results. I just don’t have hard data to back that up.

September 08, 11h

Hmmmm…I have been looking for a program that displays the screenshots of my website the same way does the screenshots? Anybody got any? Sorry for straying slightly off topic :P

Sophie says:
September 08, 11h

Screenshots : if your system is MacOsX, look into webkit2png.

Using the command line, you can specify screen width and height, and get screenshots like without owning a 23” display.

Nathan says:
September 09, 03h

Editing GIF’s in situ as you say, is defiantly nothing short of a habit, though I personally can’t say that it’s a bad one.

I find myself constantly chopping and changing my GIF’s to fit (even more so since I have been using tableless layouts). However I have attempted to place myself in the habit of either saving the “new” PSD temporarily, or more commonly, duplicating the resulting GIF/PSD product into my original source PSD. This will at least allow me to edit further without the loss that can be associated with countless re-hashing of the humble GIF in question.

This practice has saved me a substantial amount of time in some cases, particularly when it comes to ‘difficult’ clients who don’t like that shade of blue or purple. etc!

So I suppose in my opinion it’s not a bad thing as long as you can maintain the connection to the source as closely as possible. As a general rule and not always by intention, I often find myself at the end of a project with at the very least 3 source PSD files, some are a little messy, one may be mostly flattened with only some last minute changes lay on top, but the main thing is they all work together to make the bigger picture.

If the client wants the source files they are more than welcome to have them (after all they are not mine to deny), but commonly they won’t be the ones to edit the files later. Rather I would expect someone who has some experience to be handling the files, therefore I would hope said person would have the required insight to be able to unravel the inner workings of the monster I have created.

Cheers Nathan.

Kent says:
September 09, 04h

No mention of ImageReady? Do you just use Photoshop?

As someone who’s just come into a new job, and has to make updates and adjustments to other designers files, it’s incredibly frustrating when the the source .psd doesn’t match up with what’s live.

My personal workflow - which is nothing revolutionary - is to do everything up to slicing in Photoshop, then jump to ImageReady for the slicing and optimising stage. If edits come in later on, you only need to select the appropriate slices and re-export. No flattening, no cropping, no re-optimising…

September 09, 05h

Dave: you’re abolutely right, about my zagging when you zigged. I do know what gamma is, since I regularly make a habit of calibrating my monitors. The fault is mine for not reading what you said carefully enough. Usually when I see discussions about PNG support and IE, it’s with regards to transparency, not gamma. And that kind of explains the source of the error.

I will also admit to ignorance about the benefits of embedding gamma information into an image, and I will explain why I don’t get it. See, I can understand calibrating a monitor so that if you hit certain points and set a color temperature, then you have a predictable baseline from which to compare images. The thinking here is that as long as people who care about image fidelity do roughly the same thing, they’ll see roughly the same thing. And everybody’s happy. But the assumption that I’m making here is that a color is a color - 255/0/0 should look as red to you as it does to me (colorblindness and other environmental factors notwithstanding).

So, and this is pure reasoning on my part, would I be correct to understand that by adding data describing the gamma to an image, the renderer can take that image and dynamically adjust the colors based on the known state of an end user’s monitor calibration? If I’m correct, and if someone doesn’t calibrate their monitors at all, what good would that information be? The native gamma of an uncalibrated monitor is a human-determined value, so if a human didn’t determine it for their system, then your intentions were pretty much hosed for that case.

Getting back to my transparency issue, my experiments quite conclusively show that on Mac IE 5.2.3, my pngs have the correct color but no alpha channel, and the same image renders with alpha channel correctly in Safari. For what I use pngs, it doesn’t bother me that much. it’s a nice to have.

Again, apologies for straying so far from the topic, but this is, I hope, interesting reading, and I’m getting quite a bit of value out of it.

September 09, 08h

PNGOut will correct the screwed up gamma chunks (sometimes) PhotoShop CS seems to still have the gamma issue.

However WEb Image Guru - a PS plugin - works really well and saves out the right gamma chunk.

Using WIG and PNGOut I gain about 20% smaller PNG’s than PS and about 50-60% smaller than the same GIF.

If you know how to solve the software problems then PNG is by far the superior format to GIF. I don’t use anything else for 8bit work.

In fact I only use gif when I need animation, which is rare.

Susanna says:
September 09, 11h

I find that I rarely want to make just one change to a GIF of the type Dave described (a small design element). Those small pieces usually end up becoming their own source files, documenting the changes I made in layers so I can go back and tweak it if the changed graphic doesn’t look right.

Of course, this might also be because Fireworks wants to save everything in its native PNG format, encouraging me to save a copy instead of just exporting a new GIF. (The type of web graphics I use Photoshop for nearly always end up as JPEGs.)

datawise says:
September 10, 02h

As some of the other comments indicate Fireworks is becoming more popular. Personally I use Photoshop for photos and Fireworks for graphics. When using Fireworks/Dreamweaver in tandem the conversion problems are minimized. I open the orginal in Fireworks, which remembers where it was las exported to. Ctrl-Shift-R exports, and Dreamweaver immediately displays the new image. If the image is created from Dreamweaver, Dreamweaver will remember both the source file and the exported file allowing seamless editing of the png and export of the gif file.

September 10, 08h

Further to Gregory’s recommendation of PNGOut, take a look at PNGGauntlet - - a simpe GUI for PNGOut. I use it to crunch and correct whole folders full of PNG files when ready to publish. Typically, I get a 10-30% saving on each PNG file that’s been saved via Photoshop’s “save for web” feature.

david says:
September 10, 08h

#5 Dave -

Yeah, IE6 has trouble with PNG gamma, but it’s optional to include that data, isn’t it?

I use GIMP and just uncheck “save gamma” when exporting PNGs.

September 11, 03h

For all intents and purposes 8-bit PNG images are complete (non-animated) GIF killers once you remove all Gamma and special color handling info…except for one glaring exception: Safari. Safari seems to “guess” at the gamma value rather than just matching it with GIFs & JPEGs. See