by: Tal Hendrickse
My project is a small program that can apply a pixelsorting effect to an image and export it. It can sort all of the pixels in the image by either brightness, lightness, saturation, redness, blueness or greeness. It has no GUI and is operated by using the keyboard. 'A' toggles the direction of the pixelsorting (vertical/horizontal).
'<' and '>' cycle through the six types of pixelsorting. Starting from brightness and ending in greeness. 'E' Exports the resulting image and saves to hard drive.
The intended audience for this project was originally anyone who is interested in seeing an audio-reactive composition that explores the way sound and visuals can interact. Now however, the audience for my program would more accurately be people who need a way to either vertically or horizontally apply pixelsorting to an image in a short amount of time.
The intended result of this project in the very beginning was not just a simple pixelsorting program, but a generative, audio reactive composition that used a pixelsorting effect to distort images. This idea came about because I stumbled upon the pixelsorting subreddit (https://www.reddit.com/r/pixelsorting) and reasoned that it would be possible to port the original pixelsorting algorithm (Kim Asendorf) over to c++ from Processing and have it run in real time in response to music it would be possible to create the audio-reactive composition. I was naive however, as shaders are the more appropriate form of graphics processing that I was looking for. I discovered this after I realised that my project runs very slowly because it is being rendered entirely by the CPU.
What went wrong
One of the things that went wrong with this project was the lack of understanding about what would need to be done in order to arrive at the desired result. Another thing that impacted negatively on the development of the project is the fact that I was struggling to keep up with absorbing the amount of knowledge I needed to make it happen. I recall at one time, I didn't fully understanding that openFrameworks is a huge library that has many functions for manipulating pixel arrays and so instead of starting to code I spent a large amount of time searching for other image manipulation libraries.
What I have learnt
From doing this project, I have learnt that research is important, but too much of it in the wrong places can be very unhelpful. I have also learnt that planning before coding things and sketching out how they interact with the rest of my program, what functions they use and roughly how they fit together helps prevent incidents that involve starting work on new functionality for a project before realising that there is a much easier and more efficient way to do the same thing and having to re-write much of it.
What I will do differently next time
Next time that I contribute to a project of a size significantly similar to one such as this I will change a few things about my approach with the intention of improving the quality of work that I produce for it. Some of the things that I will change are:
A short time should be spent on researching the technical ingredients for what I intend to do. This means looking at directly which functions from the library I intend to use and not researching in areas that are largely irrelevant to the project.
Before I begin coding on a new piece of functionality, I will ensure that I fully understand how each class and different part of my software passes information between itself and how that impacts on what I need to include in the new code I am writing.
I decided to explore the pixelsorting aesthetic because it is a style of glitch-art that I personally enjoy. The ability to take any image and turn it into a new piece of art by applying a sorting algorithm on the pixel array is familiar to me in a way because it has a parallel to something I and many other music producers do. Sampling older music and using it to create new work.
Problems that I ran into during the project
The specifics behind the problems I had and how they were solved are lost to my memory. However, I do believe that every time I encountered a problem it delayed me for longer than it should have because I did not understand my code well enough to properly grasp how it broke. Meaning that instead of just fixing the problem I also had to find it and as a result, often did time-ineffecient research into tangentially related topics, which certainly did not help my project reach fruition.
 Firmread -- Pixelsorting in C++
 Kim Asendorf -- Original processing script
 Autechre -- Grantz Graf (music video)