Nice!

Amnon, thank you for your very speedy update! I'm really impressed at the new features, ease-of-use and the speed! I wish I had your programming skills. I've just been sending some old sequences through the new software to test it out and will give you more considered feedback after the weekend. So far, I'm impressed and very grateful. 

Good point, added towards v0.3. I also changed the code slightly so it only converts once to lowercase (instead for every format). I noticed a typo in the setTextareaInfo() method of the Slitscanner (which is also visible in the screenshot). Of course the second parameter should be inputHeight so it displays the correct info onscreen.

I've been giving the software a good testing - my HD has filled-up with many more GBs of slitscans! 

All right, so far I have implemented the following changes towards v0.3:

• Added pause button
• Added "Select output directory" button (by default: sketchpath\output\)
• Rewrote createOutputName() method for names more in line with the current modes & settings
• Minor optimizations & bugfixes
  

All right, problem found and solved. See the opening post for the link to the latest version.

It was a conceptual problem with the size of the last batch. It's nearly always smaller than than the default batchSize. Suppose you have 1280 inputWidth which leads to 1280 output images. Then suppose the batchSize is 500. So you have 3 batches. The first 0-500. The second 501-1000. The third 1001 to 1280. And NOT to 1500, which is what the old code for dimensionalSwap did. The code for TimeOffset already had safe code for handling this, because it dealt much more with possible out-of-bounds ranges. Conclusion all is fixed and new version uploaded. Old version has been deprecated. Please use the new version.

That's brilliant! DimensionalSwap is working perfectly now, thank you. Your explanation of the bug makes.

Yeah, I noticed the blackness at the start. It's because slitscan-wise there is no history for these pixels yet. Instead of black it could be the original frame, this would make more sense. I remember wanting this back when I wrote the time offset code a few months ago, but running into some troubles. I have an idea for a different approach now, so I'll give it another shot to see if I can add this feature.

That video seems to be an upwards time offset on a slowed-down video. The only thing moving is the thing in the middle. This is where time offset works best. With a largely steady background and one thing moving. For example a door opening or a person turning around.

Regarding the Time Offset setting: sequences made with it begin with a black frame, filling up line-by-line from whichever direction one chooses. I was wondering if an option could be added to the interface for that black frame to be replaced by the first image of the input folder?

All right. This option has been added. When in TimeOffset mode, a button appears to toggle firstImage. Set it to on to replace the black frame by the first image of the input folder. Try it in v04.

Thank you, amnon.owed!

Thanks, welcome and good luck dmanthei.

Ok, I've been messing with this for a few hours

Change the code and it'll do something different. This is the creative freedom that Processing offers. And of course this is also the difficulty.

The code of SlitsP5 has been optimized as much as possible for three things: ability to handle all resolutions, speed of execution and efficient memory management. Some other things were (sort of) sacrificed along the way: readability and flexibility of code. Of course I've experimented with other types of slitscanning: realtime, offset matrices, individual pixel-based, interactive. Anything is possible, but the code will be different. In short, SlitsP5 does what it does while at the same time there are many other possibilities. These general remarks apply also to your ideas. Possible, but the existing code is maybe more an inspiration than a direct base for tweaking.

