drifting

I intend to divide a real time video from webcam 1024 times. (32 by 32 mosaic). Each mosaic is the video itself played live and the overall look of the mosaic is also the video. See attached pic from a screen shot. I am able to use jit.scissors and jit. matrix and jit.brcosa to divide the real time video, calculate the value in each mosaic and apply it to the overall video.

The problem is that I got an over complicated patch. It is able to make part of the video a mosaic effect but it to the limit the if I add more mosaic (jit.scissors and jit. matrix and jit.brcosa combinations), Max/msp program always automatically quit. And the memory of my computer is extremely low. I tried on 8 core, 8gb ram iMac. In attached picture 5.jpg, you can tell how complicated the patch is.

Here is what I am trying to do.
I intend to divide a real time video from webcam 1024 times. (32 by 32 mosaic). Each mosaic is the video itself played live and the overall look of the mosaic is also the video. See attached pic from a screen shot. I am able to use jit.scissors and jit. matrix and jit.brcosa to divide the real time video, calculate the value in each mosaic and apply it to the overall video. 

The problem is that I got an over complicated patch. It is able to make part of the video a mosaic effect but it to the limit the if I add more mosaic (jit.scissors and jit. matrix and jit.brcosa combinations), Max/msp program always automatically quit. And the memory of my computer is extremely low. I tried on 8 core, 8gb ram iMac. In attached picture 5.jpg, you can tell how complicated the patch is. 

how-to-make-my-patch-simpler

The jit.scissors and jit. matrix and jit.brcosa segment is actually very straight patches, see attachment. It is just the same segment is applied to all 1024 jit.matrix of the mosaic. Is there any other way to do this?

The jit.scissors and jit. matrix and jit.brcosa segment is actually very straight patches, see attachment. It is just the same segment is applied to all 1024 jit.matrix of the mosaic. Is there any other way to do this?
Thanks a lot.

wow, heavy copy pasting going on there :)

dissect it and you will gain many XP points at matrix manipulation.

https://cycling74.com/tutorials/jitter-recipes-book-3/

wow, heavy copy pasting going on there :)
take a look at tinyvideo example.
dissect it and you will gain many XP points at matrix manipulation. 

https://cycling74.com/tutorials/jitter-recipes-book-3/
Recipe 36: TinyVideo


man, I hope you had max toolbox to help you with the patch cord connections!

you likely can streamline some of your processes and still get the effect you want---for example, I don't think you need [jit.iter], there's probably a way to do it all at once. that alone is bogging things down tremendously I'm sure.

a smaller time-saver (but a good one for computers in general)---never divide when you can multiply, so swap your [/ 255] for the reciprocal, and multiply instead. Paste Replace is your friend here...

@seejayjames i'm pretty new to maxtoolbox...

that's a good one, not sure of others. it takes a bit to get used to and there's no undo, so that's something to remember about it. however you can get pretty darn quick with patching once you get the hang of the shortcut keys :)

Thanks all. you guys are genius. This is a project for a beginner Max/Msp class I took. thanks for all the suggestions. I definitely will look into them, I knew there is some way to make it simpler.

Thanks all. you guys are genius. This is a project for a beginner Max/Msp class I took. thanks for all the suggestions. I definitely will look into them, I knew there is some way to make it simpler.
I was a copy/paste maniac.


@seejayjames if I do not dissect the video, how do I know the average value and apply it to each mosaic video? or I am totally missing some easier ways to do this?

I'm no jitter expert but I think if you reduce the resolution of the original matrix by putting it into another 32*32 matrix it automatically will give you the average of each pixel of your new 32*32 matrix, and then just iterate through each element of the reduced version....?? something like that

I'm no jitter expert but I think if you reduce the resolution of the original  matrix by putting it into another 32*32 matrix it automatically will give you the average of each pixel of your new 32*32 matrix, and then just iterate through each element of the reduced version....?? something like that


exactly, put it into a 32 * 32 and use whichever plane(s) you want to get the brightness value, or run through [jit.rgb2luma] to get the luminance. Then you can use each pixel to multiply by each chopped video in the mosaic. In fact you could use jit.glue to attach everything back together in the big video, then use jit.op @op * and multiply by the "luminance matrix", which would do it all at once.

Lots of ways to simplify the "stepping through" of the luminance pixels if you go that route, you might try using send/receives with [prepend] and index numbers instead of patch cords, look to [patcherargs] or use abstractions with arguments, try [jit.spill] to go row by row, etc. 32 * 32 is a lot of iterating, so it might be a good opportunity to try these other techniques and show off to the rest of the class ;-)

OK, it's even simpler than that, if all you want is to mosaic the original video, you can just use the zoom of [jit.rota]:

jit.rota @x_zoom 0.03125 @y_zoom 0.03125 @boundmode 2

0.03125 = 1 / 32, so that will zoom out x and y by a factor of 32, and boundmode 2 will ensure that the image repeats.

original matrix-->32 * 32 matrix-->jit.rgb2luma-->jit.op @op *

to make the overall luminance affect each square, you're multiplying the luma-matrix by the original full-sized one (which has been zoomed out already).

Tweak the x_zoom and y_zoom to suit...you can easily change the 32 * 32 matrix to be a new size, and tie it (or not) to the zoom factors...some really fun stuff there. To tie it, run (for example) 32 through [!/ 1.] to get the reciprocal, which you need for the zoom factor.

And it will definitely not freeze the machine---this is tons less computation. So you have more CPU for other fun effects...!

original matrix-->32 * 32 matrix-->jit.rgb2luma-->jit.op @op * 

And it will definitely not freeze the machine---this is tons less computation. So you have more CPU for other fun effects...!


Does anyone got that patch? would love to try and experiment on it!

this is an implementation as described in the previous post by seejay, but without the rgbtoluma step:

the matrix from the 2 sources are never really aligned (see screenshot) .

the matrix from the 2 sources are never really aligned (see screenshot) .
Any idea how to get ride of this?

How to make my patch simpler