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.
—————
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).
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.
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]
Wow, I suppose if I thought long and hard I could think of something I didn’t like abut PSDs. But since nothing comes to mind I guess you’ve done a good job with the format. I guess people always find something to complain about. I think somebody needs to give them more work to keep them busy. Now I gotta get back. I’ve got a lot of work to do. 🙂
John,
This rants about file formats will never stop. From my users point of view .psd is quite firm compared to other formats and their backward issues and it always has been. I´m talking about 20 years of experience.
I always enjoy reading your blog John. It’s fascinating to get a “behind the scenes” peek at what goes on. I see a lot of Adobe bashing from different crowds and it’s very helpful to be able to point to your blog and say “Here, see? They think about this stuff all the time. This is why they did it that way.”
Whenever I see complaints about .PSD I point to .doc and .docx.
In nice to see that the engineers/developers at Adobe listen, and have good reasons for the things they do–even if users don’t always like it. As a user I too can get pretty worked up about how Adobe products function because they are at the very core of what I do. Without Adobe Photoshop, Illustrator and the rest I can’t do my job. You guys keep me in business.
I’d been saving files processed in Photoshop as psd’s until I started using Lightroom 2.0. When I edit a Lightroom dng file in Photoshop, then save it, it defaults to saving the file as a tiff. Okay by me. I’ve read that psd’s are smaller in size than tiff’s, but I haven’t noticed any significant difference in size. Am I missing something by not saving files as psd’s?
[Nope, as Photoshop can stick all its layer data into the TIFF. TIFF may actually give you smaller files as it offers more compression options. –J.]
Yeah, this is a big non-issue. Function is more important than form, and PSDs function very well, for all the reasons noted above.
So, to elaborate on that, why does Illustrator and After Effects feel the need to constantly version their formats and break backwards compatibility. (After Effects is a big offender on this–heck, amazingly AE even used to TAUNT the user if they tried to open a newer .aep in a older version of AE)
If Photoshop can do it, it should be easy, right? 😉
I’m extremely pleased with the backward compatibility of Photoshop over the years. I wish Flash was as receptive to older or newer files. It doesn’t even ‘maintain’ compatibility one program version back or forward.
[It does now, actually: you can choose to save as CS3 from CS4. It certainly was dangerous back in the day: open an FLA with a newer version, select a layer, hit Save, and you could then no longer open that FLA in any older version. Deeply lame, to say the least. Now, fortunately, the Flash team is also working on the XML-based XFL replacement for FLA. (It works hand in glove with FXG.) –J.]
Flash is dangerous that way. I’d invite people to name many programs that have done as well on even simpler files. I know others have, but I’ve never had a PSD problem before in many years of work. The files are big but very solid in my experience.
Great post John.
I really would like to see thumbnails of PSDs in the Windows Explorer come back. You know, like before there was Bridge and somebody decided to eliminate this feature…
[The old Explorer shell plug-in was buggy & hard to maintain, and that’s why we dropped it. I’d love to see us restore something similar but much better, tying into the codec system on Vista/Win7 (as we’ve done with the DNG Codec). That’s a whole other can of worms, of course. –J.]
I’ve never understood why any other application besides Photoshop should be able to read or write to a psd file. If you need layers, there’s always TIFF, right? I think another problem is Designers are not always the most computer savvy so they end up sending end users the actual Photoshop file they were working on instead of exporting a flat image.
I’m not sure a universal format is the answer either. The most efficient way to store data definitely varies from one application to another. As an interchange format, FXG seems interesting but will that solve the root of the problem? Will users export to this magical format?
A better solution imo would be total integration with the OS itself. Much like codecs for movies, maybe Adobe could provide a special shared library application for each OS that developers could tap into for their own applications instead of trying to reinvent the wheel themselves? Limit the featureset to read only, maybe flattening each layer, etc.
I think both PSD and Photoshop has a lot of legacy drag attached to it. As an example the adjustments commands on the Adjustments menu when you now have the adjustments palette. The menu is redundent and worse allows you to apply these and in a destructive way.
I know that some of the Adjustment menu options are not available from the adjustments palette, but the ones that are should be removed.
Adobe has worked hard to make things as non-destructive as possible. It is time to start removing the old ways.
I know this is going to cause a major caniption with people. But, I think it is time for Adobe to start trimming the fact and pushing people to the new modern, better and non-destructive workflow if that requires kicking and screaming.
Based on this I have no doubt that PSD is just as legacy challenged and maybe it is time to clean it up. I like the PSD format, but I would like to see it as effective as possible and a format that becomes much more widely supported and not just supported when you have something like maximize compatibility turned on. I think cleaning up, streamlining it and documenting is as best as is humanly possible will help with that. A Vista codec would also be a nice touch.
I would also like to point out that what I am talking about has already been done but Adobe instead of fixing up and cleaning up Photoshop decided to do it as a new program with a new way of doing things. That is called Lightroom.
Now it is time to bring Photoshop in to the 21st century. Even if Adobe did this behind the scenes while still doing the CS updates in the meantime. A cleaning up, streamlining and modernizing and a near total code update should be something Adobe is working in in house for a release in 5 to 10 years time.
Adobe has been adding some very interesting technology to Photoshop but at the expense of the basics. Time to work on the basics.
Robert
Hi John,
Thanks for following up on this.
To start with, it never hurts to remind ourselves that tech customers are constantly in need of reassurance, due to the changing nature of tech/software and all of it’s variables. Communication is still a significant blind spot for all tech companies. I think the point is – why are developers etc out there blogging about the .PSD format.
I put it down to communication inadequacies. Your blog is great at dealing with a whole variety of questions, concerns and interests from users, but is sometimes putting out fires such as today.
If you relate Adobe to a political party (both indebted to their supporters), especially the dems of the moment – communicating your intentions is just as important as the actions. The dems have a multi tiered strategy, vital to maintaining there authority. Most importantly it is proactive, the most reassuring aspect. Adobe has all kinds of room to expand on quality communication to it’s customers firstly on your site, but why not have a presence on other Ps user sites as well?
Some of the info in this blog could be condensed and have an easy access link via the Ps product pages. There is never enough detail on tech product info descriptions – of course it is the job of the marketeer to find ingenious ways to avoid intimidating some clientele while making further detail easily accessible to those who absolutely depend on it to make good business decisions. As an example, if I were buying a graphics card, (usually a 1 page description) 6 pages would probably be about right for me.
There are some awesome tech docs on Adobe products (on your site of course), but not conveniently accessible (read instant access). I don’t think tech companies realise how busy we all are – and how much seconds count. If it’s inconvenient, it is often deferred and never returned to. I often relate computer use to a phone book – if I can’t find it as fast as I can in a phone book – why am I using it?
For practical examples – I would like to see pages of details on computer specs with a direct link to the Ps product pages, not buried in a tech doc. For that matter, I would like to see a few pages of links connected to the Ps product pages.
This topic relates directly with the new business concept I shared with you 2 months ago, which will be very proactive on communication. I haven’t heard anything back from the relevant parties at Abode – any info on that?
Thanks,
Poignant as usual, John. I would settle for each OS being able to show previews of PSD(or anything Adobe besides pdf for that matter) files in their respective file explorer. Is that something that the team hears all the time?
OK, I read the article and tried hard to come up with a .psd complaint and I finally got one so take care of this and I’m good forever: Make Acrobat work with PSD files. And a previous commenter hit the nail on the head. This guy needs to get a life.
There is a precedent for Adobe dropping old file formats. But why did Abode drop the AI7 format from Illustrator CS? It’s not like it was a hard format to write out, and several other programs could load it in.
psd works for me. forget who i saw ranting about psd the other day. ah if its not psd it would be something else like the ui.
@Rob- Lightroom has an option to save as .PSD or .tif from Photoshop. Check under the Preferences menu.
@Robert- Photoshop does many (many) things besides edit photos. Lightroom is specifically designed just for editing & managing photos. As you pointed out, since it is new, it was built to be non-destructive.
PS has 20 years of history and a lot of legacy behind it that it drags along into each new version. Look at all the screaming and nashing of teeth over “Picture Package” and the “Extract Filter” 🙂
As someone who has used Photoshop since 1.0 (and before!), I appreciate the history and defense.
However, one point you didn’t address. In this day and age, why should someone have to fax Adobe to get PSD documentation? Isn’t that something that you and others could change, and simply publish (even behind an “I agree to these terms” button)?
I read that guy’s PSD rant and found it funny, but I (and I think most people) took it with a grain of salt. PSD has become one of those ubiquitous formats that is known for being predictable and reliable, and this would still be true even if it is a mess underneath. Frankly, all programming and markup looks like a mess to me. If it works and doesn’t cause me woe, I like it.
I like the “an anonymous developer”, when the project page links to his website with his name on it.
[Sorry if tracking down Mr. F You’s name was hardly a top priority for me. –J.]
As an alternative to improve file read/write performance, saving to an uncompressed TIFF does seem to be faster than PSD while resulting in a much larger file. My work generally ends up with PSDs in the 500MB range, the uncompressed TIFF versions end up between 700MB and 1.2GB
That said, it seems to save faster, I think because the single CPU core (file operations are not multi-threaded from what I’ve read) doesn’t have to chew through and compress the data in all the layers.
Personally I’m sticking with PSD. Disk space is cheap, but somehow, moving images that are twice the size to save a few seconds while saving is not worth the change in workflow.
or, maybe I’m just stuck in my curmudgeonly ways…
Good work as always John.
Actually, the answer to both of your questions is “Yes, yes, yes”
You didn’t address the most important issue, which is that Adobe expects people in the 21st century to have access to a fax machine. (Outside of a museum, that is.)
[Um… eFax, which is what I use? –J.]
This fax insanity must stop. Or else I’ll have to demand the response to the fax be sent by carrier pigeons.
[We *should* get around to doing this with PDF forms; we just haven’t yet. –J.]
Thank you for the post, illuminating. I do agree with you on Adobe’s and your view on this but you didn’t really tackle the question of getting the PSD documentation. You did mention that the dev didn’t contact you, but could you elaborate on his argument please?
Also, it does sound like that the dev is kinda right, however. Your reply is basically agreeing with him on the issue of the complexity of the format.
[Yes, it’s certainly a complex format. I’m not at all surprised that someone trying to decipher it all without documentation would get frustrated. –J.]
Don’t get me wrong, Adobe has their reasons why, and I completely understand the need for compatibility, etc.
Cheers for the post.
Great piece, John. Good to see Adobe respond (informally, I suppose) with such detail. And it’s good to hear a little bit about Adobe’s plans for the future of what is, let’s face it, probably the most famous and iconic software ‘platform’ (if you will) outside of Windows.
One thing I’m so tired of is software developers who can’t see the forest for the trees.
PSD matters to _artists_. I hope working with it gives software developers terrible nightmares of infinite loops. I hope software developers have to twist themselves into a pretzel in order to code around PSD. GREAT! If that is what it takes to keep the priority on the art these past 20 years and not the software code, then that is great. If that’s what it takes to keep it so that documents just open and work in Photoshop while we are working all day there, then that is great.
This reminds me of the hubbub around audio formats. People who produce audio and video content ISO standardized on the MPEG-4 format in 2001, and now that format is supported in every single audio player as well as iTunes and Blu-Ray and even many candy bar phones have the 3GPP part of MPEG-4. However, some software developers think they know better, because digital audio is also made of bits. They know nothing about audio, but since it is now made of bits, they have an opinion. They tell us to use Ogg (which is about as good an audio format as AES-128 and just as inscrutable to over 99.9% of music listeners) and to use LAME (even though it sounds awful compared to a Dolby encoder, literally might as well sell off half my studio gear if I’m going to abuse the final mix like that) and at no point will they tell you to A B listen to the results and examine the sound quality. That is not even on their radar, the idea that the results of perceptual encoding (which will always be different for each different encoder product) should be part of the reason to choose an encoder, when in fact, it’s the most important way to compare encoders. MPEG-4 is not just one format, it’s the standardization of the QuickTime format, which all audio video people depend upon like the Web needs Unix. The idea that Ogg would be a substitute is like saying you don’t need an iPhone, 2 tin cans with string will do just fine.
Another example of this kind of thinking is the fact that in all the world, only Apple and Adobe have ever offered anything close to online typography. Font makers work for days to hint a typeface so that it renders with precision spacing under many circumstances and yet you have to be using an Apple or Adobe product to see the results of that work on your screen. This is an attitude left over from the 1980’s when what you saw on your screen was just a scratch pad for what you were eventually going to print and share … like 20 years ago.
Generally speaking, there are a lot of software coders out there who need a massive dose of humility. They need to remember that there is something called “subject matter expertise” and the fact that you know the C language does not mean you know something about art or music software. Every human endeavor has software attached to it now. The reasons some of that software may seem to be “bad” from a software perspective may be a huge benefit from the practical perspective of an expert artist who uses and funds the development of the software application.
Although I’m mostly with John, I need to mention that the increasing complexity of the PSD file format and all the non-destructive features stored in these files makes it much more complicated to create working cross-product integration.
[For what it’s worth, we try to err on the side of *not* making it harder to integrate. That’s why PSD stores composite data for Smart Objects/Smart Filters, 3D layers, etc. Without that data, the reader app would have to parse the source data & re-create the composite on the fly. (Same goes for type in PSDs, for that matter: Photoshop stores the pixels so that other apps don’t have to replicate the Photoshop type engine, and so that you can still work with a file even if you don’t have the needed font.)
Some of these decisions come at the expense of making files larger, and that’s why I mentioned wanting to provide more options (giving you better control over file size vs. compatibility). –J.]
Adobe Director still waits for a working (native) PSD importer. The fact that it’s still missing lets me assume that it’s not easy to do, at least not for a small team of engineers, that have a lot more to do.
[I can’t speak for the Director team. The Photoshop team maintains a PSD-reading/writing library that’s integrated into at least a dozen other Adobe apps. I don’t think it’s hosting the library that’s difficult so much as figuring out what to do case by case (where Director or the other reader doesn’t have a certain data type, blending model equivalent, etc.). We worked through a *lot* of those cases when Flash added PSD reading. –J.]
I personally don’t feel that there are many issues with the PSD format and I do like the fact that I can still open a PSD I created on CS3 in the office on my PS7 at home and vice versa.
I am however more concerned with the direction Photoshop is taking. You may agree or not agree with me but I feel that CS4 is not as polished as it could be and the focus has shifted to adding more ‘features’ that are only used less than 5% of the time.
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.
Good Ol’ Times !
.psd is fine — I never even thought of it until just now.
but the people here that are saying “I never have a problem with the .PSD file format” never had to do anything with it other than “File | Open…” and “File | Save…” – the deserved rant is because the internal mechanics of the file format are sub-standard.
but show me an Adobe product that isn’t.
what is, let’s face it, probably the most famous and iconic software ‘platform’ (if you will) outside of Windows.
Well, apart from a certain fruit-themed company’s most famous piece of software, one might possibly imagine.
The primary complaint I got from Dag Ågren’s rant was that it was needlessly complex to write a parser for .psd, which is exactly what he was doing (the comment is in a .psd parser after all…) He isn’t looking at .psd from a user’s perspective. You yourself admit that .psd was not intended to be read by other applications and it’s “nowhere near as cleanly structured as a format one would write from scratch”, which is essentially a nicer way of saying the same thing he was.
[I said that the format could be cleaner, and it could. That strikes me as different than fantasizing publicly about the painful deaths of its creators/maintainers. –J.]
From a Photoshop user’s perspective you’re right – no matter how bad .psd is, it’s the only thing that works. But working doesn’t imply that it’s a good format technically.
I haven’t looked at what’s required of you to get at the .psd specs, but if it’s anything like what was required to get the .flv 9 specs, I’m not at all surprised he didn’t go through with it.
[I have no idea about FLV, but for PSD it works like this: Go to the PS SDK download page, provide your contact info through the (extremely simple) online form, and we’ll get in touch to get the paperwork through. It’s really a very easy process, and in 7 years on this team I can’t think of anyone who’s been turned down (including Microsoft, Quark, etc.). –J.]
Yeah, John, photoshop isn’t slow or clumsy. You’re right. The flash widgets are great, the installer is seamless and pleasant.
Waterboarding is not torture, the fundamentals of our economy are sound, and jesus is coming back any day now.
Maybe what he said wasn’t the whole truth, but it only got any play because it resonated with the rest of the picture. You understand that.
[What I understand, actually, is that it’s easy to drive online ad impressions by repeating something salacious about something or someone well known–no independent thought, research, or analysis required. –J.]
I’ve always thought that PSD was the best file format I have ever used in over 25 years in the graphics world .
I’d like to add another vote for doing away with requiring a fax for any purpose—that’s at least as dated as the PICT format. I underwent a similarly annoying inconvenience some time back, as I do not have easy access to such a technological dinosaur. Come to think of it, the company in question was Adobe. As I stated on my personal Web site afterward:
Many companies require that certain forms be sent by facsimile transmission and will not accept those same forms as e-mail attachments. The obvious question immediately springs to mind: What is the difference between a document sent electronically via telephone and printed out by a fax machine and a document sent electronically via e-mail and printed out by a laser or ink-jet printer? To provide a semi-serious answer: facsimile copies are generally of coarser resolution and are black and white rather than grayscale or color—in other words, inferior in quality.
I agree with Terry; best file format I’ve used. And as a web-print-photo-illustration-video developer and designer, I’ve used a whole bunch. Great post.
Well said. Back compatibility and supporting legacy standards over 10 to 20 years is messy. Supporting customers with good interchange formats is great business, but no one said it would be easy.
Send a fax? Oh my gosh, you folks at Adobe are evil. What’s wrong with shooting of an email? ;-D
Next thing you know, we’ll have to do something draconian like type “photoshop” to post here. Like we have to take the time to spell correct?
While I applaud Adobe’s effort in keeping PSD backwards compatible, I disagree with John’s statement that PSD file format documentation only requires a fax to Adobe. The fact is, the documentation is very incomplete and many important things, like adjustment layers’ parameters, are not there. I once paid Adobe money to be on the developer’s program and had access to the ‘advanced sdk’ but the truth is not as rosy as this article portrays and email responses from Adobe’s developers are not forthcoming with data.
Well done. Instead of using the feedback from a real, flesh-and-blood developer who is making your product more useful by expanding its market, and reporting back on how he found it, you decided to knife him. Why bother treating him positively (“Yes, I suppose it is a bit grim, but there’s a great reason for that…”) or listening to his input on your process? It’s far better to condescend and condemn – after all, you are superior. Great work Adobe, you still have that knack.
[Dude, please, give me a break… This guy had nothing constructive to say, and I have better things to do than to feed your condescending trolling. –J.]
I only wish this was true about indd, which isn’t even compatible between versions, and for which there’s only an interchange format to go one version back – there’s no way to edit a CS4 indd file in CS2 without going through CS3 first, and there’s a huge sigh of relief every time I don’t have to deal with that problem with psd. Now, if only we could get Lightroom to read the ones that have maximize compatibility turned off…
Your gripe is with the echo chamber, not the original author. By only linking to the original, you’ve come across as someone who can’t laugh a bit at their own expense.
The context is the whole joke. Those comments wouldn’t have gotten traction in a blog post – they were funny because they weren’t intended to be read, but were rather a glimpse into the mind of the hacker up at 3AM trying to slog through PSD. They were funny because we’ve all written comments like that about some problem or another. It would have been just as funny with any other format.
Now, as to the blogs who reposted the rant as some kind of gospel, we all agree they’re silly. They too seem to be missing a great joke – the irony of a developer who pollutes his source code with a rant about the sloppiness of someone else’s code.
Finally, as someone who interacts with OPP (other people’s PSDs) on a daily basis, I can’t thank you all enough for the premium the Adobe team has put into backwards compatibility. There’s a reason PSD is the defacto standard.
PS: could you please provide more info on obtaining the PSD documentation? I’m happy to send whatever credentials are required via fax.
I use PSD files all the time.
Love them, don’t care about the size.
I can go and open a PSD from 10 years ago and not worry about fonts, which version of photoshop I used back then or anything else.
It just works the way it should
Geez the PSD format is fine.
I just wish Apple would get its act together and find a way for PSD files to preview correctly in the Finder. As it is right now if the PSD file has an alpha channel the PSD preview is masked with that channel.
“Getting the format documentation (which he did not attempt to do) requires sending Adobe a fax”
I can see the issue here clear as day. Personally I haven’t seen a fax machine, nor used one, for the last nine years (might be because I’m not in the us). It is not common thing to find in a household and most information is sent via email. The fact that Adobe forces you to hunt down fax machine to get documentation on the PSD format is rather odd.
The only reason I can think of you doing this, is to prevent people from working on the psd format. Put up a barrier that can be climbed over with some effort and most people won’t bother to even try. It stiffles innovation in my eyes, but as a business I guess holding the format to yourself is a good thing to do.
I guess this way you can say in a legal suit that you are making it available to anyone who wants it. But they will have to prove that they really really really want it to get it.
While I can empathize with you feeling ragged on, the cause of the rants that go on are not entirely unfounded. There are many instances and interactions with Adobe applications that leave one dumfounded. I’ve been to many conferences and User Group meetings put on or sponsored by Adobe and led by corporate yes-men, who you just want to shake to get real. You can defend this and that, and I’m sure there is a lot of honest effort, but Adobe does really need to get it in gear, devote resources, listen and take care of the sloppy, shoddy experiences we really truly have.
[I can’t support or defend everything this large company does, just as I couldn’t for any large organization. You don’t provide any specifics about whatever’s bugging you, so there’s nothing in particular I can do to help. –J.]
I saw the rant go by (via @daringfireball) and kinda yawned. I’ve been involved with a couple of PSD file format parsers and have not found the file format to be difficult and the developer support excellent (Chris Cox was esp. generous with his time explaining the Photoshop blending algorithms.) I also think the backwards compatibility of PSD is both commendable and remarkable.
I’m not buying it. I’m sick and tired of everything Adobe. The money, the resources you guys have at your disposal and the quality of your output compared to one man and two man teams. You should all be ashamed of yourselves. I have to work with Adobe, but the second the opportunity arrives I’ll be jumping ship.
Your company and it’s lazy cavalier attitude costs me real money.
John, I have seen many claims online that the PSD documentation was not complete, or up to date, and that total compatibility was not possible. Of course, I am not a developper, so couldn’t judge those claims.
This makes some people be afraid of the great format that is DNG, despite the fact that it is being scrutinized by the ISO.
Speaking of DNG, there are reoccuring complaints about the lack of a 64bits Codec.
As for PSD previews in Windows Explorer, I have great hopes since a Microsoft Engineer, Brandon Paddock jumped in a discussion in the User-to-User forum: http://forums.adobe.com/message/1641865#1641865
The biggest problem with the PSD format is that there no granular way to control compression. And since Photoshops multicore utilization for save operations is non existing, save times for large images are a big issue – even on a striped raid. For that reason alone i’ve dumped the PSD format in favor of TIFF whenever possible and actively endorsing the use of TIFF instead of PSD for large images.
What bugs me is why would anyone want to reverse engineer PSD file? It is Adobe’s format, used by Adobe’s apps. As long as the file works (i.e. does not get corrupted after it has 1000+ layers, or 2GB+ filesize, or whatever) i seriously could not care less HOW exactly is PSD constructed.
Oh, you want to make your own image editing software that can load/save PSD? Right, then contact Adobe and let them help you.
John, “anonymous developer”? Really? It takes all of 3 clicks to get paracelsus’ “real” name, and your post reeks of damage control (let me remind you that crap is also organically grown).
Furthermore, if Adobe really wants FXG to be a used interchange format (which I doubt), I suggest it’s dropped, because it won’t work.
[“It won’t work.” That’s it. That’s all you say–and based on what, exactly? There are plenty of nuances to discuss, plenty of interesting hurdles to overcome, but you haven’t mentioned (or thought through?) any. You simply say, “Nyah-nyah, gonna fail.”
I think of something Merlin Mann said: “Some days, the web feels like 5 people trying to make something; 5k people turning it into a list; and 500MM people saying, ‘FAIL.'” –J.]
Finally, the rant was in the context of writing input filter for an OSX *image viewer*. I’m sure you’re aware that the role of an image viewer is to show images. The images the use has on his drive. If the user has PSDs and wants to see them, FXG isn’t really going to help (irrespective of it failing to be adopted) is it?
[You’re right about this specific case, though I’d also point that one need not try to understand the internals of PSD data structures & replicate the Photoshop compositing model. Rather, you can just read the composite data that’s stored in most PSDs. That’s what Apple & many other companies do. –J.]
To many people’s dismay, and much as .doc files are, psds files *are* a de-facto interop format. That’s just the way it is. If you want to make interop easier, just make it easy for people to request the (digital) format documentation, or make it trivial to download on adobe’s website.
[Have you tried it? It’s pretty damn trivial now. –J.]
I agree. The rant was very unprofessional. Unfortunately these sort of code comments (though not usually to this level of verbosity) are fairly common for open source software. And the developer should have faxed Adobe for the file format instead of whining about his own failure to reverse engineer it swiftly.
I wonder why Adobe cannot put the file format specification on the web? I see no reason why you have to beg for a SDK.
[Providing your email address constitutes begging? We’d just like to have *some* rough estimate of how many people are using the docs, as well as a way to contact them (with questions, info, etc.) if needed. –J.]
It should be in the company’s interest that anyone can easily add support for interaction with Adobe products
Dave was spot on.
Can’t you people stop commenting and saying that “the PSD format is just great! I haven’t had any problems with it” etc etc.
The post and rant are not about PSD files. They’re about the PSD format’s internal structure! It’s a totally different thing. It’s about how a PSD file looks internally, not how easy it is to send it to a colleague.
You guys are just off topic, in regards to this.
[Actually, the two things are quite closely related. If Adobe frequently rewrote PSD, then it would be much harder to pass files around with confidence (as other versions of PS/other apps would often be unable to read the files).
It’s because we honestly do work hard on things like backward (and forward) compatibility that I get annoyed when people talk about being “forced” to upgrade. Listen, if we wanted to try twisting anyone’s arms, we could be a lot more aggressive (and effective) in doing so! –J.]
Well, I am the “anonymous developer” who wrote that rant, and although it’s already been pointed out, you SHOULD note the context of that – it’s a source code comment, it’s meant only to be an internal joke for the few people who would actually read the code, and was written just to work off some frustration. I certainly didn’t post it on a blog, or submit it to any social news sites. It is NOT meant to be taken seriously in any way.
And rest assured, trying to write a PSD reader WILL cause anybody MASSIVE frustration. I DID have access to documentation – I managed to track down an old copy of the PS 6 SDK docs online, and I only had to reverse-engineer some small newer parts, but it was still a nighmare getting it working.
But what really added insult to injury was exactly how HARD it is to get the documentation. I am a hobbyist developer in the 21st century – I don’t have access to a fax machine, and I am used to getting my information directly from the net. The fact that you require me to jump through all these hoops, that would no doubt take weeks to complete, using infrastructure I don’t even have access to, only sends the message that you don’t WANT me to read your files. It says “this is only for big companies, you small fry can just take a hike”. In your example about how supposedly easy this is to do, you only mention big companies, too.
Can you see that this would feel pretty insulting? There’s no reason that is obvious TO ME why you couldn’t just put the PDF file on your website for me to download. Perhaps you have obscure corporate legal reason you can’t do this, but to a hobbyist developer like me, it just looks like a big snub.
Now, I don’t have a problem with USING PSD files, I do it all the time – which is why I wanted a reader for them in the first place – this was entirely about the technical details of the format. And I don’t see where you got that people took this to imply that Photoshop itself sucks because of it. I didn’t see any such sentiment expressed on any of the blogs and news sites that re-linked it.
Finally, if I was writing that for the big public, I would obviously phrase it more politely. Like I said, it was never meant to be widely read. But I stand by the sentiment expressed, and I think that if there’s one single thing you should take home from that rant, it’s that your situation with the documentation is neither helpful nor friendly.
Here’s another user praising .psd. So far – so far, it’s always worked. Can’t say that about the stuff Quark produces, or any of the versions of PageMaker I’ve used.
Could you expand on the usefulness of saving psd vs tif in a future column? My technical understanding of what is being saved, and in what way it is backwards compatible is dim, to say the least.
[I’ll try to gather some info to share. –J.]
Also, is there no quick and dirty hack for doing previews? Something that represents psds as something “else” to the OS just far enough to generate a nice little icon? Like the first x bits look just like a tiny little jpg or something?
[I’ll have to ask Chris Cox what’s stored in PSDs. You can choose to save a full, flat document composite, but I’m not sure whether that’s necessary in order to get just a small preview as well. –J.]
Been away for a weekend to see that the problem with the world is that the internet is NOT policed. The posts above show that in the right circumstances those of us who support your work will care enough to respond in a constructive way, not always agreeing but adding to the debate, while there are a very small minority, who now have some channel to be heard who get given a disproportionate attention. 99 percent of users are happy. 0.9 percent of us reply to your posts, because we are happy but inquisitve and passsionate for positive change and the other 10 people in the world who are not either of the above believe that having a soap box and having something worht saying are the same thing.
To answer your questions.
Putting a pin in the ground and having a PSDx format that can be universally be read at (say) this point in time by removing Adobe specific stuff like layer style (by flattening for example) seems like a really good suggestion. Allows you to always have a backwards compatible point in time without having to pander to purists for the next 10 years.
As someone who works in sscreen, print, video with Ps Id Il Fl Ae and Pr, I would welcome a containder format that can hold any or all of the parts on information that I am likely to want to transfer between programmes. Even if it is a series of Export to x, Export to y but a single file TYPE that is created.
The PSD thumbnail thing is Windoze is also needed back, please.
I understand it’s not fun being yelled at. (I write content tools for a living – I get it daily 😉
But at the very core of this whole thing are a few valid complaints that Adobe *should* try to address – it would make many lives easier.
1) Getting the PSD documentation is unnecessarily hard. While eFax is certainly an option, most people don’t have a fax or an eFax account, and won’t bother to get one. It would certainly be nice if we could just download the thing already. Or pull a Microsoft and just submit it as a standard 😉 (I kid!). Having been on the other side of this as well, I appreciate that it’s much harder than “just put a link on the page” – I’d imagine it needs to filter past an army of lawyers before *anything* happens 😉
2) The PSD documentation is, uh. incomplete. And while it’s nice that there’s PSD documentation, there are other file formats as well. For example ABR. (Hint, hint!)
3) What I personally would *really* like to see – make me fax for it, stand on my head, and sing the Adobe company anthem; heck, charge me for it – is an Adobe SDK that allows me to read all those nifty little PSDs and render them to a bitmap. I have no idea if the demand would justify the effort, but a girl can dream 😉
As for the people above who wondered why anybody would want to read PSD (or suggested that software developers need to be tortured to protect artists 😉 : In many cases, PSD is the first step in a long pipeline. Often, the resulting images need to be re-used in other tools (mostly for visualization purposes).
Both the artists and the pipeline devs would really love to automate as much of that process as possible. Yes, it’s only a small “save as” step – but when there are tons of assets, every manual step will cause a problem.
Hence, reading PSDs directly is simply a way to minimize those mistakes and help our artists to actually focus on the art.
(Sorry for the rant. People forget too often what pipeline devs do for them 😉
I think the author’s main point was that this looks a lot like vendor lock in. The same kind we see Microsoft .doc/.docx etc.
[A) That wasn’t his point. B) No one is forcing anyone to use PSD, much less to reverse-engineer it. –J.]
It would be good to see adobe being more open.
[Did you read the part where I talked about FXG & linked to the docs on opensource.adobe.com? –J.]
[for PSD it works like this: Go to the PS SDK download page, provide your contact info through the (extremely simple) online form, and we’ll get in touch to get the paperwork through. –J.]
Why the hell would any “paperwork” be required to download a spec?
I think it was the original developper question, and you’re only confirming the problem…
BTW I did what you said, and I am now waiting for the said “paperwork” (is it about a NDA? some kind of patent truce? my first born?).
Feels like 1970 all over again…
Awesome post, John. Thanks, once again, for shedding light on an oft convoluted topic. Backwards compatibility is paramount to those who wish to have words like “trustworthy” associated with their brand.
(:
~Issac
Probably a dumb set of questions, but anyway:
If PSD format has always felt the need to evolve and this meant that developers hacked and patched it as maniacs, then why didn’t they completely rewrite it with each photoshop iteration ?
Just to have trimmed down backward compatible solution that would never work as needed ?
Why couldn’t the developers just ditch it each time and have PSD v1, PSD v2, PSD v3 ?
Unlike patching, this would truly have given a clean path of improving the format with each iteration.
But there could be other reasons also of keeping the format as it is now and unless these are national security secrets, you could share from experience.
John,
The amount of abuse you cheerfully accept amazes me. On behalf of satisfied Adobe customers, and Photoshop users in particular, thank you for being so open, honest and forthcoming while interacting with the temperamental among us. I have never had a problem with the PSD format and like Apple products, “it just works.”
I don’t know if other posters realize what a service you render by letting us all know how and why or why not something is considered at Adobe. This seems to me to be an exception rather than the rule among software companies or indeed most large companies at all. All the best, my non met friend, for all your help!
[Heh–thanks, Christopher. I’m amazed you think I’m cheerful. 😉 –J.]
Working for a company that generates thousands of Creative Suite files per month means that we have a huge number of files that were created in CS/1, 2, 3 and, now, 4. Backward compatibility is clearly important to us. We need to be able to go back to these files and use them for current projects.
As a developer, I look at reading PSD’s directly and it reminds me of the days when developers read and wrote disk files directly. I would much prefer an Adobe library that would hide PSD’s entirely and would take the complexity out of trying to understand all of the hidden semantics. For example, I like the direction in InDesign where Adobe has published a standard XML format (IDML) with the schema and IDMLTools. When there is a published interchange format, there is less chance that different third party tools will render documents differently. The user can feel confident that all of the third party tools will interpret a file consistently. This allows him to choose the tool that best fits the job rather then the only one that works on that file.
As someone with great familiarity with the PSD file format outside of Adobe (I wrote and currently still maintain/improve the ability of QuarkXPress to import, composite and print PSD files) – I don’t see what all the fuss is about, and why the file format needs defending at all. It is an organic format that has aged incredibly well. The difficulty is not the format itself, but reduplicating what it represents. Even were Adobe to supply the format in XML for a SAX parser, the format itself is not going to help you one iota to composite an image, especially with all of today’s Photoshop exotica.
John-
Thank you for writing a clear explanation for a topic that some ppl just won’t “get it”
Anybody who thinks you can sit down and quickly and painlessly write a file format reader is just naive.
And notice that nobody has pointed to a successful complex product application that has such a file format.
Go on – i double dare them!
I should also add that the “paperwork” in question contains a non-disclosure agreement, making it unclear if I could even distribute the source code for my program after signing it and receiving the documentation, making it pretty much useless for open-source programmers.
[I’m not sure what the terms of the agreement are vis-a-vis open source. I’ll investigate. –J.]
That’s certainly quite a bit more than “providing your email address” as you claim.
[I was referring to the amount of process involved, not to the agreement itself. –J.]
(Also, I can’t help but notice my earlier post received no acknowledgement whatsoever.)
[Jeez, Dag–did you notice the part where I got ~70 comments in about 8 hours? Sorry that I haven’t yet gotten to go through all of them & reply to you, personally, more immediately. (And by the way, next time, try not telling me to “fuck off” before asking for an immediate response.) –J.]
Hi John
I’m not sure if this is the spot for suggestions, but it would be nice to be able to save an action with a file, so that the action would be available every time the file was opened.
[Ah yes–including executable code inside PSDs would open some interesting cans of worms. I think there’s great potential here, but it would have to be done carefully. –J.]
This would be handy for things like actions that export a file’s layers in a specific way.
Anyway, great post.
[Thanks. –J.]
…Mike
As the author of a bitmap image editor (Acorn for the Mac), and a programmer who has tried to implement a PSD parser- FXG sounds pretty awesome. I get emails all the time from people wanting to save and open PSD files in Acorn.
However- while Photoshop CS4 can save FXG files, it can’t read them? What’s the point? And the .assets directory, where the bitmap layers are saved out as single png files, is kind of a hack.
[The current implementation is, in my professional opinion, totally worthless. Sorry about that; long story, obviously. In the future we plan to make Photoshop & other Adobe apps both read and write FXG, and in a much more complete & useful way. –J.]
Why couldn’t a format where everything is saved in a single file be used? Not all customers are computer savvy, and asking someone to “Export the file as FXG, zip it up, and send it on over. Oh, and don’t forget to attach the separate .assets directory with its contents as well” is a bit much.
I know XML sounds great- but it’s not the only solution out there. Why not use a sqlite based file format? You could then store the layer data in a single file as a blobs, and with the right schema it could be very flexible for future use, and updating a file could be more efficient (you’d only need to update a row if you changed data, as opposed to a whole xml file). Remember- “SQLite is not designed to replace Oracle. It is designed to replace fopen()”. http://www.sqlite.org/whentouse.html
Oh well, I guess that train has already left the station.
If you guys really really want FXG to catch on, you’ll need to make a reference implementation for at least the basics, in C, for Mac OS X, Windows, and Linux. Otherwise, developers are just going to ignore it and work on their PSD parsers.
[Good point. I’ll make that suggestion. –J.]
What would be even better is if Adobe published a reference implementation of a PSD reader/writer. It’s already a de-facto standard.
Really, the fact that PSD format is backwards compatible AT ALL is a great achievement. (to clarify Steven Greenfield, backwards compatible means that Photoshop7 can read a file created in CS4, not the other way round).
[Actually I think you’re referring to forward compatibility–an older app being compatible with future data. Backward compatibility (e.g. PS being able to open all older PS files) is common & expected. Forward compatibility is much harder and more noteworthy. –J.]
Its also, as far as I can see, extremely rare. And as John pointed out its not competitive of Adobe to do this for users at all. Its helpful, allowing users to know that the version they bought will be able to read files well into the future, and saving a lot of hassle out there. As for the internal structure of files – the sheer complexity of what Photoshop files can contain, surely makes that more or less unavoidable.
There is much truth to what you say, in general, except I find this sentence downright bizarre:
“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.”
But who’s going to switch to FXG? Are we going to have to tell clients and designers and so forth “stop sending PSD, start sending FXG”? Are you going to help people migrate their terabytes of old PSD files? The point you made at the beginning still stands: as long as PSD exists (and it will for a long, long time), that’s what people will use, and that’s what third-party tools will need to be able to parse.
This isn’t just a theoretical problem. Microsoft tried the same thing with “OpenXML”. 3 years after it became an international standard, the vast majority of our incoming data (I work on an app that has to deal with Excel data) is old-school XLS. It sounds good on marketing sheets, but for developers and users, it makes life harder, not easier.
I also wonder about what a file format “designed for data exchange” means. Aren’t all document files for data exchange? Isn’t that the whole point of a document? If we didn’t need to exchange them (with other users and apps and computers), Photoshop could just do an in-place core dump to a hidden file and call it good.
Ah, a ‘one true format’ – would be absolutely effing brilliant! Although I question whether XML is the best delivery mechanism; it’s hard enough to backup INDDs and PSDs let alone something twice their size!
I also hope FXG will allow some sort of state-based storage. It can’t be that hard – I don’t mind a file that’s 3-4x larger if I get to restore back 20-30 history points! Losing my Photoshop history after the damn thing crashes is possibly the most annoying thing I have to deal with on a daily basis!
Nice post and great ideas.
Thanks so much for sharing
Although from user prospective the PSD is ok because it kind of works, I do tend to agree that as a developer – writing parsers and outputting something readable back to PSD is needlessly overcomplicated task.
Speaking of my personal experiences in this area, I wanted to implement a Lightroom filtering plugin (i.e. an export plugin that takes an image and transforms it somehow passing it further down the export pipeline). The problem here is that to correctly process all possible scenarios, I need to parse or at least to write the PSD file. The other suppported file formats (JPEG and TIFFs)are actually better in this respect as they are relatively easy to parse and write.
Now I am not complaining per-se but looking at what it will take me to do, and what time I would spend implementing just PSD parsing versus all other plugin work I need to do I decided to abandon all this because of the complexity ;-(
I guess my point here being that the curresnt situation whilst understandable, is sort of deterring the developers of other software to add support of PSD (at least for import/export kind of things) into their applications. And I am not sure whether it is actually a goal Adobe secretly pursuing by playing the funny games with the SDK/infomation access.
Regarding the documentation access, it is not that it is difficult to sign some pieces of paper and send it back to Adobe, it is really understanding why this is not open and available publically? What is Adobe afraid of by making it public and vailable updated with every released version of PS? SDK – I would understand as it has a code examples, but the file format docs? It also deters any development of opensource products that need PSD compatibility by using Adobe official PSD specs (as I believe a non disclosure is required to be signed off).
Adobe lighten up. This “anonymous developer’s rant about PSD” was not intended to be a widespread attack; it was a code comment. Programmers often relieve tension while coding by writing comments like that. It’s human nature to need to vent at times.
His point about the difficulty of obtaining the documentation is valid. You have to send a FAX to get it??? What decade is that policy left over from? And based on his comments (rather than on your extremely brief “summary” of his comments), it’s not just a fax saying “Please send the documentation to this address”, it’s a full-blown application form probably with some kind of signed legal statement and possibly with identification required. Of course people are going to baulk at that. If you want your format to be widely used, correctly used, and appreciated, make its documentation freely available on the web! (Both free as in beer and free as in no application required.) What possible harm could come to your company by publishing the documentation? Hiding it away behind an out-dated, convoluted application process just makes life unnecessarily harder for the people who use your format.
“What other app lets you open & work with a file without having that file’s fonts installed?”
Microsoft Office. It allows users to embed fonts in their documents.
Had he sent the fax and received the documentation (as I have), he would have been disappointed. It does a fairly good job of defining the blocks layout in the file, but the precedence and contents of the blocks are sparsely documented.
As mentioned in this post, PSD was never meant to be an interchange format, but in the same post the you go to great lengths to point out how painful it would be if PSD went away. PSD _is_ a de facto interchange format. Adobe should acknowledge this and do a better job documenting it so that it can have better support.
In the demo version of CS4 I just downloaded, adjustment layer info seems to be dropped.
A single file could just be a zip or tarball (underneath the hood), making it easy to pull apart with existing tools.
Is there a command line psd -> fxg tool?
[Unfortunately FXG support in CS4 is rudimentary at best. Please don’t make any judgements about the quality of the format based on what you see now. We’re making a much more concerted effort across the board going forward. –J.]
The format structure is great for my purposes: raster image data in a standard form (PS CS4 wrote out a bunch of pngs), layer compositing info as simple metadata. But I don’t see anything in the 1.0 spec that could represent, say, a levels adjustment layer.
[I’m not sure what’s spec’d, but I’ve heard discussions of how Pixel Bender could be used to express/re-create these adjustments. It may be that support for these don’t show up for a while. –J.]
I’m just squeakin’ for some grease, man!
[I’m certainly glad to hear your interest. –J.]
After not getting my mail answered, signing up for a useless ‘developer account’ and look for naught for some fax form that seems more than nebulous. Instead I recommend checking out: http://www.fileformat.info/format/psd/spec/index.htm where you can get what you need, when you need it (sure it’s out dated, but it’s better than jumping through hoops because the powers at be like to see people dance). I still wait with baited breath for a reply to my request on where the Fax can be requested, Mr. Nack.
Coming soon to a 64 bit Windows PC near you.
http://www.ardfry.com/psd-codec/
David – that looks very good (and your other codecs look interesting, too).
I have worked on a PSD parser some time ago and the format itself is really not that bad. Yes, it’s inconsistent and suboptimal, but as this blog post says, it’s natural considering its long evolution and enormous amount of features it came to support.
Having said that, working with the format was real pain. Why?
1) Lack of freely and publicly available specs. And by free I mean available to anyone with no strings attached. Currently you have to sign an NDA and fax it to Adobe. It’s not an option for everyone. It’s good that it no longer requires ADN membership but the access to it is still too restricted.
2) The specs are incomplete and ambiguous. They only describe how the data is stored in the file and not how to interpret it. Data without interpretation is worthless. Most notable example: blending modes. The only thing provided in the specs is the name of each mode. Nothing about how it works and should be rendered, no formula. Yeah, it’s easy to figure out most of them but not all – I still don’t know what exotic variation of HSL/HSV color space is used by Hue/Saturation/Color modes. Or how to generate the exact pattern that dissolve uses.
More examples? Effect layers (glow, drop shadow, etc.). The file contains all necessary parameter values (blur, angle, intensity, distance) but their meaning is not always clear and it makes it impossible to recreate them faithfully.
I’d be happy if I could just forget about PSD and go with FXG but it’s not an option. PSD is used as de facto interchange format and software has to support it. It’s not possible without better documentation.
Quote 1 : “John, I have seen many claims online that the PSD documentation was not complete, or up to date, and that total compatibility was not possible.”
I can confirm that. We have access to the latest documentation of the PSD format and it’s really far from up to date. 16bits mode layer not documented, 32bits not documented, etc. It’s a 2002 document. Please provide an update of that document.
Quote 2 : “What bugs me is why would anyone want to reverse engineer PSD file?” : Because Adobe Photoshop PSD format is a standard in the industry, so
as developer you have to be compatible with it.
Hi, I want to get “Adobe Photoshop file formats”, can you mail me a copy of it?
I want to know how .abr file format, and how it works.
Thanks.
e-mail:dsclub@vip.qq.com
Actually, PSD originated in Photoshop 2.5 which did have both paths and duotones (those were introduced in Photoshop 2).
The primary ugliness in the PSD format stems from inconsistencies about how to handle lengths and padding and whether to use tagged values or fixed offsets for properties. There are other things that could be better, but those are probably the most glaringly “ugly” bits of the format. Over time, many of those conventions got sorted out — e.g., tagged values are better — but backwards compatibility meant that the old elements needed to continue to be represented the old way. What is sad is that PSB perpetuated this ugliness while creating a format the wasn’t going to be directly readable or writable by existing PSD readers.