Let me elaborate on what timeOffset does. Suppose you have 7 lines width that needs to be offset. This means you need a history of -6. So it'll start mostly black and after 6 frames you will have a whole image. This whole image is built up like shown below.
__
|-6|_ <= frame -6 (the left line needs the biggest history)
|  -5|_ <= frame -5
|    -4|_ <= frame -4
|      -3|_ <= frame -3
|        -2|_ <= frame -2
|          -1|_ <= frame -1
|________0| <= frame 0 (the right line needs no history, it's always the current frame)
       ^^
(the viewer)

By comparison, normally it would look like this.

| 0000000 | <= frame 0 (current)
      ^^
(the viewer)

Now if you have an input image of 1920 pixels width. Then the TimeOffset will be up to 1920 frames in the past, which even at 30fps is more than a minute ago. So yeah, that's a pretty substantial offset. Suppose you would want to change this method of linear history states to something else.

Would it be |-6 -6 -4 -4 -2 -2 0 | or | -3 -3 -2 -2 -1 -1 0 | ?

Of course the second option would require less history states (thus memory, thus batches, thus faster) and would be less extreme. It would also be half the offset (only up to -3 instead of -6). So to get back to your first point. Shifting one-line-per-frame is a reasonable interpretation of the fact that each line currently has a linear 1 history state difference compared to the line besides it. This could be changed as described above.

Your second point seems more suitable for either a realtime application or one that has more refined controls (ala after effects keyframes) to change/tween the targets during the process. With regard to the former. One of my realtime experiments had a sort of pixel-based matrix where if you press the mouse the history states around the mouse increase. Once you release the mouse the whole image returns slowly to the current frame. The pink and yellow image from my blog post was made with this technique. Of course the problem with this is that you need to keep a lot of images in memory, because you will never know which pixels up to what history you will need. So this technique is limited by (surprise!) memory. Not to mentioned the initial loading time, when all the images have to be read into memory before you can start.

Now if you think all of this is getting a bit mumbo-jumbo, you should have seen the paper drawings I did at the time to wrap my head around history states and memory management. Once drawn out, it allowed me to compress the whole process into code that is this short. Slitscanning code always revolves around all of the issues discussed above. The main problem is memory. However TimeOffset is actually the easier of the two, because DimensionalSwap requires pixels from literally every input image for every output image. While TimeOffset only requires pixels up to it's number of history states.

In short it's not easy. And for most people it wouldn't be a beginner challenge. Most beginners start with drawing some circles to the screen (seriously). Realise this if you want to try.

Wow, thank you for that thorough break-down.

Same answer as above. Possible if you adapt the code accordingly. Your last idea is closer to my offsetmatrix experiments. Let's go over a few offset matrices for a 5x5 image, where all numbers are negative history states.

Normal

[ 0 0 0 0 0 ]
[ 0 0 0 0 0 ]
[ 0 0 0 0 0 ]
[ 0 0 0 0 0 ]
[ 0 0 0 0 0 ]

TimeOffset (SlitsP5)

[ 4 3 2 1 0 ]
[ 4 3 2 1 0 ]
[ 4 3 2 1 0 ]
[ 4 3 2 1 0 ]
[ 4 3 2 1 0 ]

Because the history states are strongly linked to the width (or height depending on the direction) it becomes easier to optimize and shorten the code accordingly.

Your idea (or vice versa)

[ 2 2 2 2 2 ]
[ 2 1 1 1 2 ]
[ 2 1 0 1 2 ]
[ 2 1 1 1 2 ]
[ 2 2 2 2 2 ]

I've tried this. Once the slitscanning is matrix-based, it becomes possible to generate the matrix with a function or an image, which gives a lot of flexibility to the effect. I've even done realtime interpolation between offset matrices. The matrix is very visible in the output and it's no longer the 'traditional' slitscanning effect.

The greater the flexibility of the effect, the harder it is to optimize the code.

Hi. Your slitscanner code for Processing is amazing. 

Thanks!

It's not possible to tweak the code to achieve the ideas described above. Flexibility among other things was sacrificed in the process of optimization. The existing code can be more an inspiration than a direct base for realising those ideas. To flesh out the matrix techniques it would be easier to start with code that kept n previous full frames in memory and work from there...

Ah, OK. 

It's kind of hard to explain, but let me give it a shot anyway...

You can see a film as a cube/box made from a series of consecutive frames. Normally you move through the timeline of a film. You start with all the pixels from the first frame. Then you see all the pixels of the second frame. And so forth. DimensionalSwap means the time dimension is swapped for a spatial dimension aka x or y. To get back to the film-as-a-cube example and a horizontal (x) DimensionalSwap. You now view and move through the cube from the side instead of from the front. Every frame you see in the dimensionalSwapped version is a compilation of slices from each frame of the timeline film. The first dimensionalSwap frame is made from pixel column 1... in fact every pixel column 1 from the entire original film. So indeed the right of the frame is the end of the original film. When you view a dimensionalSwapped film you are not moving through time anymore, but you are moving through space. From the first column, to the second column, to the third column, etc. Until you have reach the end of the spatial dimension. That is why a dimensionalSwapped film is as many frames as the original spatial dimension and as wide as the number of original timeframes (or similar for y). Every DimensionlSwapped frame gives an instant complete overview of all times (time-frames) for that specific pixel column.

Most slitscanner examples, especially the realtime ones, let you specify one single y column (slit) that is taken each frame to create an image. In that process 99% of the original frame is discarded. My program automates the process and thus uses every pixel from the original film, except that it completely transforms the location of that pixel.

Hope this clears it up a bit.

Hello again Amnon,

This is very thorough investigation. Good work. Personally I haven't worked with the slitscanning code for quite some time, but I do know that memory handling has always been the issue to beat and is still not solidly handled in the current code. I've asked questions for example here for better methods, but none have really provided a solid answer/solution. To summarize I can't really help on this now (maybe some day), but perhaps you or others have suggestions how to improve the code.