Elias

I'm experimenting with moving slitscans such as 

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.

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

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.

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.

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.

ps: my thesis-film was made with moving slitscans too.


structure-of-a-quicktime-movie-instant-slitscan

"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.)

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.)


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 :)

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.

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.

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.


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.

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: 

https://cycling74.com/forums/jitter-delay

Spending some time really getting into the jit.matrix object will really help.

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: https://cycling74.com/forums/jitter-delay

Spending some time really getting into the jit.matrix object will really help.


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!

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!


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.

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!

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!


structure of a quicktime movie / instant slitscan