Symmetry and symmetry breaking is a central topic of my artistic work. I am fascinated by image tiling as a source of symmetry building but until recently the situation was not different than 25+ years ago when my interest started with the Photoshop plugin Terrazzo from Xaos Tool: There are thousands of known euclidean tilings (Tiling Database http://www.tilingsearch.org/) but only the 17 wallpaper groups (https://en.wikipedia.org/wiki/Wallpaper_group) were used for image tiling (which has its reasons but nevertheless).
I am working on a general approach to change this: Every image tiling or image pattern in general can be made by one or more proto-tiles (rectangle or masked polygon shaped images with transparency) and a list of clone-, rotate-, mirror- (flip,flop), and translate-commands collected in a CRMT-command list. A CRMT-interpreter would take such a list and a set of proto-tiles and generate an image tiling, ornament or pattern by step-by-step processing the commands.
For example the following CRMT-command list is coding the 14 processing steps to generate a p3m1 tile from a given equilateral triangle proto-tile image (see my p3m1-examples using this CRMT-approach on https://www.flickr.com/photos/gbachelier/albums/72157673790864417):
C0, x0, y0, C0, Fo, R-60, x-1/2t_w, y0, C0, Fo, R60, x1/2t_w, y0, C0, Fo, R-60, Fi, xt_w, y0, C0, Fi, x3/2t_w, y0, C0, Fo, R60, Fi, x2t_w, y0, C0, Fo, R-60, x5/2t_w, y0, C0, Fi, x0, yt_h, C0, Fo, R-60, Fi, x-1/2t_w, yt_h, C0, Fo, R60, Fi, x1/2t_w, yt_h, C0, Fo, R-60, xt_w, yt_h, C0, x3/2t_w, yt_h, C0, Fo, R60, x2t_w, yt_h, C0, Fo, R-60, Fi, x5/2t_w, yt_h
The operation sequence for one proto-tile processing like C0, Fo, R-60, x-1/2t_w, y0 is interpreted as: clone the first (starting with 0) element in the proto-tile list, flop it, rotate it 60 degrees counterclockwise (+ trim), make a translation in x-direction with floor(-1/2t_w) where t_w is the width of the equilateral triangle, make a translation in y-direction with 0 and then compose the proto-tile over the tile background which is in the p3m1 case a black image with an (2t_h, 3t_w) area with t_h = 1/2*sqrt(3)*t_w.
Additionally the CRMT-interpreter also needs a list with coordinates for one or more masks that must be draw because the masked proto-tiles must come somewhere; in the p3m1 case the x and y coordinates of the triangle are: x_coord = [0 t_w t_w/2]; y_coord = [0 0 t_h];
Such an approach is not fast but universal and because of the no-overlap condition of tilings the processing steps for one proto-tile are independent and therefore the 14 steps in the p3m1 case could be made in parallel. And there is always the option to optimize some specific tiling by using some knowledge about its structure. In the p3m1 case run-time can be saved by the knowledge that the lower half is a flipped version of the upper half.
To further develop the CRMT-approach I am searching for
1. Programmer implementing CRMT interpreter in different environments
– environments that are free available like G’MIC or making a CLI program with Python or Perl in combination with a free image lib like ImageMagick (http://www.imagemagick.org), GraphicsMagick (http://www.graphicsmagick.org/ might be faster than IM) or GeGL (http://gegl.org/ basis for GIMP)
– environments that are widely used by students and professionals like the three big M’s: Mathematica, Matlab, Maple. Mathematica has by far the larger audience in academia but Maple has the better tool to translate code in the target languages C, C#, Fortran, Java, Matlab, Perl, Python, and VisualBasic so that one Maple implementation could serve as a first prototype in those languages.
Programming a CRMT-interpreter seems neither a difficult nor a too costly task because the core is some string processing combined with calling some image processing functions. And if the used image processing system has RGBA abilities and boundary methods like “-virtual-pixel mirror” it makes everything much easier because composing polygon shaped images results in artifacts at the edges if non-90 degree polygon-masks were used.
I have programmed a (not as reliable as wished) batch processing prototype in Matlab but because Matlab lacks both RGBA abilities and boundary methods it was unnecessary complex and a costly post-processing step was needed to deal with the edge artifacts. I will share the code with interested developers for inspection but for sure in the end they will come up with more effective and efficient implementations.
2. People writing their own CRMT lists
Every high school student with basic trigonometry knowledge can determine the angles, lengths and distances in a given tiling image from the Tiling Database to write a CRMT-list without any knowledge of a specific programming language or image processing, so there is potential a huge community. It is only a question of persistence to code even the most complex periodic tilings like Islamic patterns (https://patterninislamicart.com/drawings-diagrams-analyses/1/elements-art-arabe).
Math teachers are often looking for something motivational. Real world applications and aesthetics in math (see Bridges conferences http://bridgesmathart.org/) are mostly the areas they come up with and I think that image tiling is an excellent example for the later. Writing a CRMT command list for a tiling would be a nice assignment if intermediate states could immediately be checked for feedback with a freely available CRMT interpreter.
Using trigonometry to extract information from given tilings, ornaments and patterns will restrict the audience mostly to academia and some math enthusiasts. A much wider audience would be reached with a GUI based system where humans can drag&drop proto-tiles to generate pattern. Combined with an interaction log that records the relevant actions and a CRMT-optimizer that combines all the actions related to one proto-tile to one command set a CRMT-list for a pattern should be reconstructible. I am thinking about modifying the freely available Mathematica demonstration http://demonstrations.wolfram.com/TilingConstructorTileDraggingVariant/ and the Giri App (https://twitter.com/GirihApp, http://hintz.bplaced.net/en/2015/art/girih-app/) is also worth a look how a GUI type system could be made. If in a long-term perspective AI-agents with a learned sense for symmetry and aesthetic can play such a system an endless stream of interesting pattern descriptions would be accessible that can directly be used in every environment with a CRMT-interpreter.
The CRMT approach is also extendible in many directions like simply adding a new command type “S” for scaling which makes image types like euclidean Fractal Tiling (https://www.mathartfun.com/encyclopedia/encyclopedia.html), Iterated Function Systems and orbit trapping (http://2008.sub.blue/projects/fractal_explorer.html) accessible.