This programmer has written about the PSD format in colorful detail: "Trying to get data out of a PSD file is like trying to find something in the attic of your eccentric old uncle who died in a freak freshwater shark attack on his 58th birthday."
>Adobe has never produced an easy way for developers to work with the format.
That's not entirely fair. Adobe has openly released a comprehensive description of the format which is, as far as I know, accurate. The problem is that the format itself is a heap of features piled on year after year with apparently no regard for doing things consistently.
Does anyone else think it's weird that they decided to make this library in Ruby? It drastically cuts down on the audience. Why not C/C++ with wrappers for all the dynamic languages?
EDIT: nevermind, it makes sense now that I see their main product is a version control system for designers. Still, it would be nice to see this ported to native code some day.
as a programming language fan, i've never found anything as productive as ruby. it may not be the fastest language out there, and it may not have a bunch of static safety guarantees, but for exploratory programming it's pretty much unparalleled. if i were tasked with making a psd reader, i'd definitely do it in ruby first and then port it over to whichever language the client called for.
libpsd and PSD.rb both have features that the other doesn't have. For example, PSD.rb parses text/font data, while libpsd can handle images with zip compression.
libpsd was actually a great reference in building PSD.rb, especially since it was correct during the times that the actual file spec was wrong and more explicit in the type of data being read.
Thank you very much for doing this! I wish all people hacking the PSD format would join forces and help with one project. There are too many partial implementations which scratch an itch instead of trying to be a full implementation.
I've read PSD.rb docs and a bit of its code; the implementation is one of the best and complete I've seen (I've checked almost all PSD reader implementations some time ago).
But it seems that psd-tools is mostly on par with PSD.rb. It also have some features that PSD.rb doesn't have, e.g. full support for 'zip-with-prediction' compression, including 32bit layers. Such images are very common in practice, and parsing them is not easy because the compression format is not documented anywhere, and "zip-with-prediction" for 8 and 16bit layers is totally different from "zip-with-prediction" for 32bit layers (for 32bits it is really tricky).
psd-tools also knows how to export individual layers, and there is an experimental support for exporting layer groups; it seems that this is not implemented in PSD.rb yet.
PSD.rb has some features that psd-tools doesn't have, e.g. it parses "Font data" which is really cool and hard because the format is not described anywhere.
Just use Ruby for this. I prefer Ruby, but there are times I will pick Python instead because it has better libs for what I need to do, e.g. numerical and scientific libs.
Great work and thanks for building this. There's a lot of room for improvement in automating manipulative photoshop exports, and I look forward to seeing what people do with this, especially in terms of building command line tools.
I have been trying to do this from last 3 months. But I intend to make modifications to layers (turn on or off, change colors) and export to PNG. When I saw Psd.rb I thought it is done. But it just exports the channel data saved by Photoshop. So our modifications wont reflect in it.
I reckon a good tool (that this psd.rd wouldn't actually help write, but), would be one that rendered an html/css page - and exported a layered PSD, so you could prototype an app, render it to .psd and send it to your designer friend to make it look rad.
This is a great example of why open source is brilliant. Everybody wins. We get a PSD parser. LayerVault benefits from the world improving they're core product too.
Look up markupwand.com an YC alumni. The problem is harder than it looks. Now, I am not an expert in PSD format but a PSD that can be automatically converted to HTML has to be specifically formatted. For example, if you merge text layers with image layers, it becomes difficult to extract the information.
So, will there be writing .PSD files as well? This would be the über thing. Imagine: upload a .PSD and get back a clean HTML layout + bootstrap_overrides.css
Writing PSD files is considerably easier than reading them. To write, you need only support the features you actually use. To read, you must support everything. For example, Photoshop always saves its layers RLE compressed (or it did when I last wrote code to write PSD files, which was about five years ago), but the format supports uncompressed layer data just fine. So if you're just trying to get basic interoperation with Photoshop, you don't have to worry about RLE at all.
>Imagine: upload a .PSD and get back a clean HTML layout + bootstrap_overrides.css
These are great news for developers and an easy way to communicate between designers with developers. Is the beginning of a solution for a big problem.
[+] [-] artagnon|12 years ago|reply
https://code.google.com/p/xee/source/browse/XeePhotoshopLoad...
(ref: first link in the article)
[+] [-] dbond|12 years ago|reply
[+] [-] nja|12 years ago|reply
[+] [-] mistercow|12 years ago|reply
That's not entirely fair. Adobe has openly released a comprehensive description of the format which is, as far as I know, accurate. The problem is that the format itself is a heap of features piled on year after year with apparently no regard for doing things consistently.
[+] [-] meltingice|12 years ago|reply
[+] [-] 6ren|12 years ago|reply
But seriously, this kind of back-compatibility horror is the hallmark of success, where success means enduring.
[+] [-] bluedino|12 years ago|reply
[+] [-] tommoor|12 years ago|reply
[+] [-] blt|12 years ago|reply
EDIT: nevermind, it makes sense now that I see their main product is a version control system for designers. Still, it would be nice to see this ported to native code some day.
[+] [-] stormcrowsx|12 years ago|reply
[+] [-] zem|12 years ago|reply
[+] [-] gburt2|12 years ago|reply
[+] [-] flixic|12 years ago|reply
[+] [-] justinator|12 years ago|reply
I think with an actual copy of Photoshop, and a little Applescript, this is something you could have done > 15 years ago.
[+] [-] muratmutlu|12 years ago|reply
[+] [-] mhd|12 years ago|reply
http://sourceforge.net/projects/libpsd/
[+] [-] meltingice|12 years ago|reply
libpsd was actually a great reference in building PSD.rb, especially since it was correct during the times that the actual file spec was wrong and more explicit in the type of data being read.
[+] [-] adamwong246|12 years ago|reply
[+] [-] tluyben2|12 years ago|reply
[+] [-] voltagex_|12 years ago|reply
[+] [-] nja|12 years ago|reply
Not trying to start a Ruby/Python fight or anything; Python just happens to be my preferred language.
[+] [-] kmike84|12 years ago|reply
I've read PSD.rb docs and a bit of its code; the implementation is one of the best and complete I've seen (I've checked almost all PSD reader implementations some time ago).
But it seems that psd-tools is mostly on par with PSD.rb. It also have some features that PSD.rb doesn't have, e.g. full support for 'zip-with-prediction' compression, including 32bit layers. Such images are very common in practice, and parsing them is not easy because the compression format is not documented anywhere, and "zip-with-prediction" for 8 and 16bit layers is totally different from "zip-with-prediction" for 32bit layers (for 32bits it is really tricky).
If PSD.rb authors are reading this, I urge them to check the decompression code in psd-tools (https://github.com/kmike/psd-tools/blob/master/src/psd_tools...) or in Paint.NET PSD plugin (http://psdplugin.codeplex.com/) to not waste the time.
psd-tools also knows how to export individual layers, and there is an experimental support for exporting layer groups; it seems that this is not implemented in PSD.rb yet.
PSD.rb has some features that psd-tools doesn't have, e.g. it parses "Font data" which is really cool and hard because the format is not described anywhere.
[+] [-] sjtgraham|12 years ago|reply
[+] [-] TheZenPsycho|12 years ago|reply
[+] [-] fish2000|12 years ago|reply
[+] [-] enry_straker|12 years ago|reply
or check out psdparse on github ( there are others out in the wild )
[+] [-] shurcooL|12 years ago|reply
[+] [-] freerobby|12 years ago|reply
[+] [-] netforay|12 years ago|reply
[+] [-] jawngee|12 years ago|reply
[+] [-] captainbenises|12 years ago|reply
[+] [-] carlosdp|12 years ago|reply
[+] [-] smickie|12 years ago|reply
[+] [-] envex|12 years ago|reply
[+] [-] gnufied|12 years ago|reply
[+] [-] meltingice|12 years ago|reply
If anything, I think it would be a cool project to build on top of PSD.rb instead of bloating the core library.
[+] [-] tlrobinson|12 years ago|reply
[+] [-] smtm|12 years ago|reply
[+] [-] mistercow|12 years ago|reply
Writing PSD files is considerably easier than reading them. To write, you need only support the features you actually use. To read, you must support everything. For example, Photoshop always saves its layers RLE compressed (or it did when I last wrote code to write PSD files, which was about five years ago), but the format supports uncompressed layer data just fine. So if you're just trying to get basic interoperation with Photoshop, you don't have to worry about RLE at all.
>Imagine: upload a .PSD and get back a clean HTML layout + bootstrap_overrides.css
Why would that require writing .PSD files?
[+] [-] FuzzyDunlop|12 years ago|reply
[+] [-] kellysutton|12 years ago|reply
[+] [-] cveigt|12 years ago|reply
[+] [-] primitur|12 years ago|reply
[+] [-] isaacjohnwesley|12 years ago|reply
[+] [-] jheriko|12 years ago|reply