Filter Forge and the notion of a Project

As a historical accident, the current Filter Forge is built around the notion of filter. After all, it was conceived in early 2000s, the heyday of Photoshop filters, after the success of Kai’s Power Tools. It was easier to ‘sell’ the concept of Filter Forge to the public: one filter to rule them all.

However, for me, and probably for many of you, the real purpose of Filter Forge is to build not just universal filters, but specific bitmaps and sets of bitmaps, with resolution and other parameters known in advance.

So let’s explore a Filter Forge specific notion for a project: it’s a task that involves resources (bitmaps for inputs), filters, chains (or even trees?) of filters, and export bitmaps, of different resolutions and settings. In this concept, a filter is just a part of the project, along with all these resources. A project may include one or more filters, which may be universal / reusable or they may be intended to be used only within this project. (a filter that works as intended only on some resolutions or background images doesn't make much sense as a filter per se, but it may make perfect sense as a part of a project).

I was particularly impressed by the implementation this concept in Sketch, a trending vector design app, basically an Adobe Illustrator made for 2016, not for 1996. It offers Artboards (basically vector sub-documents-in-a-document) and Pages to organize them. I recently commissioned UI design for a mobile app for a hobby business of mine, and the designer managed to pack the entire design -- about a dozen screens, each with a dozen states and variants, plus multiple separate UI elements -- into a single Sketch file.

The second obvious implementation of the concept of a project is Microsoft Visual Studio and similar IDEs: source files, resources, build config etc.

So, I’d like to ask you:
1. Do you feel that this notion of a project is relevant to your workflow?
2. Would you like to see it implemented in Filter Forge?
3. Would you be willing to sacrifice some convenience of the traditional FF workflow for this?
4. What are project items? Filters, embedded images etc.?
5. What's your typical project? An image with particular dimensions and contents? A filter? A set of textures?

In general, what are your thoughts on this?

Edit: I reflected on this for a while and now I think that this is a central question, the single most important question that can be raised about an app. What does an app do? What the app enables you to do? What’s its output? How does the app facilitate this output? These questions are at the core of the identity of Filter Forge, or, more likely, its successor.

I now think that the notion of a project is one of the pillars of the future Filter Forge sequel (the other two being Turing-completeness and GPU support).

And there’s another question: considering the concept of projects, how does Filter Forge, as a tool, fit into art pipelines? How does it accept stuff at its input and produces stuff at its output? Note to self: see UNIX philosophy. Also: Project = directory of files?

Also, in light of all this, what is the new central concept of Future Filter Forge? For example, Filter Forge has filters and a filter library, but what would its successor have in place of it? Projects and project library?

Quote

Vladimir Golovin wrote: So let’s explore a Filter Forge specific notion for a project: it’s a task that involves resources (bitmaps for inputs), filters, chains (or even trees?) of filters, and export bitmaps, of different resolutions and settings. In this concept, a filter is just a part of the project, along with all these resources. A project may include one or more filters, which may be universal / reusable or they may be intended to be used only within this project. (a filter that works as intended only on some resolutions or background images doesn't make much sense as a filter per se, but it may make perfect sense as a part of a project).

This makes me wish FF was a plugin for Nuke, because that's exactly how I'd envision a "project" workflow for it... node-based, fully animateable, with the FF part being "render" nodes in the graph that call specific filters/presets. In this vision, an FF project would simply be a Nuke script.

Essentially, I envision the FF project workflow as an FF renderer "encapsulated" within a compositing-app like environment. Read nodes would be your resources, write nodes your outputs. You could chain filters (i.e. FF renderer nodes) in any arbitrary way, and reproduce the "procedure" thus defined for multiple time-varying media inputs. Of course, this would mean that the workspace "surrounding" the FF renderer nodes will require basic compositing functionality, masking, color corrections, etc. Luckily, FF already has many of these... inside the Filter Editor.

If we take this one step further and imagine a Project Editor that is functionally/visually identical (mostly) to the Filter Editor, a Filter would just be a seamlessly explorable Group component in that Project Editor workspace.

One could imagine that most components would still be available in that new top-level workspace, but interactivity would suffer if too many complex filters were chained together. There would certainly have to be some way of "caching" intermediate filter results for this to be viable.

Also, we would need a new breed of Resource (i.e. read & write) components that actually "remember" their file sources and destinations. Furthermore, one could imagine that this top-level workspace provided animation functionality (i.e. a timeline) and batch render capability.

However, FF does not provide many standard compositing app functions like painting, spline-based masking, etc, so it would be a looooooong way to make that Project Editor feature-complete. IMHO, FF would be better served if it opened itself up for integration into standard compositing applications.

Quote
Skybase wrote: I think this is what Crapadilla's trying to describe but more nuke-like?

Yes. Essentially, a "project" in FF could be such a node graph, defining successive filter operations on one or several input images.

An FF "project" would enable users to...

1. make any complex sequence of filter operations repeatable, so that it can modified later or be re-used on different images or sequences of images.
2. composite and post-process the results of different filters.
3. provide a node-graph-based 'record' of creative filter explorations (like a macro-recorder, but in node-graph form).
4. batch process images or sequences of images.
5. animate filter parameters over time to create animations.

In conclusion, the introduction of a "projects" system to FF could bring with it the realization of several long-standing feature requests, so it is certainly interesting to discuss this notion.

Well, provided that "project" system came in the form of a new 'top-level' node-graph layer that is sitting 'above' the current Filter Editor's top layer (as described above with my Nuke plugin idea), then that system could mimic/duplicate functionality seen in compositing systems.

This system could make possible the following feature requests:

- Using the result of a filter as the input to another filter.
- Post-process a filter result.
- Composite multiple filter results.
- In essence, this provides an elegant solution to the inelegant workflow of having to load a filter result as the current image to do additional processing on it.

With the addition of a timeline, additional features would become possible:

- Processing of image sequences.
- Animation of filter parameters.

Just wanted to chime in and say this is a very interesting topic and I am siding heavily with Dilla here on his ideas.

Quote
Skybase wrote: I usually think of FilterForge as more like a "go-to toolbox"

Quote
Crapadilla wrote: Obviously, this kind of "project system" is still limited in appeal due to FF's specialization on pure proceduralism - it does not provide paint or vector capability.

I agree with both, and I can say that FF (and FF sequel) will stay true to its roots - I don't think we'll venture into painting or vector editing. I just need to come up with better examples of what I meant by 'project'.

I agree with 'dilla:

-1. Do you feel that this notion of a project is relevant to your workflow?
NO. Filter Forge is just one of several tools I use. And they are wildly diverse. I don't see FF being able to bridge all those things in a relevant way.

-2. Would you like to see it implemented in Filter Forge?
NO. I'd much rather see simple BATCHING / ANIMATION and BATCH SAVING OF MAPS (diffuse map, normal map, etc). Those things would have a major improvement on my workflow, and make FF relevant to a whole bunch of other activities.

-3. Would you be willing to sacrifice some convenience of the traditional FF workflow for this?
Emphatically no.

-4. What are project items? Filters, embedded images etc.?
Images(mostly .PNG, AI, and PSD), 3d models, video files, occasionally an Adobe Color Palette file.

-5. What's your typical project? An image with particular dimensions and contents? A filter? A set of textures?
Oh man... a whole computer game worth of varied assets. Typically textures are around 512x512, but as large as 8k wide for geography. Some of them are unique, but many of them are variations on a theme. But they could be a group anywhere from 4 or 5 to several hundred.

-In general, what are your thoughts on this?
I'm glad you are thinking about our workflow. But, as stated above, I'd really rather have you improve the core function of making images, and saving them by (BATCHING / simple ANIMATION and BATCH SAVING OF MAPS)

A little bit more on why this matters:

BATCHING / simple ANIMATION Simply being able to batch a series of steps, using a set of curves, would be a huge benefit. It means that I could just say 'go from preset x to preset y' and 'use this curve'. This would be good for making animations, but also just creating content in a series, like a series of 10 textures that have have one color pattern, then do 10 more with another. Totte's external batch tool is not good enough by itself. There needs to be a UI for it; I shouldn't have to code to do a simple batch.

I mean, not to put to fine a point on it: FWIW Genetica's implementation looks pretty good:
http://spiralgraphics.biz/genetica/he...mation.htm





I would much rather be able to do this sort of thing in FF, and not have to deal with AE or anything else. I've had to cobble together workflows using a series of base images, and then batch-run FF on them. But...not ideal.

BATCH SAVE MAPS
Many people have asked about this, and it is a standard feature in almost every 3d application, that I'm not sure why it isn't already in Filter Forge. Not having it really makes FF less useful for me. SRSLY.

Another workflow issue for me is:
SELF ILLUMINATION MAP
Again, this is an interoperability thing. Right now, I've been jerry-rigging this in FF, all behind a switch. It would be great to have this work in FF like all the other programs, and be able to influence lighting.

Sorry if I sound whiny ... I feel like FF is really close to being an awesome image automation tool / production tool. But it needs some of the of these key workflow pain points solved.

(A side note: animation scares me. Mostly because animation is not just user-defined parameter curves combined with the ability of batch processing image sequences. I think I'm mostly afraid of temporal anti-aliasing, no matter stochastic or not. It's trivial to implement for floating-point parameters, but how do I implement it for checkbox / intslider parameters?)

(Or can I leave this to users, who will just render a 5x longer frame sequence then compress it into 1x time using their video editing tools? That would allow them to emulate non-stochastic temporal supersampling. Will that be enough?)

Quote
Vladimir Golovin wrote: (A side note: animation scares me. Mostly because animation is not just user-defined parameter curves combined with the ability of batch processing image sequences. I think I'm mostly afraid of temporal anti-aliasing, no matter stochastic or not. It's trivial to implement for floating-point parameters, but how do I implement it for checkbox / intslider parameters?)

Didn't mean to imply that implementing animation would be trivial, but merely that it is something that FF should have, and that it should be taken into consideration when laying the foundations of FF's successor.

(Speaking of the notion of a project - I think I have an idea how to explain it visually, with an infographic. Now, if only I could get my daughter to draw me a pony and some nice hand-drawn particles for the fairy dust.)

Yup. Seen it. This is great news!