Eyesis-in-Car GUI mockup
by Stefan de Konink
Tonight I was thinking about what the possibilities are for the driver to actually see what he is shooting and at the same time facilitate appliances such as traveling salesman routing for the fastest shooting experience. I have some other ideas for the ‘main’ screen such as a 2D map with trails where the car has been (or where photo’s were taken). It seems a logical decision to even incorporate a menu to start or stop shooting or see data statistics as well.
I would like to encourage others to come up with other appliances that could be ‘nice’ to have while drive and shooting. Let me give shot: ‘cute girl tag’-button.
Stefan,
While it is not possible to switch between frame resolution without loosing a frame (with the currently used sensors), with Eyesis even an maximal frame rate (5 fps) we are using just 1/3 of the each sensor maximal frame rate, so it is possible to (not with the current code of course) to create sequences Full resolution/full quality (compress, record) -frame wasted-low resolution/low quality (compress, send to monitor) – frame wasted -… and so on. We can also use one stop shorter exposure fro the low res frame and use it in auto-exposure algorithm (camera will react faster to increased light because it will be less overexposed pixels).
Andrey
P.S. Here is what Oleg uses now:
Current version of Eyesis control panel
@Andrey there is absolutely no need for switching framerates. Because as you mentioned we can use the imgsrv to provide us an current frame. Resizing and debayer can be done in the actual application. Obviously not a webinterface.
Stefan,
Yes, you can download images the same resolution at ~10MB/sec (100mbps connection), but that will compete for the memory/CPU resources with the recording. So if you are trying to get the best performance (image quality * frame rate) you need to conserve those extra resources. This is why I suggested to switch to lower resolution.
Additionally, the camogm (recording application) read pointer is reported to the driver and available for other applications too. So it is possible for this viewer to wait refreshing if the video buffer is dangerously full (i.e. when the OS starts a new file for recording).
Andrey
I found these two papers that may help you with this project
http://www.altera.com/literature/wp/wp-01107-stitch-fisheye-images.pdf
http://www.altera.com/literature/wp/wp-01073-flexible-architecture-fisheye-correction-automotive-rear-view-cameras.pdf
Hello Stephan,
Although I like your “cute girl tag-button” I don’t think it is a good idea.
“I was thinking about what the possibilities are for the driver to actually see what he is shooting and at the same time facilitate appliances”
I am pretty sure that you overlooked the risk of driving a car in traffic and doing other stuff at the same time. Even taking a peek from time to time on a monitor will introduce a big risk that the driver is distracted from his main job, driving safe…
Of course when a shoot is done by a driver plus a helper then the situation will be different.
Best,
Wim
Wim, your reply totally made sense. But do you agree that having an appliance like a TomTom for the traveling salesman drives is a good thing?