Redid the phase correlation code again so it's one method call now. This
method call can either do logpolar phase correlation to get rotation/
scale or translation(x/y). Additionally, it will be able to also do both
at once. However, I don't have that quite working yet.
I've updated the example scripts to reflect the new code too.
Finally, I had to fix a bug in the rotation correction code.
...
Once I've got the full pipeline working I will post scripts for that. I
have all the code in there and it's been somewhat debugged... However, I
can't get a useful phase correlation lock out of the log polar fft mag.
I plan to look into noise filtering and spectral whitening solutions for
this.
This commit updates the shadow free invariant image to 2 colors from
just grayscale.
If we need to save ROM room in the future we'll just disable the LUT and
have the algorithm run with the regular C code. Right now this is not an
issue.
Someone asked me about doing a field of receptors before. These scripts
show how to do that. Also, added example scripts for calling the linear
polar and log polar methods added previously which power
find_rotscale().
Just doing one big commit/PR here since I noticed that breaking it up
causes issues.
Anyway, these fixes give us GOOD/WORKING/FAST optical flow now on the
OpenMV Cam M7. A number of changes were made to the optical flow
scripts. You have have absolute and differential estimation example
scripts. Additionally, you also have the ability to measure rotation and
scale changes too. Linear/Log Polar conversion was added for this. Users
may use the new code for generic image manipulation too. Finally, I
updated the power of 2 resolutions since you actually HAVE to use them
with optical flow for the phasecorrelation code to work correctly.
I have some more advanced scripts coming after this. But, This commit is
already getting kinda large so I'm stopping it here.
* Added hmirror and vflip support to the MT9V034 and example scripts.
* Moved sensor example scripts to one place.
* Add delay to these script for register settling time.
* Textual register cleanup.
No functional changes.
* Add exposure control support.
You can now set the exposure for the camera in microseconds (versus an
opaque unknown value previously). First, we have a new method called
get_exposure_us() which will get the expsoure time in microseconds. This
let's you determine what the auto exposure algorithm set the exposure
time to. Second, the previously implmented set_auto_exposure() method
which allows you to turn aec off and on accepts a exposure_us keyword
argument when you turn aec off to manually control the exposure.
The next commit will add support for other sensor types.
* Cleanup register formatting.
No functional changes.
* Add exposure control support for the OV2640.
Register access for this chip is a PITA.
* Formatting Cleanup.
No functional changes.
* Add exposure control for ov9650.
Just doing it for all sensors.
* Add missing 2 factor.
* Added exposure control for the MT9V034.
* Add exposure control example.
Works well on the OV7725.
Just updating the code with the same style as other methods. I have
another new sister method for histeq() comming up next which I'll push
as soon as this PR is done. Didn't want to merge the two into one PR.
This fix allows "copy_to_fb" with a different resolution than the
current frame buffer to work. It also allows the frame buffer to be
resized, etc. In particular, the pooling methods I added for optical
flow work again... you'll also be able to scale the frame buffer too.
You can now allocate an extra frame buffer for storing images. However,
this takes memory from the main frame buffer. In particular this reduces
the RAM for many methods that do image processing making memory errors
more likely to happen. Note that you may allocate as many extra fb's as
you like. Dealloc happens in reverse order.
Anyway, you can use this method to now storage things like difference
images in RAM allowing for MUCH faster frame difference image
processing.
Moving on, to keep memory management sane... the second fb looks just
like an image and you can use all the image methods to load and update
it, etc. That said, if users deallocate the second FB they need to *NOT*
use the image pointer anymore. There's no way for me to delete the image
pointer in python right now so this is just something that has to be
manually managed (even if I did setup a deconstructor the second FB is
on a stack... so, things wouldn't work so easily with that).