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 prototiles (rectangle or masked polygon shaped images with transparency) and a list of clone, rotate, mirror (flip,flop), and translatecommands collected in a CRMTcommand list. A CRMTinterpreter would take such a list and a set of prototiles and generate an image tiling, ornament or pattern by stepbystep processing the commands.
For example the following CRMTcommand list is coding the 14 processing steps to generate a p3m1 tile from a given equilateral triangle prototile image (see my p3m1examples using this CRMTapproach on https://www.flickr.com/photos/gbachelier/albums/72157673790864417):
C0, x0, y0, C0, Fo, R60, x1/2t_w, y0, C0, Fo, R60, x1/2t_w, y0, C0, Fo, R60, Fi, xt_w, y0, C0, Fi, x3/2t_w, y0, C0, Fo, R60, Fi, x2t_w, y0, C0, Fo, R60, x5/2t_w, y0, C0, Fi, x0, yt_h, C0, Fo, R60, Fi, x1/2t_w, yt_h, C0, Fo, R60, Fi, x1/2t_w, yt_h, C0, Fo, R60, xt_w, yt_h, C0, x3/2t_w, yt_h, C0, Fo, R60, x2t_w, yt_h, C0, Fo, R60, Fi, x5/2t_w, yt_h
The operation sequence for one prototile processing like C0, Fo, R60, x1/2t_w, y0 is interpreted as: clone the first (starting with 0) element in the prototile list, flop it, rotate it 60 degrees counterclockwise (+ trim), make a translation in xdirection with floor(1/2t_w) where t_w is the width of the equilateral triangle, make a translation in ydirection with 0 and then compose the prototile 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 CRMTinterpreter also needs a list with coordinates for one or more masks that must be draw because the masked prototiles 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 nooverlap condition of tilings the processing steps for one prototile 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 runtime can be saved by the knowledge that the lower half is a flipped version of the upper half.
To further develop the CRMTapproach 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 CRMTinterpreter 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 â€śvirtualpixel mirrorâ€ť it makes everything much easier because composing polygon shaped images results in artifacts at the edges if non90 degree polygonmasks 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 postprocessing 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 CRMTlist 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/drawingsdiagramsanalyses/1/elementsartarabe).
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.
Future perspectives

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 prototiles to generate pattern. Combined with an interaction log that records the relevant actions and a CRMToptimizer that combines all the actions related to one prototile to one command set a CRMTlist 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/girihapp/) is also worth a look how a GUI type system could be made. If in a longterm perspective AIagents 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 CRMTinterpreter.

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.