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.
I checked out psd-tools and it's good. Any chance of you adding their features to yours or vice versa? I know I know, I should do it myself and do a pull request, but just asking if you are planning to?
Unfortunately I'm currently very busy with other projects, so I probably won't implement PSD.rb features myself anytime soon.
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.
I didn't check your codebase (I just used the library for a few projects a while ago), so you don't have to answer. But if you want to enlighten others as well as me; am I right in thinking that you have a reader while reads the file and then have a 'decoding module' for every blob. So it would be rather straight forward to port from Ruby such a decoding part and plug it into your library?
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 :)
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.
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.
"Just use Ruby" isn't always the best option; if you have a large base of Python code, it's probably preferable to use Python directly rather than using the subprocess module.
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.
A "large base of Python code" would not be my main reason for eschewing other languages:
- 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.
> Tell me, what is less effort: Implementing that, or building a small app/service that performs the functionality you need using existing tools?
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.
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.
Nice. Obviously I didn't look too hard hence "doesn't seem to exist". My main point was against reimplementing something already extant just because you have a swathe of code in a given 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.