YOUR ACCOUNT

Login or Register to post new topics or replies
Davide Barranca

Posts: 7
Hi,
I've recently got in touch with the FF support with a feature request that – I've been told – the development team had already thought about in the past, but it never went through. I'd like to push it here as well, to hear from other community members what they think about it. Who knows, maybe it can get some traction.

As a Photoshop extensions/panels developer – mostly in the photography/retouching business – either I use scripting to create an image processing routine using existing PS tools as building blocks (somehow limited and slow), or I rely on C++ plugins (faster, but steeper learning curve) for the pixel crunching step.

I've used both systems in my commercial products, with a preference for the latter option. E.g., a panel (a JS apps or a PS scripted dialog) acts as the GUI with buttons, sliders and the like; it passes parameters to a headless (no-GUI) C++ scriptable Filter, which sole task is to receive input params and process the image.

All is well, except that I'm no C++ expert and (true story) I've used Filter Forge diagrams to explain to a C++ developer how to rebuild the routine which I already had created, as a full-working FF filter myself!

Which leads to my actual feature request, i.e. the possibility to export a FF filter as a GUI-less, Scriptable Photoshop plugin that can be embedded in separate, independent Photoshop product as pure image processing engine. No GUI, no sliders, no preview, nothing – just the Filter that can accept params via PS scripting and do its job.

I understand that this feature could appeal a limited audience: given the entire group of FF users, the subset of filter authors, and the subset of those authors interested in monetizing their filters and market them as standalone Photoshop products. But it would be huge nevertheless, and – dare I to say – as one of them I'd be happy to pay good extra money to be able to use such a feature.

Leaving aside the actual implementation (no idea whether it would be technically hard or not) there could be licensing issues. E.g. an ill-disposed person could "borrow" one of the great, existing FF filters and make a commercial product out of it, violating the original author IP. A simple vetting system should be able to keep everything under control, and possibilities could be endless (purchasing filter export tickets that enable the exportation of a filter with a specified ID, sharing royalties between authors, etc).

Frankly, I was a bit surprised when I heard that the dev team already "thought about this years ago and decided not to do that" – maybe 2020 is a good year to think about it again smile:-)

Thanks for your attention and kind regards

Davide Barranca
  Details E-Mail
jffe
Posts: 2869
Filters: 90
I had the idea of just 'locking' filters from being opened/edited, so that people could sell them, back during V1. The idea was so that people couldn't just reverse engineer them, to protect the 'design' if you will. That never went anywhere, and this won't either.

Also, wouldn't the end user still need to buy FF ? It's not like they're going to let you export the whole program -inside- a filter ha-ha.

As it is, I'm pretty sure you are free to sell Filters if you want. The user would need FF to open them, but I'm not aware of any limitation on selling .ffxml files ?

jffe
Filter Forger
  Details E-Mail
Davide Barranca

Posts: 7
Quote
Also, wouldn't the end user still need to buy FF ? It's not like they're going to let you export the whole program -inside- a filter ha-ha.


Nope, that's the whole point.

FF is a filter library, filter player and filter editor; I (naively?) imagine that part of the software is devoted to displaying and connecting the various components on the canvas while creating a filter; part of the software is devoted to list and search through the filters library; part of the software is devoted to displaying the input controls that define the filter parameters and preview the effect. And finally, part of the software is devoted to run ffxml instruction through FF image processing engine on a file.

All the above (but the very last part) is totally unnecessary and can be shaved off, if just the image processing engine is to be exported/bundled with the ffxml instruction as a PS plugin.

If you're familiar with platforms such as Electron or Node-Webkit (now NW.js) well this is exactly the same idea. E.g. Electron (on top of which Microsoft has developed Visual Studio Code, Slack their desktop app, etc) lets you bundle a web application (e.g. the Visual Studio Code sourcecode) alongside with a browser context (Google Chromium) and Node.js that are used to run it.

Transpose that idea to FF and you have my feature request: "just" the FF image processing engine bundled as a binary PS plugin alongside with one ffxml. So why not.

Quote
As it is, I'm pretty sure you are free to sell Filters if you want.


That's not my point, I'm suggesting to export something that can be used independently – I think the Electron/NW.js analogy is spot-on.
Hope this clarifies!

Best,

Davide
  Details E-Mail

Join Our Community!

Filter Forge has a thriving, vibrant, knowledgeable user community. Feel free to join us and have fun!

33,712 Registered Users
+19 new in 30 days!

153,534 Posts
+31 new in 30 days!

15,348 Topics
+72 new in year!

Create an Account

Online Users Last minute:

26 unregistered users.