Filter Forge 3.0 and multiple image support

To implement support for multiple images, we're overhauling Filter Forge's control components. Previously, all our control components were uniform. Starting with version 3.0, they will be separated by type – there will be green (map) control components, gray (numeric?) control components and blue (curve) control components. This picture shows how map control components can be used to load multiple images into a bomber:

Issues and open problems:

1. We haven't yet decided on the method for storing references to Photoshop layers in filter's presets. The filename/path combo, obviously, won't apply here. Perhaps some hashed combination of layer name, document name and its dimensions will work, but we aren't yet familiar with the Photoshop CS5 plugin SDK, so we don't know if we have access to this information.

2. Separating control components into types may require changes in official Filter Forge terminology. The current term 'control components' conflates two characteristics – 'externality' (i.e. the ability of the component to expose something to the filter interface) and 'type neutrality' (i.e. the ability to be connected to an input of any color/type). I don't yet know if the old term will be appropriate for the new situation.

3. And finally, the most annoying issue – user interface for loading images into controls. The problem is that UI controls that represent the new Color Map and Grayscale Map green control components have different width. The color swatch is short, so we can easily add some kind of dropdown menu and display some info such as filename (as shown in the picture below), but the grayscale control is pretty long, in both its variants (LDR with a slider, and HDR with a spinner dial shown below), so it leaves us no space for any wide UI elements:

This soo good news

Quote
1. We haven't yet decided on the method for storing references to Photoshop layers in filter's presets. The filename/path combo, obviously, won't apply here. Perhaps some hashed combination of layer name, document name and its dimensions will work, but we aren't yet familiar with the Photoshop CS5 plugin SDK, so we don't know if we have access to this information.

In some PS plugins you have access to other layers (from the image), I think I saw this as early as in CS2. When FF runs as plugin, you could add a new menu item, 'Layers' in the input context menu, which expands to a sub menu containing the available (and compatible) layers.

As for storage of the layer information in preset: In general I'd say this has very little application, but then again if you're working on a larger composition and need to go back and readjust something in the FF filtering, it would be annoying that the layer input information is not stored.
Identifying the layers in the PS image should IMO not be related to layer content, size or index in the main layer composition in the PS image. I'm sure the SDK contain information about some sort of layer ID or handle you can use as reference.
When the layer (or image) is not available, you could show some sort of '*' or other passive indication of change (I assume FF will fall back to a solid color input).

Quote

2. Separating control components into types may require changes in official Filter Forge terminology. The current term 'control components' conflates two characteristics – 'externality' (i.e. the ability of the component to expose something to the filter interface) and 'type neutrality' (i.e. the ability to be connected to an input of any color/type). I don't yet know if the old term will be appropriate for the new situation.

I am very excited about this change. The lim itation of the static gray controls is a very annoying aspect. As I think of it, controls and components in "External" category really are the same sort of user->filter communication entities. Will you be keeping the old "constant" controls along with the new additions or will you go fully procedural on all input types in FF3?
If you still keep up that distinction, I'd say the new map "controls" belong in the External category, along with other components that use external input some way or the other.

Quote

3. And finally, the most annoying issue – user interface for loading images into controls. The problem is that UI controls that represent the new Color Map and Grayscale Map green control components have different width. The color swatch is short, so we can easily add some kind of dropdown menu and display some info such as filename (as shown in the picture below), but the grayscale control is pretty long, in both its variants (LDR with a slider, and HDR with a spinner dial shown below), so it leaves us no space for any wide UI elements:

Hmm, I'm not sure I see the real problem here - the arrangement in the two first screenshots (large ones), look good - as long as you just keep the right alignment. When a grayscale input (HDR or not) is mapped with an image or layer, you don't have to show the slider, wheel and numerical input controls any more, so why is there a problem?

Quote
Sphinx. wrote: When a grayscale input (HDR or not) is mapped with an image or layer, you don't have to show the slider, wheel and numerical input controls any more, so why is there a problem?

You're right. I did a better mock-up that shows all kinds of controls in both mapped unmapped forms, and it looks decent so far.

When a control is unmapped, we'll show its native form with a menu triangle on the right. The color controls will be 'padded' to the right for better looks -- see 'Particle 3' in the pic below.

For all unmapped controls (HDR/LDR colors and HDR/LDR grayscales) we'll just show the thumbnail, the text (the name of the loaded image, layer or stock preview pic) and the menu triangle.

Clicking the thumbnail brings up the Previewer dialog that shows the loaded image in zoomable/pannable form (similarly to the main preview). Clicking the text bar opens one a Chooser dialog for stock previews and PS layers, and the standard OS file open dialog for loaded images.

