Hello again Alex

Your driver for ps3eye now seems to be even better than linux version, great work!

Recently I was reading about professional and expensive cameras and noticed some nice feature:
hardware ROI (region of interest). Programmer is able to set smaller movable active sub-window,
and the camera transmits only this region. Using this feature one can focus on some
region and achieve better frame rates, shorter exposure times, reduce required bandwidth, etc.

Reading ov7620 data sheet noticed fragment about “Window Sizing”
and registers: “Horizontal window start / end”, “Vertical window start /end “.
Maybe it would be sufficient to write some values to this registers.

Do you think I would be possible to add such feature to your SDK?

Best regards,

The OV7720 supports only 1x1 and 2x2 pixel binning modes. Hardware ROI is possible but this will reduces the effective camera viewing angle and will not result in any frame rate speedup.

Yes, I don’t expect increasing frame rate beyond 60 fps at 640x480 resolution,
but I really suspect this could help in synchronized light case.
I was able to achieve usable results using better lens and shorter exposure times,
but only at 30fps VGA mode. Possibly using 50 or 60fps could be achieved by limiting number
of rows using hardware ROI. I conclude it from the fact that without ROI, half of the screen is
correctly seen in difference image. Using 1/3 of rows in ROI should solve the problem.
It does limit viewing angle, but for tracking small objects and
using movable ROI would be acceptable.

I could test this idea under linux , by tweaking camera driver if it would help.
Anyways this feature is found in pro cameras probably not without good reason.
What do you think?

Yes, that’s the idea I was experimenting a while ago. Reading only a portion of the sensor, will allow for line exposure to be contained within the single frame by ignoring the lower part of the sensor. In the case of QVGA image size, the exposure must be <240 which is not bad, but for higher frame rates this would mean less light being detected by the sensor. This of course will require brighter input lights to be tracked, so high voltage LED/Laser pulsing is a must.

thanks! so it seems it’s at least worth trying.

Could you recommend some windows usb library I could use to
peek/poke camera registers? Maybe libusb-win32 or
microsoft winusb? It should be possible without kernel driver
support like in WcCtrl used in astronomy.

You might try some of those libraries/frameworks but considering that you are dealing with USB 2.0 transfers, you must be careful cause these are typically user land ‘drivers’. Meaning, dropping data will be your main issue here. Ideally you would want to write a kernel mode driver for this purpose.

Actually I do not intend to rewrite all USB 2.0 transfer functions, which would be very hard indeed.
I was only hoping to write some functions to update “Vertical window start /end “ registers,
and rely on your driver to do the rest. Do you think the driver will function correctly
after narrowing active window from 640x480 to say 640x200 ?

Any success in using the hardware ROI? I need it for vision of a robocup robot.