pspi for gimp on linux
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
pspi for gimp on linux | Carol Spears | 23 Mar 19:48 |
pspi for gimp on linux | Tor Lillqvist | 23 Mar 20:52 |
pspi for gimp on linux | cedric GEMY | 23 Mar 22:58 |
pspi for gimp on linux | Tor Lillqvist | 23 Mar 23:56 |
pspi for gimp on linux
there are rumors lately that tor will be working on getting the pspi filter thingies working on linux. when they become available will that be announced on this list?
i am curious to no end about these; my idea is that even i will be able to write a pure gimp equivelent of them. they simply have not been available to me on the computer that i use yet.
there is always the chance that photoshop plug-ins are a magical thing that a simpleton like me could not ever concieve of emulating, it would be nice for me to know this though.
carol
pspi for gimp on linux
Carol Spears writes:
> there are rumors lately that tor will be working on getting the pspi
> filter thingies working on linux. when they become available will that
> be announced on this list?
Sure; Today I built pspi on SUSE 10 and Ubuntu. Downloadable from http://www.gimp.org/~tml/gimp/win32/pspi.html . Hopefully the Ubuntu binary works for Debian, too? Or are the shared library sonames too different? I wonder whether either binary might work on Fedora, too?
Sorry, no distro-specific packages (.rpm or .dev), just tarballs with three files: README.linux, pspi and pspi.exe.so. Plus a source tarball, of course.
> there is always the chance that photoshop plug-ins are a magical thing > that a simpleton like me could not ever concieve of emulating, it would > be nice for me to know this though.
Well, many of them *are* quite trivial and already implemented in GIMP. But I guess some of them are not that trivial.
Please also keep in mind that pspi works only with 3rd-party Photoshop plug-ins, not the ones by Adobe that ship with Photoshop.
Here's the contents of pspi's README.linux:
How to use a binary Linux distribution of pspi ==============================================
You should have three files:
README.linux, this file
pspi, a small shell script
pspi.exe.so, the binary that wine runs
Copy pspi and pspi.exe.so to your personal GIMP plug-ins folder, typically ~/.gimp-2.2/plug-ins .
When you run GIMP it will issue a warning "wire_read(): error" as pspi.exe.so isn't a GIMP plug-in. This warning is harmless (GIMP just ignores that file then), but if you want to avoid it, move pspi.exe.so somewhere else and modify the pspi script to point to its new location instead.
After starting GIMP, go to the Xtns:Photoshop Plug-in Settings and enter the folder where you are going to keep the 3rd-party Photoshop plug-ins (.8bf files) that you want to use in GIMP.
Preferrably you should use an initially empty folder for this, and then install (copy) Photoshop plug-ins there one by one, verifying that each works. It isn't really useful to rush and install a shitload of Photoshop plug-ins at once and assume they all will work under pspi.
And here is the general README file:
Introduction ============
This is pspi, a GIMP plug-in that interfaces to Photoshop filter plug-ins.
First, the bad news: Pspi only works on systems that understand i386 Windows executables, more specifically, DLLs. (Photoshop plug-ins are actually DLLs.) Pspi was developed on (i386) Windows. It is also possible to build and use it on i386 Linux, using Wine.
To build pspi, you will need the headers from the Adobe Photoshop 6 SDK. It used to freely available from Adobe, but unfortunately isn't any longer. If you can find an old copy of Photoshop 6, the SDK is included on the CD.
To build pspi on Linux, configure it like this:
CC=winegcc ./configure --with-pssdk=/path/to/pssdk6
Before compiling on Linux, you need to fix a few glitches in the PS6 SDK headers:
-In PhotoshopAPI/Pica_sp/SPProps.h, change the #include of SPMdata.h to use the correct file name SPMData.h. (On Windows, this of course is not relevant as the file system is case-insensitive.)
-In SampleCode/Common/Include/PIUtilities.h, comment out the #include of Types.h, whatever that is, which is not needed.
-In SampleCode/Common/Include/WinUtilities, put the extern "C" begin and end braces inside #ifdef __cplusplus..#endif .
Debugging pspi ==============
You can set the environment variable PSPI_DEBUG to have pspi print out various debugging messages at run-time, for instance (in a Windows command prompt):
set PSPI_DEBUG=resource_suite:debugger
(or in a Linux shell):
export PSPI_DEBUG=pipl
See the source code for other possible values. Obviously, this environment variable must be set before starting the GIMP (which eventually runs pspi).
On Windows, as pspi is a Windows GUI application, to actually see the debugging print-out, you have to start GIMP from a command line with stdout going somewhere, for instance:
gimp --verbose | cat
This stdout redirection will be inherited by GIMP's children, like pspi.
Run-time setup
==============
Pspi has a search path consisting of folders where to search for Photoshop filter plug-ins, which are files with the extension .8BF. These folders are searched recursively.
Pspi stores info about the Photoshop plug-ins found in the pspirc file in the user's personal GIMP directory. The first time a .8BF file is noticed, pspi loads it and searches for the so-called "PIPL" resources, which contain some more information about the Photoshop plug-in, for instance where it should be located in Photoshop's Filter menu. It gets a identical menu entry in GIMP's /Filter menu.
Unless the .8BF file changes, it isn't loaded on subsequent GIMP starts, but only when the filter is invoked.
Also files with the extensions .EFF and .DLL are checked to see if they are Photoshop plug-ins.
Reverse engineering ===================
The hardest thing in writing this plug-in was figuring out the stuff in the Photoshop plug-in communication that isn't clearly documented. To make the reverse engineering easier, I wrote a "proxy" Photoshop plug-in, piproxy. The Windows resources of a real Photoshop plug-in (the "target") is copied to piproxy.8bf. The target should be moved away so that Photoshop won't find it, and instead piproxy.8bf shouild be put where Photoshop will find it.
Thus, piproxy gets loaded when the menu entry for the original plug-in is invoked. It then loads the original target plug-in, and starts passing calls back and forth between Photoshop and the target, while logging the stuff that passes through. This works fine. If you intend to run piproxy, set the PIPROXY_LOG and PIPROXY_TARGET environment variables. See the source code.
The piproxy sources are included, but it does not get built by default.
After a week of late-evening hacking, the breakthrough came when I realized that the "Handle" type in the Photoshop API is used by some plug-ins in an undocumented way. Instead of treating a Handle as an opaque type, they "know" that a Handle in fact is a pointer to a pointer, and use it like that without calling the "lock" API which is the documented way to get the pointer from a Handle.
Tor Lillqvist , December 2001, March 2006.
pspi for gimp on linux
But how are these filters licensed by Adobe ?
Cedric
pspi for gimp on linux
cedric GEMY writes:
> But how are these filters licensed by Adobe ?
What "these" filters? As I said, pspi doesn't even work with Adobe's filters (those that are bundled with Photoshop). Even if it did, I don't know whether your Photoshop license would allow them to be used with other plug-in hosts.
As for 3rd-party filters, why would their vendors want to restrict what program they are used with? The more customers 3rd-party filter vendors get, the happier they are, presumably. There are lots of programs other than Photoshop that can use Photoshop plug-in filters: PaintShopPro, Xara, and IrfanView for instance.
--tml