v0.6.0

This is a bit of an intermediary release. I'm preparing the next big version of the application, where the CPU-based rendering, blending and diffing will be replaced by GPU instructions (making it much faster). Unfortunately, that new version will break compatibility with previous releases: the same command line arguments will now produce slightly different results because of implementation differences in the painting algorithm (the new one is actually more correct).

Therefore, I'm creating this version to bring some important features that have been implemented already, and to make this last CPU-based version more robust. Some of these new features will make it easier to compare the speed between this and future releases, to validate that the GPU-based version is actually better.

Changelog

• Changed: output images are not eagerly saved on every successful generation anymore; they're only saved during their "final" output, when any of the required parameters (tries, generations, or diff) is met. This should reduce I/O thrashing and make the overall generation process faster. The old behavior can be brought back with the new --save-often parameter
• Changed: argument help shown with -h/--help has been rewritten and should reflect the content of the online documentation
• Changed: even more internal code cleanup, updated configuration to Rust 2021
• Added: new --benchmark parameter to show additional statistics about the output generation process (this implies --candidates 1)
• Added: new --save-often parameter to re-save the output image on every successful generation

v0.5.0

Blending modes have been added, adding great variation on how images are generated! A lot of the internals of the application have also been revamped in preparation for upcoming features.

Change Log

• Fixed: when using the --painter circles, the equivalent of 100% radius is determined by the minimum of the image width and height, instead of the maximum. This fixes a problem where circles painted in non-square images could bleed outside of the target area. Thus, it also means output images can be different from previous versions, even if using the same command line arguments and --rng-seed.
• Changed: show proper panic messages when errors occur inside threads
• Changed: a lot of code refactoring: split functions between packages, make some functionality more modular, and generally just make it all easier to extend
• Added: when running, write an output line at least every second, even when no successful generations have occurred
• Added: new --blending-mode parameter to use different "blending modes" (a la Photoshop) when creating new images. This has many new options (normal, multiply, screen, overlay, darken, lighten, color-dodge, color-burn, hard-light, soft-light, difference, and exclusion), with normal being the default. Several blending modes are allowed at the same time; they're randomized in the same way as other parameters are. For example, --blending-mode normal multiply@2 overlay@3 would try using the normal mode 1/6th of the time, multiply 1/3rd of the time, and overlay 1/2 of the time

v0.4.0

This version was aimed at polishing existing functionality, but a few new features were added as well.

Change log

• Fixed: errors when randomizing vertical rectangle positions on non-square images for the "rects" painter
• Fixed: errors during painting on a separate thread properly now cause the application to abort, rather than explode into infinite error messages
• Changed: the printed output is less verbose, as it doesn't write a new line for every successful generation anymore
• Changed: any scale parameter can also be expressed in percentage units; --color-seed 0.5 is the same as --color-seed 50%, for example
• Changed: new internal PRNG module to allow for deterministic randomization
• Added: new --rng-seed parameter that can be used to seed a new pseudo-random number generation and get repeatable images. The used seed is printed in the terminal and added to the generated file as metadata
• Added: new --margins parameter that allows setting side margins of the generated image. Values can also be negative to allow for bleeding
• Added: all parameters that take values for randomization also allow a "weight" value via @. For example, if you want to use painter widths of either 10px and 20px, but to use wider ones 5 times more often, you can do --painter-width 10 20@5 to give a "weight" of 5 to the value of 20 (in other words, the width will be set at 10 1/6th of the time, and to 20 5/6ths of the time). The default weight for values without one is 1.
• Added: new -d/--diff parameter to set a target percentage for image generation; this takes a float value or a percentage
• Added: when printing the output, we also show an estimate of how much time is left for the generation to end based on target parameters when using -d/-diff, -t/--max_tries, or -g/--generations

v0.3.0

This versions adds a few features that have been on the pipeline for a while: adding generation statistics metadata to saved images, more control over color alpha randomization with a bias parameter, and the ability to generate images faster with a new color seed parameter (which is a bit of cheating, since it means painters are not completely random anymore).

Change log

• Changed: code refactors for image saving from the separate "files" module
• Added: new --color-seed input parameter to determine how much of the "target" image color to use when picking a new random color; 0 (the default) means the new color will be completely random, 1 means the new color will come from the target image instead, and everything in between blends the two. Target colors come from a single location; for example, when using the circle painter, the target image comes from the circle center. This can produce more accurate generations faster, but is a bit of a "cheating" mode since painters won't be painting blindly anymore
• Added: new --painter-alpha-bias input parameter to control bias of random alpha distribution (default 0, linear distribution)
• Added: saved images also have metadata appended to them with generation statistics (number of tries, generations, time spent, final diff, etc) as well as command line parameters
• Added: new --no-metadata input switch to disable writing image metadata

v0.2.0

Concurrency! This new version finally makes use of multi-threading when generating images. Now, instead of using a single code path that tries to paint a new "candidate" per iteration (which might or might not get discarded, depending on whether it improve on the current image), the application can use an arbitrary number of candidates per iteration. When doing so, whatever candidate image gets the best results is used for that iteration; all others are discarded.

The number of candidates can vary. By default, the application now uses the number of logical CPU cores of the computer when running for that. On a modern computer, this is usually between 4 and 8 cores, so it's likely any run will have 4-8 candidates per iteration, running in parallel to each other. This is enough to improve the speed of successful generations by cutting its running time to about half of what it would be with a single core. More candidates can be used with the --c/--candidates switch. A higher number of candidates can cut down on generation time even further, at the cost of more CPU and memory use.

For example, while trying to generate 1000 random squares on a 512x512px image, this was the result:

• With --candidates 1: 103319 iterations, in 151 seconds
• With --candidates 12: 10501 iterations, in 74 seconds
• With --candidates 30: 5070 iterations, in 68 seconds
• With --candidates 150: 1960 iterations, in 54 seconds

This is not a silver bullet; using multi-threading requires that image data is passed around between threads. This data copying takes time, and in some cases, depending on the number of candidates and size of final image, this could actually make the whole process slower. So consider this something to play around with; it's likely each situation will benefit from a different number of parallel candidates, if at all.

Because of this, in case the number of candidates passed is 1, all generation is done in the main thread, without concurrency. This replicates the old behavior, and is somewhat tweaked for high performance (using 1 separate thread with the new system would be slower).

Finally, it's likely that this process is lacking some optimization, and that some data is being copied more often than it should. My hope is that future updates will improve on multi-threaded performance and memory use.

Change log

• Changed: small code refactors for succinctness
• Changed: command line help for matrix examples is more reliable
• Changed: updated image create to latest
• Added: new -c/--candidates input parameter for additional candidates during each try (defaults to number of logical processors)

v0.1.0

First stable release.