RGB565 reading and writing is going to be slow. But, grayscale is going
to be going as fast as the system can go.
If Omnivision has just reversed the byte order of data sent to the
camera we wouldn't have this problem for RGB565.
Added BMP file format reading and writing support code and modified the
ppm code to match. Upper level glue code has been left intact to be
altered in future commits.
Tested save() and ppm writing functionality still works. More
comprehensive tests coming soon.
... Kinda concerend that standard image file formats might not cut it for
the speed we'd like to have when using image files in function calls. I
think only grayscale is going to be fast. All other formats require a
lot of prep work.
I think I may modify some of this low level stuff in the future to
autodetect if an entire grayscale image can be read in or written out
in one go to speed that stuff up.
The negate function gives you the ability to negate an image before
running difference on it. The difference function will subtract two images
from each other and return the abs() of the result.
I believe it would have been optimal to work on the RGB565 image in the
LAB color space. However, since we don't have an inverse LAB lut this is
not possible. If we could replace LAB with YUV then that would free up
space to have an inverse YUV table (YUV->RGB).
* Filter functions bypass the default line processing in sensor.c, and pre-process lines.
* Processing is done on the fly, i.e. filters are called from after each line is received.
All the drawing functions have been updated to handle automatic clipping
when drawing offscren and work with both grayscale and RGB565.
Additionally, all functions now accept color arguments.
I've also updated the example scripts with the new functions and tested
them out to make sure they work.
Additionally, I wrote a test suite for the drawing functions to make
sure they work.