Image Dithering

An "algorithm" is just a method - so it would not be specific to any particular platform.

Look at the Floyd Steinberg algorithm for error diffusion. It keeps track of the error and forwards the error to comming pixels. It is most commonly used when going all the way to one-bit pixels but gives nice result with higher color resolutions too.

It is a fast algorithm in comparison to algorithms that uses a random or pseudo-random round-up/round-down. You can do it in-place with two extra scan lines stored in memory.

But as mentioned - this is general algorithms, so it doesn't really matter if you have an embedded platform or a specific chip.

I guess that there are many algorthm exist for PC

No. They're algorithms for every platform. They don't exist "for" the PC any more than your local electricity company exists "for" you.

would like to perform it on arm with limited resource.
I don't care about dithering algorithm's efficiency,

Hmm... now you're contradicting yourself from one sentence to the next. As a matter of fact, your current ARM CPU is quite likely faster than PCs were for the first decade of their existence. And dithering has been around for quite a while before that...

In other words, you're asking the wrong people. You should be consulting books or other resources concerned with computer graphics in general. The fact that you're doing this on an ARM is quite irrelevant to the issue at hand.

do this in matlab with image processing toolbox.it's a piece of cake in matlab.
if you want to port the code into MCU.do the following:
reimplement the algorithm with embedded matlab function.
covert the code into c src code with embedded workshop
it's not that hard.

The source code for a number of dither or error diffusion algorithms can be found with a very short trip to Google. A number of them can probably be decided to be free implementations, or have a nice enough license - especially since the actual algorithms aren't protected.

The main task for an embedded application (or a PC program) is what binary format the image comes in. Is it a raw array or is it RLL-encoded or huffman-encoded... Does it contain header information with resolution, color depth etc that may possibly change because an external camera gets reconfigured, ...

Matlab is a fun prototype tool but in this case the logisitcs decisions are so very much harder to handle than the actual image data processing. And another thing: Matlab isn't designed with the knowledge that the target has way less memory than a PC. The Matlab algorithms are probably written to be very efficient with relation to cache lines of a high-end processor but that may not be the primary concern for an embedded device.

for matlab RTW, the code generation is controlled by the user. it's quite more than just "a fun prototype tool" and meets the middle (such as hcs12) to high end processors (mpc or arm) code generation. You can also direct the target library, which will be more efficient to generate the code.

Currently, lots of embedded applications are benefited from the code gen technology, especially in automotive.

I guess for this application, a DSP or or other 16/32 bit MCU with hw/sw DSP functions may be applied.

Have you looked at the amount of code that is needed to extract the image data from a png or jpeg image?

Have you looked at the amount of code that is needed to perform error diffusion for limiting the color depth?

What was your initial thought about the amount of code for the two tasks?

When all you have is a hammer, everything around you tends to look like a nail. The quality of the code Matlab can generate isn't really relevant if the majority of the problem is to implement networking code that receives data from a webcam, and decodes the actual image data. The dithering step may be less than a percent of the application. That might mean that it is better to decide what tools are most suitable for the other 99% of the application - especially since

Matlab is an excellent tool but in this case the algorithms requested are quite simple.