strange behavior with set_windowing

Discussion related to "under the hood" OpenMV topics.
User avatar
aakoch
Posts: 24
Joined: Wed Dec 06, 2017 11:07 pm

strange behavior with set_windowing

Postby aakoch » Fri Apr 20, 2018 10:35 pm

I don't know if it is my camera only, but I am getting strange behavior ("behaviour" for you non-Americans :P ) 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
odd_width.jpg (5.07 KiB) Viewed 1395 times
Secondly, with some even-numbered widths the image jumps around, for example if I use 20 pixels.

Code: Select all

sensor.set_windowing((10, 0, 20, 120))
20_px_width.jpg
20_px_width.jpg (1.4 KiB) Viewed 1395 times
I have a video (with the newest version of the IDE! :D ) 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:

Code: Select all

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:

Code: Select all

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.
User avatar
aakoch
Posts: 24
Joined: Wed Dec 06, 2017 11:07 pm

Re: strange behavior with set_windowing

Postby aakoch » Fri Apr 20, 2018 10:59 pm

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

Code: Select all

> file snapshot-966393929.jpg.bmp 
snapshot-966393929.jpg.bmp: PC bitmap, Windows 3.x format, 320 x -240 x 16
User avatar
kwagyeman
Posts: 2467
Joined: Sun May 24, 2015 2:10 pm

Re: strange behavior with set_windowing

Postby kwagyeman » Sat Apr 21, 2018 12:21 am

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/m ... lib.c#L323

SO, that's weird behavior. It should have figured it out...
Nyamekye,
User avatar
aakoch
Posts: 24
Joined: Wed Dec 06, 2017 11:07 pm

Re: strange behavior with set_windowing

Postby aakoch » Sat Apr 21, 2018 12:48 am

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

Code: Select all

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:

Code: Select all

> file /Volumes/NO\ NAME/name.jpg.jpg 
/Volumes/NO NAME/name.jpg.jpg: data
User avatar
kwagyeman
Posts: 2467
Joined: Sun May 24, 2015 2:10 pm

Re: strange behavior with set_windowing

Postby kwagyeman » Sat Apr 21, 2018 2:38 am

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.
Nyamekye,
User avatar
kwagyeman
Posts: 2467
Joined: Sun May 24, 2015 2:10 pm

Re: strange behavior with set_windowing

Postby kwagyeman » Sat Apr 21, 2018 2:39 am

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.
Nyamekye,
User avatar
iabdalkader
Posts: 634
Joined: Sun May 24, 2015 3:53 pm

Re: strange behavior with set_windowing

Postby iabdalkader » Sat Apr 21, 2018 2:10 pm

Hi, the image width*2 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 (8*2 == 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.
User avatar
aakoch
Posts: 24
Joined: Wed Dec 06, 2017 11:07 pm

Re: strange behavior with set_windowing

Postby aakoch » Sat Apr 21, 2018 3:17 pm

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? https://github.com/openmv/openmv/issues/272
User avatar
kwagyeman
Posts: 2467
Joined: Sun May 24, 2015 2:10 pm

Re: strange behavior with set_windowing

Postby kwagyeman » Sat Apr 21, 2018 6:14 pm

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.
Nyamekye,
User avatar
iabdalkader
Posts: 634
Joined: Sun May 24, 2015 3:53 pm

Re: strange behavior with set_windowing

Postby iabdalkader » Sat Apr 21, 2018 8:13 pm

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).
User avatar
kwagyeman
Posts: 2467
Joined: Sun May 24, 2015 2:10 pm

Re: strange behavior with set_windowing

Postby kwagyeman » Sun Apr 22, 2018 11:37 am

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

Return to “Technical Discussion”

Who is online

Users browsing this forum: No registered users and 3 guests