Forums > Jitter

blending modes (like photoshop) in jitter?

May 21, 2007 | 3:01 pm

Can anyone point me in the right direction for any jitter objects that
can duplicate the transparency and masking effects with Photoshop and
After Effects’s blending Modes?

Any thoughts or referrals would be really appreciated.

Many thanks in advance! Robert.


May 21, 2007 | 3:20 pm

jit.gl.slab. Have a look in the c74/jitter-shaders/composite folder.
There’s even a nify example patch in the
examples/jitter/render/slab-helpers folder.

wes

On 5/21/07, Robert Griffin Byron wrote:
> Can anyone point me in the right direction for any jitter objects that
> can duplicate the transparency and masking effects with Photoshop and
> After Effects’s blending Modes?
>
> Any thoughts or referrals would be really appreciated.
>
> Many thanks in advance! Robert.
>


May 21, 2007 | 3:36 pm

Hello,

Cycling’74 people(also part time wall painters), made it incredibly
easy for us:
checkout jit.gl.slab-composite patch in jitter examples folder.

best,
nesa


May 22, 2007 | 4:52 am

has anyone implemented an object which does this on matrices which is compatible with the latest jitter? i know that the auv-i library has objects that do this, but hasn’t been made friendly with recent jitter versions.

thanks!
m


May 22, 2007 | 9:03 am

Quote: Mark H. wrote on Tue, 22 May 2007 06:52
—————————————————-
> has anyone implemented an object which does this on matrices which is compatible with the latest jitter? i know that the auv-i library has objects that do this, but hasn’t been made friendly with recent jitter versions.
>
> thanks!
> m
—————————————————-

How about this? Wesley, could you explain why this works? Is the texture automatically captured back to ram?

Mattijs

(note, there is a loadbang inside)

#P newex 31 376 48 196617 loadbang;
#P newex 33 283 55 196617 jit.matrix;
#P user jit.pwindow 32 304 82 62 0 1 0 0 1 0;
#P user ubumenu 119 200 100 196617 0 1 1 0;
#X add additive;
#X add average;
#X add brightlight;
#X add burn;
#X add darken;
#X add difference;
#X add dodge;
#X add exclude;
#X add freeze;
#X add glow;
#X add hardlight;
#X add heat;
#X add inverse;
#X add lighten;
#X add multiply;
#X add negate;
#X add overlay;
#X add reflect;
#X add screen;
#X add softlight;
#X add stamp;
#X add subtractive;
#X prefix_set 0 0 0;
#X pattrmode 1;
#P newex 164 225 111 196617 sprintf read co.%s.jxs;
#P message 437 85 79 196617 read dozer.mov;
#P message 342 85 28 196617 read;
#P message 407 85 27 196617 stop;
#P message 373 85 31 196617 start;
#P toggle 279 66 15 0;
#P newex 279 85 55 196617 metro 20;
#P newex 279 117 104 196617 jit.qt.movie 320 240;
#P comment 295 66 149 196617 • read a movie and start metro.;
#P flonum 282 204 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 282 226 85 196617 param amount $1;
#P message 191 85 79 196617 read dozer.mov;
#P message 96 85 28 196617 read;
#P message 161 85 27 196617 stop;
#P message 127 85 31 196617 start;
#P toggle 33 66 15 0;
#P newex 33 85 55 196617 metro 20;
#P newex 33 117 104 196617 jit.qt.movie 320 240;
#P comment 49 66 149 196617 • read a movie and start metro.;
#P newex 33 262 69 196617 jit.gl.slab foo;
#P newex 31 418 145 196617 jit.window foo @depthbuffer 1;
#P newex 31 396 80 196617 jit.gl.render foo;
#P connect 12 0 11 0;
#P fasten 15 0 14 0 284 111 284 111;
#P fasten 19 0 14 0 347 111 284 111;
#P fasten 18 0 14 0 412 111 284 111;
#P fasten 17 0 14 0 378 111 284 111;
#P fasten 20 0 14 0 442 111 284 111;
#P connect 16 0 15 0;
#P connect 22 1 21 0;
#P fasten 14 0 2 1 284 179 97 179;
#P connect 24 0 23 0;
#P connect 2 0 24 0;
#P fasten 21 0 2 0 169 253 38 253;
#P fasten 11 0 2 0 287 253 38 253;
#P connect 4 0 2 0;
#P fasten 10 0 4 0 196 111 38 111;
#P fasten 7 0 4 0 132 111 38 111;
#P fasten 8 0 4 0 166 111 38 111;
#P fasten 9 0 4 0 101 111 38 111;
#P fasten 5 0 4 0 38 111 38 111;
#P connect 6 0 5 0;
#P connect 25 0 0 0;


