Dimitrios, try to experiment with camogm and external trigger as I did with arduino on motion detection : http://wiki.elphel.com/index.php?title=Arduino#Arduino_source_code
it should be much more faster than calling wget and any PHP software. regards, Polto ----- Original Message ----- From: "Dimitrios" <d...@telemetry.gr> To: "Andrey Filippov" <support-list@support.elphel.com> Sent: Jeudi 5 Janvier 2012 23:45:38 Subject: Re: [Elphel-support] Camogm triggered mode Andrey > imgsrv is the fastest to get images over the network (i was able to > get 10.4MB/sec over 100Mbps network), Yes, I like imgsrv very much, its quite capable for delivering images. I'm already achieving ~5fps (or more) on a javascript viewer running on an android tablet browser over wifi, using a proxy server that resizes the 2592x3888px images coming from the camera. > Currently there are only 3 instances of the php allowed, so in some > cases (i.e. if camera is locked up waiting for an external trigger) > and there are several simultaneous requests, all the PHP instances may > be in use. It is possible to increase number of instances in lighttpd > configuration file I might well be using up all PHP instances in some instances already. The way this javascript viewer is written, it uses the img onload event to ask for another image after one is loaded. Then there is a histogram image load running in parallel, written in the same way, and at the same time there may be some control set/get taking place, now with camvc and later by using the PHP-Elphel extensions. I might indeed need to increase the lighttpd instances. > for the in-camera recording I would recommend camogv with MOV format > (it has the least of the CPU load). Recording individual frames is > not that good if you need many Camogm seems the best way to handle the in-camera recording, since I'll be recording thousands of images in one go. I've already written some code for parsing my proposed command 'trigger'. That is the easy part. I need to find where to insert code for inhibiting writing a frame until a trigger is received in the input pipe. That's the tricky part. > snapfull.php is not that slow, it just waits for the image pipeline > (before and after). It is designed to interrupt low-res high-fps video > stream with full resolution format (i.e. high fps for navigation, > high-res for the imagery) This is very interesting! I tried viewing a low-res stream 272x496px (decimation 1/8) in my javascript viewer using imgsrv, while at the same time taking full shots over the same channel using imgsrv too. It works, although if I take full snaps fast, simulating a burst, the resolution returns to the full sensor size and stays there. I need to study the snapfull.php script more. Dimitrios _______________________________________________ Support-list mailing list Support-list@support.elphel.com http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com _______________________________________________ Support-list mailing list Support-list@support.elphel.com http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com