Hacker News new | ask | show | jobs
by just_for_you 1966 days ago
I would actually beg to disagree, as someone who was bored a few weekends ago and decided to go through a few reasonably-complex PSD files (eg, ones with different layer types, bezier curves, etc.) in a hex editor with the official specification in-hand in an attempt to understand the format. (The specification can be found here: https://www.adobe.com/devnet-apps/photoshop/fileformatashtml...).

After a few hours, I was able to grok it without too much difficulty, and found the format was reasonably well laid-out. Yes, it does suffer from some "let's take the in-memory representation and bake it into the on-disk format"-isms, and there were a few things were not covered by the specification (eg, a couple Resource IDs aren't mentioned at all, or they are, but there's no documentation on how to interpret their content) - but it's not anywhere close to insane.

To give an example, partially going off memory from what I remember seeing in real files, but mostly skimming the spec, a very basic gist of a typical PSD files might look something like this. (I can only assume HN is going to mangle the formatting of the following text, so expect to see multiple edits to this comment):

EDIT: I was right about the formatting getting messed up. I've posted it to Pastebin and will call it a day:

https://pastebin.com/raw/WZNrCSAP

So that (the Pastebin link above) is the basic and oversimplified gist of a PSD file. It's mostly just reading 4-byte tags and length fields. Now, rendering a complex PSD file (or worse: generating a complex one) is another matter, but the on-disk format is pretty understandable IMO. Creating a bitmap-to-PSD conversion program from scratch is also something I could see being doable in a weekend if you followed the spec, and, as long as the PSD only contained simple rasterized data (eg, no filters and other fanciness) and only the bare-minimum ResourceID/Layer tags.

Honestly, I really trust PSD as a general interchange format for images. It's quirky in some places, but it's pretty logically laid-out, is universally-recognized, and I can rest assured that a rasterized copy of my images will always be stapled to the end of the file if worse comes to worse. There really is no alternative, because while you can contain Photoshop data in a format like TIFF (Photoshop just staples the entire PSD file into a TIFF/EXIF tag anyway), and if an application unaware of that PSD data opens the TIFF files and saves it, the Photoshop data might go poof or have a mismatch with the other TIFF data. And then there's Gimp's XCF format, where the on-disk format is allowed to be changed willy-nilly because you are only supposed to use Gimp's official library for reading/writing to it (not to mention no application really supports XCF aside from Gimp and maybe a few open-source projects). And let's not even bother with $application-specific formats, because they are meant only for that specific application.

The moral of the story is PSD is an alright format.

2 comments

No, it's nothing of the kind. It's not alright, it's not a general interchange format for images that you can trust, and the specification isn't complete or correct in any case.
But the problem is not in the "basic and oversimplified gist". If you look at it on that level, it looks reasonable.

The problem is in nearly every detail that is left out of such an overview. Every little detail is weird, unexpected or annoying.