I’l suggest adding a > at the beginning of the expression:
f. ">begin(X=0);X = xor(X,i)"
because if your image becomes quite large, there is a risk the command fill decides to enable multi-threaded evaluation, and in this case, you cannot be sure the evaluation follows a scanline order.
For instance, this simple example exhibit a difference on my machine :
(the first image has been filled using 4 cores simultaneously, so not in a scanline order).
The second image is correct, using > ensures you evaluate in a scanline order.
I’m working on a pre-processor/lossy PNG optimiser.
Dithering is not very good for PNG compression but does really help with visual quality, so I am producing dither that is only horizontal lines. It’s a compromise between compression and visual quality.
The issue I am having is that there are discontinuities in the dither pattern cased when the error between the quantised image and the original jumps from a big positive value to a big negative value.
What you get is effectively a change from white lines on black to black lines on white. Detecting the change is easy enough (there a big step in the error) and then it just a matter of switching he dither pattern so all the lines are lined up.
That works great horizontally, but it introduces problems vertically because in some places you have you get two dither lines of the same colour on top of each other creating 2 pixel lines instead of 1 pixel lines. Oh well.
Well I’ve managed to get ‘better’ results by manipulating the error signal. Unfortunately, while it looks better on smooth areas, it makes the compression slightly worse