the External Image component

along with being able to have more than one image open in a filter or in the filter workspace, i'd also like to be able to embed an image as part of the filter so that it's a permanent part of the filter.

but, the real reason for this post is the more i play with the image component, the more i want to be able to input INTO it, not just have it with an output node.

a lot of the filters being made seem to be texture type filters and that's fine, but i notice most of them dont use the image component at all. for me, as an artist, i want to see the textures on a given image within FF and not just when i import back to photoshop or psp. so, i use the image component a lot. however, when i was working with it last night, i kept thinking something was missing. i wanted to make a filter where i altered the image at its base; i kept wanting to plug other components into the image component and have it altered directly, not just with a blend. i wanted the inputted other components to alter things based on the plugged in component.

let me see if i can think of an example. if you take the noise distortion, this one doesnt matter much that you can only plug the image into it and not the other way around, but on something like the 5 color gradient, this makes a difference. if you plug the image comp into the 5 color gradient comp color nodes, you get the image itself or that part of it corresponding to the image position its plugged into. but, if you did it the other way around and could plug the 5 color gradient into the image, i would think this would be quite different...if you could do it. i would think you'd get something like a banding of the 5 color gradient into the image keeping the image but altering the colors based on the 5 color gradient.

another example might be the various tile components, though maybe not the kalaeidescope one. if i plug the image comp into a tile comp i get the image divided into the various tile shapes with the mortar lines showing as themselves but the image showing in the individual tiles. now, in my imagination, this would be different if you could plug the tiles comps into the image comp. i would think you'd get an alteration of the image based on the tile's shape. so, it would tend to act like a warp filter.

notably, this really wouldnt matter with a number of the components. things like hue/sat, sharpen, gamma and others wouldnt have any effect. but on some, like most of the gradients and maybe the tiles, i would think this would make a big difference.

this is mostly a low priority item for me.

craig

4. Can lead to copyright problems.
5. Leads to a mandatory pre-approval of submited filters because of possible inclusion of pornography and similar offending materials.

yes, i realized before posting that embedding images as part of the filter would probably be shot down. didnt know some of the reasons, but was certainly aware of file size issues and copyrights. so, wasnt really expecting a 'hey, good idea' on this one

still, i think there is something to this. things like clip art, stock designs and images and so on might be useful in the creation of some filters. and even if the image couldnt be uploaded to the filter library, if the capability existed within the workspace, one could embed a personal image for one's own use. of course, that then begs the question, 'well, just load your image when you use the filter. why embed it?'. i guess what i'm thinking here is embedding coupled with multiple image capability such that one image was always loaded in the filter and another was added by the user. but again, if multi-image existed then it still begs the same question, i suppose. just load the images you wanted.

i'm quickly talking myself out of this thing... ok, let me take this further. the embedded image would be embedded not as a generic, global, but rather specific to one component and ONLY that one component (unless otherwise specified by the user). so, you might have an external 'image' component that had one picture in it and another of the same component with a different image attached to it.

hmmm, still not even making sense to me... let me give an example. let's say in mike's chain link fence filter he wanted to simplify this but still get the same results. if it were possible to load a cheater image, one that is already close to being a chain link fence or a portion of such, wouldnt it be simpler and thus less taxing on resources, to produce his end result? in fact, mike's excellent filters are exactly the kind of thing i'm thinking of here. his crate filter or barbed wire filters also fit this. in other words, the embedded image would act as a seeder to seed the final result. and as such would be an integral part of that filter's effect. and really, the only way others could then use this filter correctly would then be if they had the 'seeder' image or if it was part of the filter itself.

ok, does that make sense?

and even if it does make sense, i do understand the other objections so this post is more of a theoretical, what if and could it be done type of post.

Quote
Vladimir Golovin wrote: You can easily do that by plugging both the Gradient and Image into Blend and setting the blend mode to Color or Luminocity.

vlad, i'll play with those some more and see if this is what i was looking for.

and as for the second thing you mentioned with offset and distortion, i guess what i'm saying or looking for here goes along with the first part of this post; i'm trying to make the 'image' component my 'seeder' but more directly than what currently exists. actually, i suppose what i'm after is more of the image being the effect of other seeders. if we look at simple cause and effect, the image component is currently set to being 'cause'. you input it into other components. what i'm looking at is making the image component 'effect' such that other components would feed into it and thus alter it accordingly. i'll have to play with this some more based on what you posted and see if this isnt anything more than just a way of looking at the workflow rather than an actual change in function.

thanks guys.

craig

onyx,

thank you for imparting that. i certainly have no objection as a user to having the embedded ones disabled from upload, much like the duplicate presets will keep a filter from being uploaded. that seems easy enough. if you also wanted to make some sort of restricted or trusted vehicle for doing so, that would also be good.

since FF already has the capability of transferring the xml files as individual files so that others can download them separate from the filter library, that would keep FF Inc. free from any liability shld someone indeed make some violation or objectionable embed. but at the same time it would allow users to use those files and share those files that did have the embeds. they'd just have to do it not through the library. i think as a quick fix that would work well. and if later you added a 'trusted' system, then all the better.

vlad, i know you're watching out for the whole complexity issue and frankly, i'm glad you are. i mean, otherwise FF could have just been another filter factory or filter meister where we'd all need to learn code... and i dont know code. it's got to be a bit of a trick to see the power of FF and at the same time try to keep it all within an interface that anyone can learn.

compared to byRo and Mike i'm a complete novice. i do have some understanding of how things work, but not to their level. i'm more of a 'let's plug this into that and see what it looks like' and then, if i like it, i bundle it all up and submit it. and the nice thing is, in doing that, i do learn. so, i guess what i'm saying here is, if i can see a need for some of this stuff, users buying the product are also going to see it, whether they are a 'byRo/Mike' or a 'Kraellin'.

if i'd never seen photoshop cs2 before and someone handed it to me and said, 'ok, go to town'. well, i'd barely know where to start. i might learn a little about brushes and a few other simple things to start with and maybe graduate to clone and smudge. and i may not ever learn it all, but if adobe had said 'well, we're not going to add clone; it's too complex. we'll scare the customers away.' i like to think you might agree that would have been a shame.

sorry, i guess i'm argueing on a preemptive strike basis here based on past experience.

oh, and on that other issue about the image component, i've been testing it out. i'm afraid i got a bit sidetracked, however, since one of the things you suggested turned out to have some interesting, albeit, off-topic effects. so, i'm still testing

craig