Create better color growth script

[scribblemaniac]

I saw a video of the color growth script and wanted to play around with it. Unfortunately it was really slow. I have optimized it quite a bit, mostly by using more appropriate data types and removing some unnecessary complexity. For reference, a 256x256 image (--WIDTH 256 --HEIGHT 256 --GROWTH_CLIP "(1,5)" -q 5 -s 0) takes me ~7.5 minutes to generate with the original script, and ~5 seconds to generate with this new script.

I also added a few new features:

• Random color mutation base. By using -c random or --COLOR_MUTATION_BASE random, each origin point will be assigned a color randomly.
• Border blending which causes the pixels to blend with their neighbor under some situations. It helps remove the very hard edges between significantly different 'mutations'. Enabled by default, disabled with --BORDER_BLEND False.
• Tiling. By having the growing color to loop from any one side to the opposite side, the generated image becomes seamlessly tileable. Disabled by default, enabled with --TILEABLE True.

[earthbound19]

Wow, thanks for this! I'll have a look and merge as appropriate.

I have had the same complaint about speed and wondered if the algorithm is optimal and how it could be optimized. If you've done so much of that work, super fantastic! :)

[scribblemaniac]

No problem. Let me know how it works for you.

[earthbound19]

@scribblemaniac, I pasted your improved version (color_growth_fast.py) over the original color_growth.py, after I copied the original slower version to /_deprecated/color_growth_v1.py, so you know. I've continued development (of new features and bug fixes) on it.

Also, I don't know whether you saw that the faster version sacrifices a feature of the slower version in which --GROWTH_CLIP deliberately allowed values below zero or higher than 8. This feature caused cells to not grow sometimes or to excessively grow (respectively).

The slow version, for example, with a clip rate of (-12,3), can produce a result like this:

Where the fast version does unexpected stuff (including rendering a lot of things in the first frame), like this:

I haven't investigated what causes that behavior change. I also haven't yet examined what it is you did that sped things up so much :) but I'm very happy to sacrifice the possibility of outsized clip rates for the faster speed. I would bet that reintroducing the possibility of outsized clip rates would slow things down again.

I'd love to get this algorithm into a compiled language or even parallel processing (like multithreaded or a GPU if possible) to add that feature back without sacrificing speed, and with (I would hope) much faster speed anyway.