Other Interesting Ideas

Seems like I have more ideas than I'll ever have time to try, so I better write them down somewhere in case someone else has use for them.

Multi-pass filters

These are filters that have two or more "modes" (switched by a checkbox or selector), that first generate a starting image or an intermediate image and on the next application generate either the next step or the final image.

Example: Etch-A-Sketch. First application "shake mode" would draw the Etch-A-Sketch and one line. Subsequent application in "draw mode" would draw one more line each time without altering the image otherwise, just adding a line each time. Line beginning and end would be controlled by sliders.

Storing and retrieving information from image

For multi-pass filters, you might want to be able to store information that will be used in the next pass. Using the same Etch-A-Sketch example, you might want to store the x and y coordinates of where the last line ended so you can use it as the beginning coordinates of the next line in the next pass.

There are a couple of ways of doing this. They are based on embedding a couple of pixels that represent the number (0=black, 100=white). A rather neat way would be to use an area that is transparent, so as to hide the pixels from view altogether. For instance, in the Etch-A-Sketch filter, the four corners are transparent. You could store the values there in the RGB channels and retrieve them from there.

As this may not be enough of an explanation, the method to get the stored numbers back out and into use involves enlarging those pixels to cover the entire image area. Then you can use them in any green component input.

Other uses for transparency

Or you can store a whole bunch of information temporarily as transparency. Let's say you want to modify a height map over a number of passes of a filter. You could do a Set Alpha to temporarily use the transparency of the image to store the height map and Get Alpha in the next pass to retrieve it. Since FF does not remove any of the RGB information during this operation, it is non-destructive and can be used as many times as you want.

Boolean Logic

The easiest way to implement "IF ____( AND/OR/XOR ____) THEN" functionality into a filter is to use black and white to represent FALSE and TRUE. Then you can do blends to make boolean logic decisions. Blend modes work as follows:

Maximum = OR
Minimum = AND
Difference = XOR

Then you can use the result as opacity in another blend.

Okay, that may be difficult to comprehend. Here's two examples:

Say you only want to flip an image IF the center pixel is lighter than 50%. Okay, you would enlarge the center pixel to cover the entire image and threshold it at 50. Then you would use the outcome (which is basically TRUE or FALSE) as the opacity in a blend in which Background is flipped and Foreground isn't.

Follow?

Second example: You only want to flip an image IF the center pixel is lighter than 50% AND the transparency of the center pixel is less than 75. In this case, you would do the same with the threshold. Then you would do a similar operation on the transparency (Get alpha, enlarge to cover whole image, threshold at 75). Now you have two outputs, one which tells you whether the center pixel is lighter than 50% (white or black for TRUE or FALSE) and another that tells you whether its transparency is less than 75 (TRUE or FALSE). You want them both to be true, so you blend them with minimum (boolean AND operation) and get TRUE or FALSE. Then feed this into the opacity of the flipped/non-flipped blend.

If you read the above many times enough and try it, I'm sure it will eventually make sense.

[Sorry, useless blabber was here -- I need to sleep more]

Boolean by depth

Not altogether a new idea, but I haven't seen it clearly pointed out elsewhere and definitely worth a special mention:



That's how I'll be constructing my 3D teapot...

Here's how it works:

Boolean Construction Technique.ffxml

Boolean Intersection

I just had to try it...







Boolean, intersect.ffxml

way the freak above my head. lol. but i still like looking

Quote
Kraellin wrote: way the freak above my head. lol. but i still like looking

"Boolean" is just a fancy mathematical word, the idea is really simple. When it comes to 3D objects, they are basically just three different things:

1) Combine objects together.

2) Subtract object(s) from another.

3) Use the space that is in common with two or more objects as new object(s).

Then you can call them "boolean operations" to make it sound real fancy. (George Boole was the mathematician that described these types of operations)

Saving multiple alpha channels in one file

As to what you would use them for, I leave it to your imagination. (Think for instance bump, transparency, diffusion, ambience, specularity, metallicity and reflectivity maps. Or making selections for separate objects in the image, rocks separate from sand, grass, twigs, etc.) Here's the theory.

You can of course create a filter that creates an alpha channel, say with a checkbox and a switch, and save it as an image and then later load it as a selection. Not a big deal. But what if you wanted to save more than one selection into one file?

You could save three alpha channels pretty easily by making each of them one of the RGB channels.

But for even more capacity, take a look at this: Filter Forge can save lossless images with 3 channels, 16 bits per channel. If you use 8 bits for full quality anti-aliasing, you can theoretically still have 3x8 = 24 "alpha channels" at photoshop quality for every image. But how would you store them in a single image?

By the upper 8 bits!

Okay, that is probably too technical an explanation, so let me rephrase that in other terms.

You could save one selection by making the alpha channel white 0/256 black and the alpha channel black 1/256 black in one of the RGB channels. You would have used one bit of image information.

Then you can save your second alpha channel in the same RGB channel by making white 0/256 black and black 2/256 black. When you add that to the existing image, you will have used 2 bits of image information. Yet the two alpha channels remain separatable out, for they fall in distinguishable black ranges.

The next alpha channel would be added to it with black at 4/256, the next one with black at 8/256, 16/256, 32/256, 64/256 and 128/256. At this point you would have used up one of the RGB channels storage capacity.

