August 14, 2010

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.

Gui Mockup
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.

6 responses to “Eyesis-in-Car GUI mockup”

  1. andrey says:


    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).

    P.S. Here is what Oleg uses now:

    Eyesis camera control panel

    Current version of Eyesis control panel

  2. @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.

  3. andrey says:


    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).


  4. Wim Koornneef says:

    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.


  5. 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?

Leave a Reply

Your email address will not be published. Required fields are marked *

− two = 1