Has a bias value that allows you to control if its really a midpoint,
min, max filter, or something inbetween. Run at 160x120 or lower. 320x240
is slow (seems to be the case for all convoltions at that res).
Added setters for these camera settings. AWB is necessary for color
tracking to work correctly. AGC still runs, which causes lighting
shifts. It may need to be disabled too. Not sure... if I want to do that
or not however, because without it lightning won't get normalized to
remain at a certain level. So, turning AGC off may cause issues in other
ways.
First, a few things:
The MLX 16x4 sensor has just too low of a resolution for mass appeal for
the price. The product is not going to sell very well. We need to look
into supporting sensors with a better res. Like the FLIR 1. The MLX
module was renamed to the "flir" module with this idea in mind.
The flir code now takes care of doing scaling and blending itself. I did
this to get rid of the user having to scale the image themselves and
blend themselves. Its too easy to run out of memory given our current
ultra small heap. In general, anything that requires multiple images in
RAM has got to go. When we do another OpenMV Cam with external RAM in
the MB range then maybe such functions will be safe. But, right now they
are definately not.
Anyway, moving on, I fixed a few bugs with the MLX math code. But, for
the most part was correct. I also added reconmended polling code for
brownouts as required by the datasheet.
Last, I designed this code like the LCD code to support a type value
when inited. This will allow the system to user a different sensor in the
future without any API changes to the user.
I will add test scripts for this next. Basic usage follows:
import flir
flir.init()
flir.display_ir(sensor.snapshot())
And that's it. Super easy. If the user wants the raw temp values they
can use flir.read_ir() to get the ta and to values. The display function
has a hidden alpha and scale argument for controling blending and the
min/max scaling.
The previous way we worked out scaling kinda sucked... it was a good
shot, but, controllable min and maxes that autoscale by default just
work better. If the user knows the temp range then they can just set the
min and max.'
Anyway, longest commit ever done.
File reading is runing ultra fast now. We're getting that SD card speed
the STM32 promised now. The file buffer commands have been updated to
alloc as much available memory to read as much of a file in as possible
now to speed up things. This works really great.
Note however, while the file buffer is active you have to use the file
buffer versions of tell and size. Spent a few hours on tracking down an
error related to not using the buffered versions.
All file write functions now use fb_alloc to go much faster. Writes are
re-directed to the extra frame buffer RAM and are grouped until they can
be written in a massive multi-block write to the SD card. We get the
best SD card write speed by doing things this way.
Ideally we'd want to buffer the whole file... but, this is about as good
as we're going to get for now.
Going to fix reading functions to use the same buffer next.
The built-in mjpeg module allows you to record videos seamlessly. It
will automatically compress the frame buffer using the extra space in the
main ram. So... you don't have to pass it jpeg images. Gets 7 FPS at
320x240 while connected to the computer too (it has to compress the
frame twice in this situation).
Anyway, the module work like Gif.
Now you can just grab all the free ram in the frame buffer in one go.
This fixes problems figuring out how many lines to alloc. Will update line
op code with this new info later.
Color gifs look very good for how bad you'd expect them to be with just
7 bits of color (rgb232) - quite amazing. Also, I hardened the gif
module to make it "user ready".
You can now get the color stats for an area in the image. The stats
function returns the mean, median, mode, min, max, st_dev,
lower_quartile, and upper_quartile.
This function allows you to automate binary and threshold functions
based on what's in the iamge.
The morph function lets you convolve the image with a kernel. It's
decently fast right now. But, in the future we'll have to optimize it by
a lot (unrolling loops, using SIMD instructions, etc.).
Anyway, along with morph I added an edge detection test script showing
how you can use a high pass filter on an image to get all the edges in
it. This is not as good as canny edge dection... but, it's about the
same and fast enough.
We'll need a Hough Transform system in the future to make edge dection
useful. Not sure how that will be implemented... so, that's going to be
far away for now.
The old code did not actually implement the errode anhd dilate kernels
correctly. However, it migh have been a little faster because it avoided
the boundary problem.
In the future we can optimize all the kernel code to have different loops
for doing the edges of image versus the center. But, for now, this is
good enough. QVGA color tracking with kernels will be slow, but, the
speed can be improved with QQVGA resolution. Using a 3x3 kernel is
plenty fast. Larger ones are slower.
I also added the ability for you to set the threshold for erode and
dialte. This lets you make the kenrel a little bit smarter so that it
won't errode or dilate a pixel unless the threshold is met. Meaning,
you'll be able to use erode to erode an image down to 1 pixel wide
lines.
All the work previously has been more or less leading up to supporting
this function. The line op function will open a file and execute a
function pointer on each line of the file opened to modify the frame
buffer.
It now figures out the file type from the file extension. If no file
extension is given it just saves the file as BMP if its not a JPEG image
or JPEG if it's a JPEG image. If you specify an extension and the file is
not of that type then it will give you an error.
The new test_save.py should run until you reach the JPEG image part
where it quits due to lack of JPEG support natively on OV7725 boards.
Maybe JPEG mode should be supoorted by just compressing pictures?
There's not a lot of actual functionality changes from the last commit.
However, switching the basic wrapper library to just long_jump on
failure and moving all the state info to structs required changes to all
the base functions in the last commit. The rest of the changes are to
link in the new functionality and to get the code to compile (usbdbg.c
edits).
Next I'll work on a function which abstracts the problem of opening an
image up and executing a line by line function op on it. I already
worked the code out for that. But, it's not in this commit to keep
things streamlined.
* With the new integral moving window we can support face detection,
keypoints and template matching on QVGA frames. However, it was only
implemented and tested for face detection.
* Increasing the max integral frame now for easier testing.
Fimrware will now automatically detect the appropriate file type and read
in that file type correctly.
Working on tying on of this stuff togheter next. It's getting a little
bit too complicated to deal with error cases. Need to add error message
function layer.
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.
* Use a scanning factor proportional to the current scale.
* Use the new integral moving window to allow two integral images
(sum and sum squared) for fast mean, variance and standard deviation.
* Higher FPS and more accurate detection.
* A new integral image implementation that uses a moving window.
* Integral image is computed in steps, each shift computes n new lines.
* This only requires (image_width * (feature_height+1) * 4) bytes.
* Allows Haar detector to run on QVGA, and allows a second squared
integral image for standard deviation calculations.
The alloc functions allow you to use the framebuffer as a storage space.
It's very simple but effective. You can alloc which puts some memory on a
stack... and then when you're done you can free which pops the stack.
Pops (frees) must be done in reverse order of pushes (allocs).
In general, functions should call the init code before using the stack.
It could be in a bad state.
Also, I added some wrappers for file system functions to make that stuff
easier. This will be used in the future.
With new RGB565<->RGB888 scaling. This included redoing the LAB/YUV/XYZ
tables. I translated the table gen code to python also and added
comments as to where the math came from.
And yes, I tested and compared the tables to make sure they weren't
borken. The tables are slightly different... but, if look at the
progression of values loosely you'll see the triplets are very close to
each other when doing a compare. This is to be expected given I used a
slightly better scaling algo.
And modified the rainbow table so that the RGB888 to RGB565 translation
is done using a rounding technique versus hard floor. This is also used
for the RGB565<->RGB888 LUTs.
Additionally, I added a bunch of stuff to the image library to make
working with images easier. I will using these helpers in the future.
Finally, I cleaned up trailing space in the font stuff (pet peeve).
Point didn't need many changes. However, for rect I made the merge
function alot better so it won't alloc while merging, just free.
Additionally, I added a function to get the intersecting rectangle of an
image. This will be used for all functions that accept a subimg
argument. This function allows the user to basically pass any wild and
crazy rect they want and the function will find the intersecting area (if
it exists) and return just that to operate on. This is good for "do what
I mean" functionality versus "do what I say".
There were a lot of missing features in the array module. I added
quicksort based on the MP sort function and I expanded the array code so
you can do stuff like take() which lets you get an object from an array
and easily put it into another array.
I also fixed the "struct array" problems in the code. Anonymous structs
have to go.
It was previous set to 10 seconds... since the timeout is in ms. Now
it's at 1 second. This represents 100 clocks at 100KHz I2c. Also, I
noticed general call mode was being set for the I2C which is not at all
something we want (the ability to address multiple devices at once).
I tested the changes with all my cameras. No problems. This was 4 units
(2 being the original protos).
0 bytes and don't fail if you do that. Additionally, I added some
comments on behavior. (I studied what the gc functions did extensively
to know the behavior of this stuff). All changes have been tested with
code that does memory allocs.
* Add HAL_DCMI_Start_DMA_MB to allow line by line transfers for
raw frames using DMA double buffering feature.
* This means bigger grayscale resolution that would not otherwise
fit into RAM.
* YUV to Grayscale conversion on the fly (as the frame being read).
* It's possible to perform differencing (and maybe JPEG) on the fly.
* Additionally, FPS for grayscale should be exactly like RGB
(since there's no additional step after capturing the frame)
* Set the address of the DMA transfer to addr + offset to allow JPEG
Compression of the framebuffer without overwriting image pixels.
* This saves 1KBs of stack and conditionals in jpeg_put_bytes/char.
* Add slave address to sensor struct.
* Pass slave address to every SCCB_Read/Write function.
* Pass a pointer to the sensor struct to sensor functions.
* Fix read raw to return rotated ir readings.
* Add refresh rate parameter to mlx_init.
* Rename mlx_read to mlx_read_ir.
* Add mlx_read_ta to return the ambient temperature.
* The LAB lookup is too big for 512K flash, it used to fit
at some point but not after enabling all the needed modules.
* The imlib_rgb_to_lab function is way slower than LAB lookup,
but it's a must to maintain support for OMV1