Thus, if you save the image in 16-bit format, you should be able to store up to 24 alpha channels in one image this way.

Separating them back out is a bit of a subject, too, but I'll return to it eventually, or if someone wants to try this.

Sounds good in theory, it'll have to be tested to see how it works out.

Separating objects by index number

Another idea for multi-stage image construction. Say you want to "build" and object but haven't decided what textures to apply to the different parts. How about assigning an index number to each of the parts and deciding later what texture to apply to each? It's like having separate modeling and texturing steps that anyone who has done 3D modeling is familiar with.

And how that would be possible is this:

With each separate "object" that is created, the filter can create a grayscale image that matches the objects with a certain flat gray value (again, checkbox-and-switch approach would work for rendering this out separately). I better make a picture here to show you what I mean. I'll use the same boolean image example.

Here is the diffuse color:



Here is the height/bump map:



And here is how the index channel could look:



You see how that could be used later? You could retrieve any one object out of that index image and assign a texture to it, then another object, assign a texture to it, etc. This could be done for example with the multiple-image-input workaround method.

But this would allow you to add, change and experiment with different textures altogether separately from object construction.

---

PS. The index channel idea could, BTW, be used as a simplified multi-selection storage method. It is limited in that you can't have overlapping selections, but could be useful for some purposes.

Custom shapes library

Thought of another use for saving multiple alpha channels in one image. You could make a custom shapes library that way. Think about it: 24 custom shapes in one file!

Didn't InfiniView or someone talk about some such thing?

Man, now I really want to try that idea out!

Okay, wasn't quite as easy as that, and probably will only work for 2-bit images, for you get the residue from the antialiasing of the other channel(s) in the lower end. Nevertheless, my first attempt came out fine with a bit of cleanup at the end (.1 blur and levels to clean up the residue).

Here's the 2-image packing example:



Pack alpha.ffxml

Quote

ThreeDee wrote: You could save three alpha channels pretty easily by making each of them one of the RGB channels. But for even more capacity, take a look at this: Filter Forge can save lossless images with 3 channels, 16 bits per channel. If you use 8 bits for full quality anti-aliasing, you can theoretically still have 3x8 = 24 "alpha channels" at photoshop quality for every image. But how would you store them in a single image? By the upper 8 bits!

We actually use the RGB multi-alpha channel trick in games. It works pretty well. All sort of inter-related data packed into an RGB layer. We've talked about breaking each layer into it's respective bits, but it's hard to work that way. Not to mention messy; It's very easy to get a little bit of anti-aliasing from one area into another area accidentally. I've tried separating it all off with pshop threshold layers, but it's hard to work that way and your work habits have to be pristine.

Clever idea for FF, though!

Importing font outlines into FF?

If you add a selection input to the above, you get 16 alpha channels.

Further, if you put, multi-image-input style, 4-up on each channel, you have 64 inputs -- or enough inputs to get the upper and lower case alphanumeric character outlines into FF.

Not that I can think of any sensible reason to do so, but maybe someone will -- or maybe I can come up with some nonsensical reason to do it anyways.

I was in the middle of another too-ridiculous-for-words filter but now I have to go to sleep. Not fair.

Here are couple of the ideas in action.



The image on the screen of the Etch-a-Sketch was drawn one line at a time in FF during several passes with the filter, "rotating the knobs" with two sliders.

You can see two small gray squares at the top corners; that is where the previous pass X and Y coordinates are stored and retrieved from.

Actually the biggest problem was figuring out how to draw lines between two points. It's not working correctly yet, for the lines disappear if they are drawn horizontally or vertically.

Plus, it is painfully slow to draw anything with it -- just like the real Etch-a-Sketch!

I think I have an idea for how to draw the lines easier.

Ah, steganography!

You could set it such that you have to know the correct variation # to decode!

Some techniques use the last 2 bits, ThreeDee:

http://en.wikipedia.org/wiki/Steganography

I give up -- it is impossible. You can probably only do it as a bitwise operation.

What important shading types and effects am I forgetting?

Quote
ThreeDee wrote: What important shading types and effects am I forgetting?

Ambient Occlusion (is sort of Deeper shadows, more contrast / casting shadows, but not exactly)

Quote
CorvusCroax wrote: Ambient Occlusion

This works.....to a certain extent.....

http://www.filterforge.com/filters/4517.html

Meanwhile, here's my first stab at a custom "surface filter" constructed as a simple filter. Got reflections, transparency, refractions and a (sort-of-a) lightsource. The blob represents an object. Or a blob.

Quote
CorvusCroax wrote: Ambient Occlusion

Quote
StevieJ wrote: This works.....to a certain extent..... http://www.filterforge.com/filters/4517.html Steve

Okay, I get the idea. The object itself occludes ambient lighting in its self-generated shadow areas. Like reverse radiosity.

Yes, I get what you mean.

I just realized the flaw in my logic with the idea of being able to store alpha channels in RGB. 16 bits isn't really any more than 2 times 8 bits, in terms of storage capacity -- duh! So with RGB, you could store a maximum of 6 alpha channels with 8-bit quality. But you could still store up to 24 1-bit alpha channels in an 8-bit RGB image, or 48 of them in a 16-bit image. At least theoretically.