asura

That's weird. The performance tests I did on the separate parts promised some gain, but when I put the whole thing together it actually works a little slower with my test image. Memory usage is lower, but the number of GC collections stays the same. I guess there are some other forces at work... Since it doesn't improve at all I've kept the code as it was. So no new upload, sorry.

Hmm, I've tried the static cache, but then it isn't 'clean' when the Render method is called. The image still renders in a recognizable way, but it gets polluted with noise from previous renderings. Cleaning the cache by resetting all its elements at the start of the Render method pretty much cancels out the static cache gain. However, when I change the ColorError class to a struct it gets much faster even when I'm creating new caches every time the Render method is called. The structs are created much faster than classes, and they're instantiated automatically when I create an array. Since the default value happens to be exactly what I need, I don't need to loop through the array afterwards. According to my profiler the Floyd-Steinberg calculations are also twice as fast. I did some performance tests with arrays of structs and arrays of classes , and the structs turned out to be much faster then the classes, with half the number of GC collections as well. An array with just one struct isn't much faster than an array with one class, but it gets better with bigger arrays. With 10000 elements it's 4 times faster, with 500000 elements it's 80x faster. So, that sounds like a gain. I'll upload a new version later today.

Thanks for your constructive input I was already happy that it was faster than the 'Edge Detect' filter, which I think is a technically similar effect. Where do you think I could gain a bit, 50% still sounds like a lot. I know it isn't, but you've got my curiosity triggered. Pointers for navigating through the cache as well, or something like that? Or throwing in some threads for the rois that need to be rendered?

I don't have any experience with more than one core at a time. I always assumed that the cores would work together by sharing at least some the memory. Oh well, learning moment... Anyway, I've kicked pretty much everything out and started again. It's now only using its source and destination surface, assisted by a much smaller buffer, just as big as the width of the image. Memory impact will be much lower. I've tested this with a 4000x5400 image: Loading the image increased memory usage by 176MB. Starting the effect made it increase by another 92MB (which it does with any effect, not just this one). During processing memory usage grew with about 5 or 6MB and it dropped back when it was done. I found that my original code was rather slow on larger images, so I also made the processing loop more efficient using pointers instead of the surface indexers. On the test image it took about 11 seconds. The previous version would've taken a few minutes probably... And since I was busy anyway, I also documented the code The dll and source are available at the original locations.

I've uploaded the corrected code and dll. It's still cloning, but now it's cleaning up after itself as well. Asura

:oops: I had some troubles getting my code to run properly in CodeLab. The problem was that the dithering needs to apply changes to the source surface, and in CodeLab it seemed to apply the effect twice. By cloning it I was able to get around that problem, but I forgot to dispose the copy afterwards. Or can I just apply the changes to the source surface without disturbing any code outside my plugin? Regards, Asura

Simple plugin, no options, just run it on an image or a selection. You might want to adjust contrast or levels before running this plugin for better results. The example above was dithered without any prior adjustments. Copy the dll into the effects folder to install it. Source: <no longer available - EER> Download