But right for now I would settle for just a layers export that includes each layer and it’s individual name.
Mhhh, all the layers at once?
The File I/O plugin interface might be OK for exporting single layers, but probably the DDE interface is the one to go to export the whole project as a Photoshop file. The file IO interfaces passes preprocessed images, where layers are merged, opacity settings and filters applied, which is not going to convert the PM project to a PS equivalent. The DDE interface is more flexible for it allows to extract all the required data, separately.
Anyway, there are various ways to go about it, including exporting as TIFF images, which in Photoshop can carry all the required layers info — PS TIFFs are as near as you can get to a
.psd project file, in fact I mostly save PS projects as TIFF images, for portability.
In any case, exporting is easier than importing, because you’d be targeting only specific features, whereas with an incoming PSD file you’d have to deal with all the unsupported features that you might encounter in a file (probably, just by opening and saving in Photoshop a PSD file created by PM NG would add lot’s of extra info to the PSD file that wasn’t there in the first place).
The clipboard is also an exploitable tool for exporting layers — not only via the DDE interface, but also via the file export interface: it can be “tricked” to export to the clipboard instead of a file; even though it passes to the plugin a destination file name, it doesn’t do any checks that the file was written, so the plugin can really do what it wants with the image data. Usually, clipboard images representation have lower requirements than files (no file headers, no compression, etc.) so they might provide an easy solution for complex formats.
I think that the upcoming new PM plugin interfaces should make similar operations easier and more accurate, but chances are that these won’t be available soon (not before summer anyway).
In these days I’ve been working again on the PM plugins interfaces templates, updating the code and the documentation, and was planning to do so the whole week (got some spare time between a close project and a new one starting next week), so I’ll give this a quick look — but nothing more than digging into the PS tech-specs for the moment.
There are still some issues with the plugin interfaces documentation which I need to solve, some details are still obscure and preventing full exploitation in the templates. I was planning to create a Rust version of the templates (at least, the File I/O interface to begin with), but these undocumented features are really blocking the work. These pending info for the two plugin interfaces are the main reason why my plugins projects haven’t evolved much in the last year.
Once I manage to get from Jan clarifications on all the required info, I should then be able to reach the stable release with the current PureBasic boilerplates and start covering other languages too (PureBasic being a commercial language is a limiting factor) — I was thinking of Rust, but also FreeBASIC, which is a simple language to use and could attract more developers to the plugins project.
My hope is that in the near future we might see some community joint efforts in plugin developments, which would greatly simplify the whole endeavour (e.g. by providing ready to use functions, algorithms, etc.).
@Morintari, which would be the programming language you’d be more comfortable developing plugins with?