IDE framebuffer display corrupted

OpenMV Boards
1

The bottom of the IDE framebuffer display is corrupted. Corruption changes as the framebuffer is resized vertically. (Smells like a decompression bug in the IDE?)

Board H7 Sensor MT9M114 Firmware 4.1.1 IDE 2.8.1 running on Ubuntu 20.04 inside a VM.

Note that test case is running sensor in monochrome transpose vga mode.

Interesting side question. If I ask the IDE to show color histograms. It does even with the sensor in grayscale. Since we are on a system with limited resources, I put the sensor in greyscale to save memory and cycles. In this mode, which parts of the signal path have switched off color?


# Hello World Example
#
# Welcome to the OpenMV IDE! Click on the green run arrow button below to run the script!

import sensor, image, time

sensor.reset()                      # Reset and initialize the sensor.
sensor.set_pixformat(sensor.GRAYSCALE) # Set pixel format to RGB565 (or GRAYSCALE)
sensor.set_framesize(sensor.VGA)   # Set frame size to VGA (640x480)
sensor.set_framerate(10)
sensor.set_transpose(True)         # swap h and v
sensor.skip_frames(time = 2000)     # Wait for settings take effect.
clock = time.clock()                # Create a clock object to track the FPS.

while(True):
    clock.tick()                    # Update the FPS clock.
    img = sensor.snapshot()         # Take a picture and return the image.
    #img = sensor.snapshot().replace(hmirror=False, vflip=True, transpose=True)
    print(clock.fps())              # Note: OpenMV Cam runs about half as fast when connected
                                    # to the IDE. The FPS should increase once disconnected.
2

Hi, if you are using transpose there’s a maximum limit of the resolution that the processor can handle before it falls over. VGA is above that limit. Please use QVGA or lower.

Transpose is an EXTRMELY inefficient operation give how caches and memory access work. While we offer the ability to transpose the image for almost free in the display capture operation it hammers the processor memory bus hard. Above a certain resolution the system is unable to keep up. It’s inefficient because to transpose you are writing 1-2 bytes per cache line flush to RAM versus 32-bytes.

If you’d like to transpose a larger image you must use the img.set(transpose=True) method. This will not be free but will result in the right behavior.

As for why there’s no check/error on going above the limit… well, it depends on the camera type, the image format, processor clock speed, and many other factors. Some camera chips we have work at VGA, some don’t, and now that we support a lot of different H7 clock speeds it’s hard to know when this will work or not.