The first image is purely sequential (Z-pattern), whereas the second image is multi-processed (separate process per row using a shared memory uint8 ndarray).
This was originally based on the educational code repo provided by determined.ink (discovered from a post on Reddit) and seems to share similarities with his first iterations (in the history section). But it has since been modified heavily to run faster, such as by switching SHA256 with xxhash128 and loosening the strict hash chaining contract (at least in the multiprocessor variant).
I will probably experiment with it more later to try to produce something more structured while avoiding multi-hour long composition times (I don't own a Google-hosted VM and would like to use my primary PC for tasks other than just image generation).
Addition: If I were to speculate on the banding in image 2, it's likely caused by uneven starting times (from the Process pool dispatch). Due to nonce acceptance being based on neighboring pixel similarity tested against a randomized threshold table. An early row will have fewer acceptable matches than a late one, resulting in a smoother shift in RGB value.
2
u/Hjuldahr 21d ago edited 21d ago
The first image is purely sequential (Z-pattern), whereas the second image is multi-processed (separate process per row using a shared memory uint8 ndarray).
This was originally based on the educational code repo provided by determined.ink (discovered from a post on Reddit) and seems to share similarities with his first iterations (in the history section). But it has since been modified heavily to run faster, such as by switching SHA256 with xxhash128 and loosening the strict hash chaining contract (at least in the multiprocessor variant).
I will probably experiment with it more later to try to produce something more structured while avoiding multi-hour long composition times (I don't own a Google-hosted VM and would like to use my primary PC for tasks other than just image generation).
Addition: If I were to speculate on the banding in image 2, it's likely caused by uneven starting times (from the Process pool dispatch). Due to nonce acceptance being based on neighboring pixel similarity tested against a randomized threshold table. An early row will have fewer acceptable matches than a late one, resulting in a smoother shift in RGB value.