Psd.rb
layervault.tumblr.com
layervault.tumblr.com
https://code.google.com/p/xee/source/browse/XeePhotoshopLoad...
(ref: first link in the article)
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.
Older illustrator files are in fact, EPS files. This is somewhat tricky since, an EPS is not actually so much a data format as it is a turing complete programming language. Sooo... yeah, who knows what black magic they did to pull off reliably reading and writing it.
You can write an EPS file by emitting your list of shapes without using the turing-complete features of the language.
Not that hard, at least conceptually.
But seriously, this kind of back-compatibility horror is the hallmark of success, where success means enduring.
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.
I think with an actual copy of Photoshop, and a little Applescript, this is something you could have done > 15 years ago.
If you just want to do basic conversion ignoring layers, it's quite easy:
for f in *.psd; do
convert "$f" "${f%%.psd}.png"
done find . -iname "*.psd" -print0 | xargs -0 -P 4 -n 1 -I I convert I I.png
find . -iname "*.psd" -print0 | parallel -0 convert '{}' '{.}.png' $ pacman -S applescript
error: target not found: applescript
$ pacman -S photoshop
error: target not found: photoshop
$ ruby --version
ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-linux]
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.
Not trying to start a Ruby/Python fight or anything; Python just happens to be my preferred language.
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.
I'm trying to provide feedback for psd-tools pull requests, merge them and release new psd-tools versions in timely manner; the testing suite also helps here, so you know, pull requests are welcome :) Most improvements over last 6 months came from pull requests submitted by other great people.
I think that the "reader" part of library is feature-complete. psd-tools reads all the information, but it doesn't decode all Photoshop data structures (some of them are available only as binary blobs). So I think implementing a PSD.rb feature will most likely involve checking PSD.rb code and decoding a binary blob (already loaded to memory) to a Python data structure.
The whole process is divided into 3 stages: reading, decoding and providing "user-facing API":
- on "reading" stage PSD file is read and split into binary blobs (I think this part is done);
- on "decoding" stage "decoding modules" are called for each binary blob; decoding modules should produce Python data structures that closely resembles internal PSD format;
- on "user API" stage decoded data is converted to more convenient format that is easier to work with (e.g. this include building layers hierarchy, and the PSDImage/Layer/etc classes).
I hope that providing new decoders will be rather straightforward, and it seems to work this way so far: contributors haven't touched "reader" part, and I haven't touched it for a while as well. But software development is hard, so we can never be sure :)
Feel free to steal anything: test PSD files, etc.
If you want to implement layer blending in PSD.rb (required if you want to be able to export layer groups as images) then check libpsd C library - I think it has the most sophisticated open-source PSD blending implementation available.
Your PSD.rb and https://github.com/layervault/psd-enginedata libraries are very nice too; unfortunately I'm busy with other projects now, but maybe somebody will take effort and port PSD.rb features to psd-tools, or I could do this in future - the LayerVault's code will be very helpful.
Also, a port would be fairly straightforward. Some combo of the struct/ctypes modules (depending on how complicated the data structures are) would make a transliteration pretty simple.
- Unfortunately psd.py doesn't seem to exist. Tell me, what is less effort: Implementing that, or building a small app/service that performs the functionality you need using existing tools?
- Also I'd consider the suitability of a given technology before this too, e.g. on my current project there is a lot of Ruby code, but it's a major bottleneck in one of our services performing a particular task. We rewrote that service in Clojure and it performs orders of magnitude faster and uses orders of magnitude less memory.
I think it depends on your use case. In certain cases, you want to do work inline. In other cases, you want to do PS manipulation in the background. I could imagine projects that go in either direction. If I had a large Python desktop application, I'd port the code. If I had a Django application that wanted to do background processing of PS documents, I'd put the work on a queue and have Ruby take care of the messy bits.
> Also I'd consider the suitability of a given technology before this too, e.g. on my current project there is a lot of Ruby code, but it's a major bottleneck in one of our services performing a particular task. We rewrote that service in Clojure and it performs orders of magnitude faster and uses orders of magnitude less memory.
I take a different approach. If I find a bottleneck in Python code, I use ctypes or write a C extension. I'd do the same thing in Ruby. I'm hesitant to deploy multiple runtimes, since I worry about security updates, etc. If I were on JRuby, Clojure would be a natural fit -- I'd only be deploying one JVM.
This is just plain wrong. There are many Python readers for PSD format:
* https://github.com/kmike/psd-tools
* https://github.com/jerem/psdparse
* https://code.google.com/p/pypsd/
* PIL and Pillow can read PSD files.
I'm biased because I wrote psd-tools, but I think psd-tools API is quite simple, and it has some features that PSD.rb doesn't have, e.g. it supports more PSD compression formats (actually, all of them) and can export individual layers and layer groups as images. It also has more tests than PSD.rb and more PSD files in testing suite.
But it seems that reimplementing worked very well for them: API, language and a good timing really matters.
or check out psdparse on github ( there are others out in the wild )
It runs inside Photoshop (there is no upload stage nor do you have to open up separate software) and it generates HTML and CSS that looks like a designer wrote it and slices up all your images. It also outputs LESS, SASS, HAML, Slim, Jade and I think there are some other formats I may be forgetting.
Text is output as text. If you use a Google font, it automatically links the fonts in for you.
It does not use absolute positioning so if you modify things like text and it grows taller or shrinks shorter, other items will be positioned properly (initially we did it with absolute positioning but later I figured out an algorithm to make it work the way it should, even with overlapping elements).
It's definitely not an easy problem to solve (hence why we've been working on it for over a year although not full time).
We've done some outputs now and the results are amazing.
I would link you to the website but it looks so bad right now that I don't want to show it. Anyways, we will launch in about a week so look for an announcement. If you have any questions about it, please leave a comment.
Sunny
Ideally, you'd have to spend some time making sure your .psd is formatted properly instead of just 100 layers names Layer X.
markupwand.com is pivoting...
If anything, I think it would be a cool project to build on top of PSD.rb instead of bloating the core library.
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?
I see bro...