May 22, 2007 | 9:33 am

yes, that’s one way to do it, my concern here is the brief hiccup when changing the blend modes, at least that’s the case on this machine. however, i am running max 4.5.7 and jitter 1.5.2. does the brief hiccup occur with more recent versions of jitter? the other concern is widespread use of this .jxs could overly burden the GPU which i’d like to reserve for other tasks. are these reasonable concerns? i’m new to the glsl/gpu world and am just beginning to integrate it into my video work. my habits want me to find a CPU method of resolving this issue for maximum flexibility. any other possiblities out there?

macbook pro 2.33 ghz

mark.


May 22, 2007 | 9:38 pm

On May 22, 2007, at 2:33 AM, mah wrote:

> my habits want me to find a CPU method of resolving this issue for
> maximum flexibility. any other possiblities out there?

GPU version will be way faster, but I decided it was about time to
make an example of how to do this stuff with a combination of
primitive Jitter operators on the CPU. Everything done here could
also be done in a set of patchers, but I found it easier to manage in
JS. A dedicated object in C wouldn’t be that hard to write, and would
be faster (though not as fast as GPU), but this example shows a
variety of tricks for the not so C savvy, or those that wish to
prototype in JS before coding up in C.

It’s not rigorously tested, but I compared with the JXS variants, and
it’s pretty much the same except for a few places where there’s
resolution issues with 8bit data. It should work for both floating
point and char data, but I also haven’t tested on floating point data.

The trickier parts of it were dealing with division (the blendmodes
which require this are slow since we have to convert to floating
point using jit.expr to get the type of division desired for this
task), and the luminance based logic of the hardlight and overlay
blendmodes.

http://www.cycling74.com/download/jkc/jsblendmode.zip

Hope someone finds this sort of thing useful.

-Joshua


May 22, 2007 | 9:49 pm

Hi Mattijs,
your patch works because the loadbang builds a render context in
jit.gl.render enabling jit.gl.slab to do RTT stuff internally and
shoot it back to a matrix. When using RTT, you’re basically creating
a context within a context, so jit.gl.slab has a context within itself
(which is actually in the out_texture) that is uses to do the fragment
processing.

wes


May 22, 2007 | 10:03 pm

How does the FBO backend deal with @context and render to texturing?

I wonder if that is partially why I get so many texture binding
errors is because of one backend vs the other.

How do I query what backend is in use? is RTT the default?

On May 22, 2007, at 5:49 PM, Wesley Smith wrote:

> Hi Mattijs,
> your patch works because the loadbang builds a render context in
> jit.gl.render enabling jit.gl.slab to do RTT stuff internally and
> shoot it back to a matrix. When using RTT, you’re basically creating
> a context within a context, so jit.gl.slab has a context within itself
> (which is actually in the out_texture) that is uses to do the fragment
> processing.
>
> wes

v a d e //

http://www.vade.info
abstrakt.vade.info


May 22, 2007 | 10:14 pm

what does @context refer to. rtt is default, by RTT i meant render to
texture in general, not a specific implementation.

wes

On 5/22/07, vade wrote:
> How does the FBO backend deal with @context and render to texturing?
>
> I wonder if that is partially why I get so many texture binding errors is
> because of one backend vs the other.
>
> How do I query what backend is in use? is RTT the default?
>
>
>
> On May 22, 2007, at 5:49 PM, Wesley Smith wrote:
>
> Hi Mattijs,
> your patch works because the loadbang builds a render context in
> jit.gl.render enabling jit.gl.slab to do RTT stuff internally and
> shoot it back to a matrix. When using RTT, you’re basically creating
> a context within a context, so jit.gl.slab has a context within itself
> (which is actually in the out_texture) that is uses to do the fragment
> processing.
>
> wes
>
> v a d e //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>
>
>
>


Viewing 10 posts - 1 through 10 (of 10 total)