May 04, 2009

Some thoughts about the PSD format

Here’s what I think people want to know: Is Photoshop’s PSD format a goofy, antiquated piece of crap, and by extension is Photoshop slow, clumsy, and/or outdated?

No. (Read on for details.)


The questions arise because various Web sites1 have been linking to an anonymous developer’s rant about PSD. The guy’s complaints boil down to the following:

  • There are multiple ways to do various things in the format
  • Getting the format documentation (which he did not attempt to do) requires sending Adobe a fax

These perceived atrocities earn a final, and always classy, “F you Adobe.” Nice.

Now, let’s be clear: Photoshop engineers would be the first to agree that the PSD format reflects a lot of organic growth2, and thus it’s nowhere near as cleanly structured as a format one would write from scratch to encompass everything PSD can do. Of its quirks, PSD expert Tim Wright says, “Most are the gradual result of discovering better ways to do things over 20 years, while staying compatible with older applications.” Making it easy to reverse-engineer without documentation was certainly not a design goal.

In any case, so what? Does this matter to you?

If you’re a developer, PSD’s complexity makes writing a file format reader/writer more difficult. Of course, PSD was never designed as or intended to be an interchange format. Be that as it may, customers clearly want easy interoperability with Photoshop, and we’d like to make data exchange easier. More on that in a sec.

If you’re a Photoshop user, would a brand new PSD alternative offer tangible benefits–faster read/write performance, smaller files? That’s unlikely. Being easier to code has nothing to do with offering better performance.

There are improvements we’d like to make to PSD (for example, I want to provide the option to omit composite data for Smart Objects, making files smaller at the expense of backward compatibility), but these improvements don’t require a new format. Similarly, there are ways to improve Photoshop’s file handling (e.g. enabling opening/saving in the background) that don’t depend on changing the format.

Of course, even should such a new format be developed, we could never get rid of PSD as we know it today. (We can hardly even ditch PICT!) The Photoshop team prizes compatibility, as do our customers. (What other app lets you open & work with a file without having that file’s fonts installed?) As Kevin Connor notes, “You don’t have to upgrade in order to continue collaborating with someone working in a newer version, and they don’t even have to jump through lots of hoops such as saving to old file format versions.”

Any new format would exist in parallel with PSD, and it wouldn’t be compatible with any other reader. Let’s say that to force migration, Photoshop CS-X made PSD read-only. Would you upgrade if doing so meant no longer being able to create files that could be read in (take your pick: Final Cut Pro, Maya, QuarkXPress, iView, RenderMan, etc.)? I’m not saying it’s impossible, just that it would take many years in which Adobe would need to support writing both formats (and then reading PSD forever). And it’s not at all clear that the benefits here would outweigh the costs.

Let’s go back to the question of how to improve data exchange with other apps. No matter how clean Adobe could make the Photoshop format, you’d need different native formats for Illustrator, InDesign, Flash, etc.3 Therefore any tool wishing to read/write data from multiple Adobe apps would have to build and maintain file format modules. Wouldn’t it be better if all apps could read/write just one common interchange format?

That’s just what Adobe is developing with FXG. The format builds upon SVG, and as such it’s an XML-based way to represent vector & bitmap graphics. It’s not trying to represent every nuance of every authoring tool. Instead, it focuses on data that most design/animation/interactivity apps should be able to handle.

Here’s the upshot of FXG for third parties: instead of dealing with PSD (and AI, and Fireworks PNG, and…) at all, you could focus on reading & writing one new, common format that’s clearly & publicly documented–and that was designed for data exchange. The upshot for customers should be a richer ecosystem of tools that can work with Adobe apps & documents. That translates to more & better ways to use what you create.

So, in summary: The PSD format isn’t perfect, but it has grown smoothly while offering backward compatibility. We’ll work on ways to improve both the format specifically & document handling in general in Photoshop. And we’re putting real effort into a new format that’ll address what matters in the real world: a simpler path to smoother workflows.

J.

—————

1

I see no need to link back to these sites (and thus give them ad revenue) when none of them, as far as I’ve seen, have added any value by doing more than regurgitating the rant. No one, to my knowledge, contacted Adobe for comments. Doing so would’ve made for better, more interesting articles. (For future reference, guys: jnack at adobe).

2

How much growth? When Photoshop (and hence the PSD format) started life, Photoshop supported only flat images of up to 8 bits. There were

  • no layers
  • no paths
  • no live adjustments
  • no live effects or filters
  • no editable type
  • no color profiles
  • no duotones, etc.

and forget about things like Smart Objects (which can be nested & embed entire Illustrator documents, raw files, and other PSDs), linked video layers, and 3D layers. All these things arrived over time, along with higher bit depths (up to 32bpc), jumps in resolution (first to 30,000 x 30,000 pixels, then to 300,000 x 300,000), breaking the 2-gigabyte file size limit, and more.

3

Though I understand the appeal, proposing that all apps use a common “.adobe” format isn’t realistic. Each app has its own complex object model, blending modes, and so forth. Do you really want Fireworks trying to understand all the internal data structures needed by After Effects & InDesign, or Photoshop trying to understand everything that’s inside an FLA or AEP or INDD file? No, as that approach would add tremendous overhead. Sure, we could have each app just understand its own slice of a .adobe container, but at that point we may as well put everything inside a ZIP file and then claim that everyone uses the same file format. (FXG is different in that it’s not trying to be or replace any native file format.)

• Last footnote: Joel Spolsky discusses how Microsoft Office file formats “appear to be almost completely insane”–the products of incompetence, malice, or both–but aren’t, and for good reasons. [Via]

Posted by John Nack at 10:00 AM on May 04, 2009
Copyright © 2014 Adobe Systems Incorporated. All rights reserved.
Terms of Use | Privacy Policy and Cookies (Updated)