Modulations, Modulations, Modulations

Here is yet another experiment in generating noisy images. This time the pattern is obvious, regular. The point of all this is to start with noise and modulate the noise until I get something "visually interesting." Below the code I wrote to generate the image is the resultant image itself.

Noise field by A.G. (c) 2017. All Rights Reserved.

Code Reading

I just wanted to say that when I'm in the coding mood/mode, I like to do an insanely large amount of code reading. I go on Github or look at Github Gists, or look at code on-line in tutorials and quickstarts. It's really what helps me the most in learning to code in Python, which I've been doing for a good 6 years now.

There's a whole other side to what I just said that I won't go into too many details about. Suffice to say that I believe in a kind of New Documentation where the purpose of documenting code is precisely for the ambient code-reader who happens to stumble across the code doing searches on the web or on Github.

Think of it this way. If you're writing code that's going to be read by yourself or your team members, you can get away with documenting less or maybe not even at all. But in the open source universe, you have to think of an indeterminate number of people who might read your code 5 or 10 or 50 or 100 years later. So it's important I think to be very "literate" in one's documentation.

You can never take for granted that future code-readers are going to know what you were trying to do, even if they can get your code to work. One thing I learned is that you have to UNDERSTAND the code, how and why it works, along with what it's purpose is. I can write a Python script that does exactly what I needed it to do and yet not fully understand it because I'm just basing my coding on idioms I learned and stuff I saw other coders write in my code-reading experience.

It's tantamount to saying something and not truly understanding it. You can still get the point across to an audience, but what's the point if you don't even fully understand what you are saying? A wise man once told me to only ever speak about what I have knowledge of. I think it should be the same thing with code. Use restraint. Only write code about what you understand and have knowledge of.

I find code-reading a great passtime. I can almost never get the code to run on my machine, but I see how the problem was solved, or at least one possible avenue. Often I find the code very ugly and hard to read, and that's when I go back to the basics and make sure I know what I'm doing when I write code.

I think that a certain responsibility comes from being able to code, just as one has the responsibility to watch what one says when one is speaking. Think before you open your mouth, or before you code something.

Procedural texture synthesis it is called

Procedural texture synthesis by A.G. (c) 2017. All Rights Reserved.

...

Noise Field Breakthrough

Procedural texture synthesis. A.G. (c) 2017. All Rights Reserved.

I had a mild breakthrough. The above image was generated entirely through numerical computation. I essentially created a vector with 65536 values, all either a 0 or 255. I generated various segments of all black or all white, of different lengths, and I created the 65536 vector by randomly choosing between various length "LINES" or line segments.

Then I generated a Gaussian distribution matrix and did a matrix operation equivalent to a difference blend mode. That is, I took my two separate 65536 vectors and turned them into np.array types, did the arithmetic, subtracting one from the other, and then I ended up with the above image.

There must be easier ways to do this, but I chose to work with a vector of 65536 values. I just am learning to construct it in different ways. I will try to do it using list comprehensions and functional programming, to make the job more elegant.

I repeat: The above image was generated entirely through numerical computation in a step by step, therefore algorithmic, method. I just did some of it manually, creating the 65536 vectors.

Noise Field Redux

This time I am "seeding" an image with random black and white pixels.


I used the "L" mode, which is a standard mode for an image that has 8-bit pixels, black and white. I am choosing a black or white pixel at random with the random module:

im.putpixel((x, y), random.choice([0,255]))

The next step is to write modulation functions to modulate the noise field. I am working on a threshold function for when I make noise that is in grayscale. I am also trying to work out a pixelate function, which is proving more difficult than I thought.

The bit at the end with the saving of the image may look weird, but it allows me to save the image with its date and time as filename. For now, this makes it easier for me to work with my images. Here is an image made with the code above.

Noise field generated with Python code. A.G. (c) 2017. All Rights Reserved.

Noise Fields, Noise Fields, Noise Fields

Noise Field (512 px x 512 px). An applied noise function. A.G. (c) 2016.

Here we have pretty much the same thing as before, i.e. a function called noisefield() that returns an image. This time what we did, or tried to do, was to generate a "LINE" first that is a list of 512 "RGB tuples" which in this case, as before, are randomly generated (via the noxel() function).

Then, simply enough, all we did was create an entity called "MATRIX" that is made up of 512 "LINEs". We used an "iter" function to create an object called "nixel", as you can see, that iterates over the "MATRIX" object which is basically just a very long sequence of RGB tuples made up of the concatenation of 512 "LINEs"

What you can see in the image above, created via this Python script, is an interesting series of LINEs, each with randomly chosen RGB tuple values.

Here is the code, hosted on Github as a Github Gist.

You might as well ask, since I know you're thinking it: Why go through all the troube? Couldn't you do this much more simply with less code and in a much more idiomatic style, plus much more elegantly? The answer is, yes, of course I could. This is only the beginning. I have structured the code this way because I want to be able to create what I call "mod" functions which are "modulations of the noise field", so to speak. I want to be able to create noise fields and then apply functions to them, either on a pixel-by-pixel basis or else on the whole image, or else on individual "LINEs" which in this case, as vectors if you will of random "RGB tuples", the LINEs that is, are actually "column" vectors and not "row" vectors, if you will. That is to say, the LINEs in the Image, of individual random RGB tuples, appear "horizontally", but the actual LINE in the code ends up being in the "vertical" direction. This is not a glitch, it's because in the code in the 5th line of the noisefield() function, we have (x,y), i.e.

im.putpixel((x, y), nixel.next())

We could just as easily make the uniform-colored lines appear on the vertical axis in the final image just by switching (x,y) to (y,x). To be continued...

Prolegomenon to Noise Field Theory (via Signal Science)

Noise Field (512 px x 512 px). An applied noise function. A.G. (c) 2016.

Noise Field Theory is a somewhat complex domain that I have been investigating, exploring, now for many years. For now, I just want to share some actual working code in order to eventually develop the theory of Noise Fields in a way that people can actually understand. That way me critics can finally realize that I'm not so crazy after all.

Simply put, you have these "fields" called noise fields. The simplest way to imagine a noise field is to just think of a matrix of numbers, but not just any old matrix. Imagine a digital image, a Bitmap, say, that is 256 pixels by 256 pixels. The simplest form of a noise field is just such an image/matrix made up of random values.

As you shall see in the code, I create something called a "noxel" which is meant to be a kind of "pixel", i.e. a "noise pixel" = "noxel". In RGB, it has three values, each of which is a random number between 0 and 255, the possible values for an image inside the RGB model.

What we do is create an image and assign a new noxel to each pixel, creating essentially a random matrix, a.k.a. a noise field. What I will do a little later is explain what this all means, because I can assure you, there is a much deeper meaning that is not obvious at first. (It took me 20 years to get this far, this is not simple, yet it is quite elegant).

That's it for now. Stay tuned for more details on the noise field as data model - for we are using Python programming to explore Noise Field Theory. It becomes a language, if you will, to speak about noise fields. I will also show why Noise Field Theory is not only best explained through Python itself, but through what we have called Signal Science. In the above case in point, in the code, the "noxel" function is "passed" as an "input" into the "noisefield" function. This allows us to tackle the also complex subject of Signal Science, which essentially is a purely signal-based view of the world and everything in it. To be continued...