Clicking the menu triangle always brings up the same menu.

(Whew. I think I'm done with this one. Thank you.)

can their be any wishlist again!

Quote
Vladimir Golovin wrote: Essentially, it works by allowing you to load images from files or Photoshop layers into color controls in the filter interface

what about stand-alone mode? cant import them one by one from 'load image'?

Quote
Vladimir Golovin wrote: 2. The images won't be embedded into the filter's .ffxml file. Instead, the filter will reference them via filename and path. The references to the images will be stored in filter presets.

wont this kill making the stand-alone freepacks?

Quote
Kraellin wrote: what about stand-alone mode? cant import them one by one from 'load image'?

In stand-alone mode, loading from Photoshop layers will be disabled, but you'll be able to load images from files.

Quote
Kraellin wrote: wont this kill making the stand-alone freepacks?

Uh, I don't see how. Could you elaborate?

Quote
..but like, all European and crap?

Hey! People are living there you know! LOL, yes its just a different standard - we use that in Denmark too. It is controlled by the OS.

Quote
Betis wrote: I meant the spinner only, it has '0,9', is it 0 and 9 or 0.9 but like, all European and crap?

It's just a screenshot made on a computer with Russian locale -- we use comma as a decimal separator instead of the period. Yes, it is controlled by the OS.

Quote
Crapadilla wrote: Looks great!

In the latest mock-up it looks even better -- we decided to widen the left sidebar to make room for the menu buttons instead of compacting the affected controls. However, now we have a dilemma -- the left sidebar in the Editor will become wider too but the new space will be left mostly unused. But we're going to implement it this way anyway.

Lots of great stuff in here! More than one image will really open things up, I'm really interested to see this in action.

Multiple preview images will be great, I'd be very happy if one of them was a normal map and maybe if one was a particle sheet you could put into bomber (so you could make a strong preset and it'd be real easy for people to drop in their own custom particle image).

The sidebar in the editor being wider would be cool for script editing

I got sad when you said winter because in southern hemisphere we just left winter. Then it clicked and I'm very happy

Quote
Indigo Ray wrote: Wooooah what V3? I feel like I just got V2!

Don't worry -- FF 3.0 is far from being done. We just decided to be a little less secretive about the development.

Quote
Vladimir Golovin wrote: Uh, I don't see how. Could you elaborate?

never mind. had a wrong idea in there for some reason.

Wow this looks great, maybe i will get some hate for saying this but i have chosen Genetica as my main app for textures because of the multiple image options it allows. Also because i really, really dislike the constant rendering FF always does (add a render button you click when ready to render instead).

I think all that would change with V3 if it allows multiple images and improves the workflow as i find FF way more powerful but i currently don't like the workflow as much, if improvements are made though i think FF is on to a winner with V3.

if you want quicker renders in FF, turn off anti-aliasing and in 'view' turn off 'actual size'. these two things will speed things up tremendously. there are also optimizing speed tricks which are covered both in the forums and in the wiki help pages. these can also help a great deal with speed. turning off ambient occlusion can (if it's being used) can also speed things up but can seriously change the look of the effct, too.

i sometimes go through other folk's filters and re-write them for speed. authors are usually more concerned with quality than speed. so, you can often tweak a filter and cut its render time a fair amount. authors shld take care of this since if i'm tweaking their filter for this reason i'll now be using the tweaked version and they wont get credit in the usage rating system FF, inc. uses to reward authors with HU (high usage) points.

Quote
James wrote: I dislike how i cannot just have a basic preview

Have you set your preview size to 'Reduced'?

in the editor, i like the auto-immediate rendering. why plug in 20 components and then hit a render button only to find out that you goofed at the fifth component. with auto-render on in the editor you see what is happening on the fly, and that's a good thing for constructing. but, i wouldnt mind an option for either way, both in the editor and out. options are good!

well, i have to say, you've won me over. just make it as options one can turn on and off as needed.

Quote
Vladimir Golovin wrote: There will be two green control components: Color Map and Grayscale Map – both are shown in the Editor screenshot above.

The Grayscale Map component looks confusing to me. The GUI mockup shows a constant numeric value, but it should really show grayscale image map, no?

Quote
IONclad wrote: As an interface designer I actually did a mockup for V3 last week.

Would you mind sharing it here?

And the same function in the Filter Editor:

This is massively awesome. It also means that the output image will no longer be forced to be the same size as the input image. Thus, in theory: actual rescaling of the images could be made possible and you could make large images from small images (or vice versa).