strange behavior with set_windowing

OpenMV Products
#1

I don’t know if it is my camera only, but I am getting strange behavior (“behaviour” for you non-Americans :stuck_out_tongue: ) in a couple of cases.

The first case is if I use an odd number for the width in the ROI of the set_windowing method, there is some strange distortion.
odd_width.jpg
Secondly, with some even-numbered widths the image jumps around, for example if I use 20 pixels.

sensor.set_windowing((10, 0, 20, 120))

20_px_width.jpg
I have a video (with the newest version of the IDE! :smiley: ) that I can upload if you want to see it.

It doesn’t seem to matter if I use color or B/W or change the frame size.
Anyone else seeing this issue?

Here is my code I’m using to reproduce the issue:

import sensor, image

sensor.reset()
sensor.set_pixformat(sensor.RGB565)
sensor.set_framesize(sensor.QQVGA)
sensor.skip_frames(time = 2000)

sensor.snapshot()

for i in range(1, sensor.width()):
    roi = (0, 0, i, sensor.height())
    print(roi)
    sensor.set_windowing(roi)
    sensor.skip_frames(time = 1000)
    sensor.snapshot()

I also want to say that I am having issues with the img.save() method. It always seems to add a .bmp extension to the file.
This:

img.save("snapshot" + str(pyb.millis()) + ".jpg", quality=50)

produces files such as “snapshot2827052.jpg.bmp”.
I’m not sure if my app to view the image is just looking at the file headers to display it correctly because I can open it with .bmp or without it.

#2

For the file saving issue, yes, it is a bitmap.

> file snapshot-966393929.jpg.bmp 
snapshot-966393929.jpg.bmp: PC bitmap, Windows 3.x format, 320 x -240 x 16
#3

Hi I would only use the set windowing command once right now on startup. The way it’s implemented needs to be updated (on my list of things to do soon). As for the bmp issue. Do this first:

img.compress(quality=90).save(“name.jpg”)

Note that save takes ROI values for the BMP files. It should be able to crop the image for you. Here’s how save figures out the file:

https://github.com/openmv/openmv/blob/master/src/omv/img/imlib.c#L323

SO, that’s weird behavior. It should have figured it out…

#4

Even with setting the windowing only once on startup gives me that weird output.

import sensor

sensor.reset()
sensor.set_pixformat(sensor.RGB565)
sensor.set_framesize(sensor.QQVGA)
sensor.set_windowing((10, 0, 20, 120))
sensor.skip_frames(time = 2000)

while(True):
    sensor.snapshot()

When I try to call .compress() before .save() I can’t open the file. I reset the camera and the file is there but I get an error:
The file “name.jpg.jpg” could not be opened.
It may be damaged or use a file format that Preview doesn’t recognize.

Oh, yeah, it appends “.jpg” onto it.

And when I try to get info on the file I just get this:

> file /Volumes/NO\ NAME/name.jpg.jpg 
/Volumes/NO NAME/name.jpg.jpg: data
#5

Okay, I see why it appends the .jpg. I think a bug was introduced here. Specifying the .jpg right now causes it to assume you didn’t add an extension. It looks like a switch statement was changed…

To fix the saving issue just leave out the extension:

sensor.snapshot().compress(quality=90).save(“example”)

Um, so, a bug that I added to the IDE. When you click the “Save script to OpenMV Cam” button I do a write of nothing to the disk to flush stuff from the desktop OS. However, this overwrites whatever the camera saved losing you data. Please just unplug the camera from the PC after saving files until the next OpenMV IDE release hits.

…

As for set windowing, it looks like that is bugged. There’s already a bug in the github on this. Please add to it. It looks like the window has to be some multiple of the frame width and res for it to be okay. This should not be required. I will fix.

#6

Can you make bugs on the github for these things?

Sorry about this… both of these are old code that hasn’t been touched for a while.

#7

Hi, the image width2 should be a multiple of 16 bytes to work with the current DMA transfer size configuration (burst of 4 * 4 bytes). Which also means the minimum width is 8 (82 == 16 bytes). We should probably check for these limitations. There’s a way to fix this, make the DMA transfer size smaller but this will result in more transfer requests.

#8

Does this mean the windowing should be in multiples of 8px?
You say you could fix this but I wasn’t sure if your comment about more transfer requests means we shouldn’t.

Is this the windowing ticket you want me to update? set_windowing doesn't work · Issue #272 · openmv/openmv · GitHub

#9

I will just make the sensor driver do a virtual window without whatever the HAL is doing. We write all pixels from a temp line buffer to the main frame buffer anyway so there’s no need for this limit if it’s done in software.

#10

Does this mean the windowing should be in multiples of 8px?

Yes for now.

@Kwabena

I will just make the sensor driver do a virtual window without whatever the HAL is doing.

I was also thinking of just adding a window to the sensor struct, we would have make sure it doesn’t break something else, so maybe not for the next release, but it should work. However, note that JPEG code also assumes the width and height are multiple of 8 (pixels).

#11

I already did this to support windowing for the Lepton driver. So, we can have this support in for the release after next.