What is the relationship between coding, pixel art, computational thinking and digital representations of images? We talked about it in a webinar organized on the occasion of CodeMOOC's first birthday. Find below the slides, which you can download and reuse. The full video recording of the webinar is available on YouTube and is directly linked to the last slide of the presentation. Here are some preliminary considerations which I hope will provide a further key to reading the webinar and the slides.
Preliminary considerations
Computers need to build a grid and color the squares to represent images. They don't know how to do otherwise. Each square is a pixel . We call pixel art any drawing that highlights the checkered structure and makes it an artistic expedient, making a virtue out of necessity.
The smaller and more numerous the pixels, the less evident is the grid and the more defined and continuous the image appears. The number of rows and columns of the more distinguish the pixels. High-resolution videos have 1920 columns and 1080 rows, so about 2 million pixels. The cameras of our mobile phones and the screens of mobile phones, tablets, computers, even more.
Once the grid has been defined and a starting point has been chosen (by convention the upper left pixel) and an order (by convention, the scan by rows from left to right and top to bottom), to represent an image just say the color of each pixel. There is not even need to represent the change of line, because it is enough to have decided once and for all that when you get to the bottom you start over from the beginning of the next line. Just like when you read. The color sequence of each pixel is a mere description of the image. It is not a procedureto draw it. To make it so we must also explain how to use it. For example: starting from the pixel on the top left and proceeding by lines, as long as there are colors in the sequence, read a color, use it to color the pixel you are on and go on.
There are also more compact descriptions. In particular, the RLE encoding (run length encoding) uses the concept of “run” to avoid repeating the same color several times in a row. A “run” is just a sequence of contiguous pixels of the same color, which is represented by indicating the color only once and specifying how many pixels it should be kept for.
Since there are several possible descriptions, to interpret them correctly it is necessary to know what convention they adopt. In the images we usually use, the file extension (the two or three letters following the file name, after the dot) indicates its format. The program we use to open the file applies the right procedure to interpret the description and show us the image.
Using pixel art as an unplugged coding activity we can take inspiration from image description formats by adopting a convention and describing the image consistently. In practice it is as if the procedure were part of the convention adopted once and for all and the description of the image allowed the performer to reconstruct it. In computer jargon, the description of the image is declarative.
We can use an imperative approach by equipping ourselves with a repertoire of instructions that directly describe what to do to draw the image. In this case, the description of the image and the actions to be taken to reproduce it are one and the same. For example, we can use CodyRoby to move a robot on the pixel board by adding a new instruction that tells Roby to color the pixel it is on. Drawing is the entire sequence of movement and coloring instructions.
In any case, the drawing that is produced by coloring the pixels is a so -called pixelmap , or bitmap , characterized by a predefined resolution. Conversely, a drawing could be described through unlimited resolution as a combination of geometric figures and curves whose parameters or construction rules are given. If we want to draw a circumference we just need to indicate the center, the radius, the thickness of the line and the color. Whatever the resolution of the drawing, with this description we will always be able to reconstruct it fully exploiting it. This technique is called vector graphics. A bitmap of any resolution can always be generated from a vector drawing. A vector drawing or a higher resolution bitmap cannot be regenerated from a bitmap.
Even with vector graphics you can do coding. And even in this case you can define a convention and use a declarative language to describe the drawing, or you can directly use an imperative language to describe the actions necessary to draw it. It's a bit like technical drawing. If we have to explain to someone how to use the compass to draw the circle we give them precise instructions and following our directions they will draw the circle ( imperative approach ). But if we all already know how to use the compass to draw a generic circle, to have another draw a circle we just need to provide the parameters of the circle we want ( declarative approach ).
The imperative approach is that of the artist from code.org or from Scratch. If you want to experiment with vector graphics and touch the expressive power of a declarative language, I recommend you use inkscape (it is free and open source and allows you to do everything) to generate a file. svg (simple vector graphics). Then open the .svg file with a text editor to look inside and try to recognize the description of the various objects you have drawn.
I perfect art with paper and natural colors. Digital is fast but i still like the classic. drift f1