blurring a float matrix?

    Feb 24 2012 | 1:20 am
    okay, so I may be losing my marbles completely here, but... how on earth do you blur a float32 matrix?
    jit.fastblur is char only, and the closest thing I've found is jit.avg4, which isn't really it either.
    My matrix is "mymatrixname 3 float32 100 100", so it's rather small, and I can afford to throw some processing at it, but I *cant* do shaders, since I need this in matrix-land still.
    any pointers? I reckon there might be a simple jit.pix hack I could do? I don't mind quirky blurs, either.

    • Feb 24 2012 | 2:08 am
      One way is simply to downsample and then re-upsample with interpolation, but the more sophisticated way is convolution with jit.convolve, I think.
    • Feb 25 2012 | 12:03 am
      thanks. I love how jit.convolve's help file AND reference assume that the jitter users know what convolving two matrices with each other entails. ;)
      I'll be using this, but damn, it ain't pretty.
    • Feb 26 2012 | 4:30 pm works pretty well also with float32 matrices, and it's great! :)
    • Feb 26 2012 | 10:46 pm
      i would use, and then go back from openGL to CPU...
    • Feb 26 2012 | 11:24 pm
      slab processing for a small matrix which is just a tiny bit of a larger whole? Am I completely nuts for thinking that that is too convoluted? (pardon the pun)
    • Feb 27 2012 | 12:13 am
      well it depends what kind of blurring you're after
    • Feb 27 2012 | 2:02 am
      well, I reckon what I'd really like is something like, but in matrix-land.
      Do any of you have this wrapped up in an abstraction that handles the back-and-forth from- and to- matrices internally?
    • Feb 27 2012 | 9:00 am
      it's not an abstraction but i hope it will help you anyway...
      PS: the rendering context is made with jit.window, which is a bit annoying - there is a "useless" window floating. for some unknown reasons, my Max crashes if i make the rendering context with jit.matrix...? anyway, all you have to do is to adjust the dimensions...
    • Feb 27 2012 | 10:14 am
    • Feb 27 2012 | 4:32 pm
      @napentro: Thanks, that is even sexyer solution! I removed also the videoplane and changed the "jit.pwindow @name maax" with "jit.matrix maax", to remove the unnecessary processing.
      PS: Creating rendering context with jit.matrix seems to work for smaller matrices. I remember I had problems with larger Max always crashed. And even few moments ago that happened with 320x240 matrix. I don't know what is the reason for that dodgy behavior...
    • Feb 27 2012 | 4:58 pm
      I played a little bit more with the patch and it seems that if creating rendering context with matrix, patch works slow and dodgy. Can anyone explain that?
    • Feb 27 2012 | 9:23 pm
      i think, that videoplane is nessesary. there is jitter tutorial 31RenderDestinations, that allows you to change the destination of opengl objects, but in my case when trying render to matrix pops up " invalid extension called" - maybe it is some kind of bug.
      anyway i think, that videoplane is nessesary to send the context of renderer anywhere.
      it is a modyfied version of the tutorial with " invalid extension called" error:
      if it would work the patch with rendering gl.slab to matrix should looks like that:
      or maybe i'am missing something @:) after all sorry for my english :)
    • Mar 01 2012 | 8:26 pm
      i don't get any errors in your first patch. also the last patch i posted (without videoplane) works. but as i said, it is dodgy. now, for instance, when i tested it again, it first didn't work, then my Max crashed, but after i restarted it, it started to work.
      i would expect that when i make the rendering context with matrix instead of window or pwindow, that the patch would run faster, since there is nothing (necessary) to display. but as i said, things start to crash, behave dodgy, works slow...???