for (var i = 0; i < this.img.length; i++) {
this.update(i);
}
this.commit();
this.iterateCount++;
This code has a nasty side effect. Because the commit updates the parameters, AFTER the colors have been synchronized to the image, it's possible the image has chosen colors from an older iteration of parameters. This causes some pixel export errors that used to go unnoticed (until the asserts I added started to fail). The reason is that the translation into image cell blocks needs to pick a pixel pattern to match the colors selected. If the colors don't match then the pixel pattern chosen can mismatch and lead to garbage coloring. This error amount is small but it exists.
The Intellivision branch fixes this issue by making the commit happen prior to the update. This ensures
the params are chosen and the image reflects the chosen params. There is a side effect to the fix though. The dithering error amount is one iteration less than before (meaning a bit less error by default). I suggest the default values be retweaked rather than leaving the bug in place.
Another interesting side note: on the C64 Hires, I noticed that if left this bug in place and did NOT perform an initial commit on the canvas prior to this loop, the colors would get muted and instead the image became a mostly black and white image, which only the most important colors coming though. For the parrot, it was beautiful. No setting I played with came close to reproducing this result. This makes me think we might need a few more dithering options. I think the reason why it worked is because the colors didn't get iterated with enough error and the palette was still mostly dithering from black and white. In other words, the colors were both muted and vivid at the same time, like watching a black and white movie except that a single rose would be colored in a scene (a reference to Pleasentville).
Anyway, if there are ideas how to allow the settings to reproduce this result, that would be wonderful. I'll try to recreate the "bug" and attach an image at some point.
This code has a nasty side effect. Because the commit updates the parameters, AFTER the colors have been synchronized to the image, it's possible the image has chosen colors from an older iteration of parameters. This causes some pixel export errors that used to go unnoticed (until the asserts I added started to fail). The reason is that the translation into image cell blocks needs to pick a pixel pattern to match the colors selected. If the colors don't match then the pixel pattern chosen can mismatch and lead to garbage coloring. This error amount is small but it exists.
The Intellivision branch fixes this issue by making the commit happen prior to the update. This ensures the params are chosen and the image reflects the chosen params. There is a side effect to the fix though. The dithering error amount is one iteration less than before (meaning a bit less error by default). I suggest the default values be retweaked rather than leaving the bug in place.
Another interesting side note: on the C64 Hires, I noticed that if left this bug in place and did NOT perform an initial commit on the canvas prior to this loop, the colors would get muted and instead the image became a mostly black and white image, which only the most important colors coming though. For the parrot, it was beautiful. No setting I played with came close to reproducing this result. This makes me think we might need a few more dithering options. I think the reason why it worked is because the colors didn't get iterated with enough error and the palette was still mostly dithering from black and white. In other words, the colors were both muted and vivid at the same time, like watching a black and white movie except that a single rose would be colored in a scene (a reference to Pleasentville).
Anyway, if there are ideas how to allow the settings to reproduce this result, that would be wonderful. I'll try to recreate the "bug" and attach an image at some point.