Make ProMotion export into Photoshop with layers,types of layers, FX layers,and tilesets intact? ProMotion is the best tool I’ve ever used to draw pixel art or 3d stereoscopic pixel art. And I would love it if we could use all the power of Photoshop with it?
Thank you for your time.
Hi @Morintari. Indeed an interesting request.
This should be something that can be (and probably should) be done via custom File I/O plugins probably. The problem I foresee in this is the amount of different elements supported by PS — not all of which are documented by Adobe.
If this can be of any help, here is a project I re-published on GitHub a few years ago, containing various JS scripts by Michel Mariani to export and import a variety of PS elements:
It also documents some PS specs which are not officially documented by Adobe.
As I said, it’s an interesting project but at the same time a cumbersome one. The ideal approach would be to see a group of developers work on a custom plugin to export/import to/from PS file formats, in a well planned manner, starting with simple layers, then adding support for transparency, and so on.
Definitely, it requires a lot of reading and sifting through the Adobe PS documentation, but it should be doable (although I suspect that some undocumented formats might be patented and not employable).
I would have though that most operations should be already doable by either saving to some commonly shared images formats or even via the clipboard. Of course, being able to export a whole proejct, layers and all, would be a great improvement.
All of the proMotion abilities would be nice tajmone. But right for now I would settle for just a layers export that includes each layer and it’s individual name.
Thanks tajmone for writing back!
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?
tajmone, Thank you as considering this as one of your projects. Unfortunately I am an artist not a programmer so I wouldn’t be able to help you. I’m sorry.
I didn’t manage to pursue any further this due to the current problems with the File I/O interface, so it will have to wait that they are fixed and documented.
But so far I’ve found an obstacle to this type of conversion, i.e. that PMNG allows 256-colors indexed layers, each one with its own palette. In Photoshop an image project is either true-color or indexed, not both. So converting a PM project that uses different color maps (palettes) for each layer is going to be a one-way feature only, and it will either need to export as a true-color PS project, or as separate indexed-color projects (one for each layer that uses a different palette).
In theory, it could be possible to create a secondary file containing extra info about the color maps of each layer, but in practice it might be very hard (if possible at all) to efficiently handle reopening in PMNG a project which was exported to PS, and edited. This might require creating a Photoshop plugin too, for handling the extra data correctly and support exporting to/from PMNG.
I guess that the whole idea of being able to work with both tools would make sense only if it allowed to seamlessly switch from one tool to the other while working on the same project, which should be an easy operation that doesn’t destroy any data.
The problem is that these two programs take a quite different approach to image processing, and while Photoshop is often used by pixel artists, it’s not a tool designed with pixel art in mind. I personally think that PM approach to pixel art is the correct one, i.e. focusing on indexed color maps, and allowing different color maps (palettes) on a per-layer basis.
Sure, Photoshop is a powerful tool, but ultimately I wonder how much of that power can be safely applied to Pixel Art. Most of PS internal algorithms were designed with high-resolution images in mind, particularly photographs, and definitely not pixel-by-pixel artistic works. In general, to use PS on very small images (e.g. 50x50 px) you need to disable a lot of features to prevent messing up the image (anti-aliasing, etc.), and even after doing this, many pixel-perfect operations often turn out to be unfriendly to carry out.
Tajamone: Id like to publically apologize to you. At the time I was’nt aware that you could save brushes to PNG so easily. That’s why I asked for this feature I’m sorry that I burdened you with it.
No burden at all, I’m also curious about exploring potential interfacing with other apps like Photoshop because it’s always an added value to the workflow.