structure of a quicktime movie / instant slitscan

    May 01 2011 | 2:32 pm
    Introduction: I'm experimenting with moving slitscans such as this movie on youtube (not mine). To create this, I've written several max/msp programs while researching this. They are are based on non-realtime processes but it takes a lot of time. I wonder if it coudn't go faster or even instant.
    What I did so far: The programs I made are all based upon the jit.matrix commands: srcdimstart - srcdimend - dstdimstart - dstdimend. I copy pixel line per pixel line to the destination-movie. I tried to increase this workflow by letting the program do only a part of the whole image, so I could run multiple instances to benefit from multicore processing. Works good, but still way too slow with decent resolution images: to create a moving slitscan, I have to play the source-movie as many times as there are pixels in the width, which is pretty time consuming
    Slitscan: If you look at a movie file as a cube of pixels - one frame forms a slice, all the frames forms the cube - we are used to traverse this cube always in one direction: from the front (start) to the back (end). What I would like to do is traverse this video cube from the right to the left.
    Instant: I was wondering if this could be done by "simply" navigating in a different way through the movie data package instead of running through this long copying process. If you have only spacial compression (like Motion JPEG A), I guess the data package is just a bunch of pixels, so why not just 'play' the movie, but then in a different direction, from the right to the left. Instant slitscan.
    I guess it won't be that simple, but I thought to ask the question here, since I don't know much about the structure of a spacial compressed quicktime movie.
    ps: my thesis-film was made with moving slitscans too.

    • May 03 2011 | 6:58 am
      "What I would like to do is traverse this video cube from the right to the left."
      Do you want to do this once, lasting the entire duration of your video or instead do you wish this right to left traversal to recur several or many times? (Your preference determines the specific approach to be used.)
    • May 10 2011 | 1:10 pm
      I would like to do this once. In other words: I just want to rearrange all the pixels in a movie file (slit scan) and save it as a new movie file. This is to process a lot of files in order to start editing a movie project.
      It doesn't necessary need to be max only. I tried Processing too, but the most basic patch was way slower than a basic max-patch.
      (sorry for my late answer, I didn't got an email-notice and lost the hope after checking a few times :)
    • May 12 2011 | 3:00 am
      Is it necessary to do this in realtime?
    • May 12 2011 | 10:07 pm
      No, I would like to do this non realtime, just as fast as the computer could perform.
      I'm cleaning and debugging a patch that I could post here in a few days, but I don't know if that is a good starting point, because using the srcdimstart - srcdimend - dstdimstart - dstdimend commands to the matrix object seems not efficient enough. I'm hoping a little that there could be a fundamental different approach to make these slitscans, just to reduce processing time.
    • May 13 2011 | 12:05 am
      Sounds like you're on the right path for now. SInce realtime is not an issue for you, the various commands to jit.matrix will work well. I find I have more precise control that way than when trying to use an OpenGL slitscan.
    • May 13 2011 | 7:42 am
      Alright, I indeed prefer pixel per pixel translation, so using the matrix commands seems to be the only way.
      I saw someone building a slitscan application in C++ and he could sped up the process by loading the entire movie in a sort of buffer. I know one can load a movie in RAM, but there is still the bottleneck of the cpu. I can try to make a better multicore application, but I guess it still would be slow due to the mail building blocks of the program: the matrix commands (as opposed to the idea of simply interpreting a video-file in a different way so you would become a slitscan immediately. The pixels are all there, they just need a different location in the data-file). Anyway, I give it a try.
    • May 13 2011 | 5:57 pm
      One approach might be to use a 3D jit.matrix as a buffer for frames of the video (z=time). There are many examples of this in the forum archives, like this:
      Spending some time really getting into the jit.matrix object will really help.
    • May 14 2011 | 7:10 am
      I didn't thought about using the jit.matrix with a third dimension, that sounds interesting. I'm going to spend some time getting in to the jit.matrix object. Also thanks for the link to the other thread!
    • May 20 2011 | 8:35 am
      I'm getting there slowly. I now load a movie in the jit.quicktime object and then do a 'framedump' into the matrix object so that every frame is a new 'plane' in the z dimension. The drawback of working with a matrix is the limitation of images you can put in. So I sequencially load parts of the image and export multiple movies. It should be nice to be able to do this:
      srcdimstart 0 0 0 (x y z) srcdimend 0 "height of movie" "total frames" (x y z)
      This way one would be able to immediately visualise an image in the z-axis, but this doesn't seem to work. I now use the old way of copying pixel row by pixel row into a new matrix. I'm surprised by it's speed though!