Biel,

so it is not the Python script?

parsedit.php is a development tool - for quite a while it did not have GET 
mode, and by default it schedules the parameter modification to 3 frames in the 
future (you may use EXPOS=1000*0 to overwrite that, but the frame +0 will to be 
affected anyway - 2 frames will be lost in the sensor) - the longest delay it 
may take the sensor (different commands have different latency). Actually 
parsedit.php allows you to make multiple parameter changes at different frames 
and then open 9 last images with the parameter values below so you can 
troubleshoot latencies.
3 frames will take 12 ms, the rest may be the laptop opening and running wget.

Andrey


---- On Thu, 13 Dec 2012 17:10:06 -0800 Biel Bestué de 
Luna<7318...@gmail.com> wrote ---- 


ok,

about the wget:

I'm currently using a WAN router attached to the camera, I connect the camera 
to it via ethrnet, and I connect my laptop to the router via WiFi

then I setup the camera to triggered in order to have a fixed rate of 25 fps 
with the API I talked before
 
I open a real time stream with gstreamer at low latency in my laptop to see the 
real time reaction:

"gst-launch-0.10 rtspsrc location=rtsp://elphel:554 protocols=0x00000001 
latency=40 ! rtpjpegdepay ! jpegdec ! queue ! xvimagesink"
 
then I open the terminal and write this:

"wget --delete-after 'http://elphel/parsedit.php?immediate&EXPOS=100&'"
 
(EXPOS at some strange value so I see the change easily)

I see the change 1 second after I touch intro



2012/12/14 support-list <support-list@support.elphel.com>
  Biel,

It will be quite a work to do a C program - as I said the easiest will be to 
adapt the php extension code (written in C). But agan - I do not think you'll 
get much of the performance gain (if any) compared to PHP - we use it ourselves 
and it is fast.
 
Andrey




---- On Thu, 13 Dec 2012 15:51:45 -0800 Biel Bestué de 
Luna<7318...@gmail.com> wrote ---- 


 Andrey
you talked before about the possibility to create a C coded program, how would 
someone interact with that program would that be a daemon like the php 
application seems to be working? if so would it be any better than php 
resource-wise?
 
if a C coded application could be added in order to cover this rapid control 
and data acces, could both applications (php application and C coded 
application) coexists using the same parameters? so if you change EXPOS via 
wget you see the change right away in the C coded program and vice versa...
 so both applications would cover diferent usages of the camera, one could 
cover the current usage, where you can do everythin in camera, and the other 
would cover a more service-like usage where the camera serves the purpose of 
recording/shooting device, and other functions remain in another computer not 
inside the camera. what do you think? 
 

2012/12/14 support-list <support-list@support.elphel.com>
 
> the idea was to unload that work from the camera, and leave all the 
important processing to the external computer,
 
 Yes, we do the same with Eyesis, there is a lot of processing, but PHP is 
still used in to control the camera

> like Flavio Soares does, he deactivates the php functions of the camera so 
it can record at a higher quality jpeg compression.
 
What does "deactivates the php functions of the camera" mean?

He does not use the camera GUI? Yes, that GUI is rather slow, but not slower 
that it was before the PHP was implemented in the camera (camvc is rather old - 
at least 6-7 years).
 
Using PHP in the camera is the fastest way to control it. Of course, if you 
will run Drupal there - it will be terribly slow, but just changing few 
parameters you really need - it will be faster than telnet. 
 
> what would be cool would be to have an abstraction layer that would cover 
that kind of usage of the camera, for rapid interaction with the camera.


Camera control functionality is implemented in PHP extension - 
http://wiki.elphel.com/index.php?title=PHP_in_Elphel_cameras . Any simple "API" 
like in many cameras would definitely limit the functionality, so we decided 
that user can make her own API, coding it in PHP. It can be universal, but big 
and likely slow. Or it can be tailored to particular application - and be 
really fast.
 
Andrey






 _______________________________________________ 
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 




_______________________________________________
Support-list mailing list
Support-list@support.elphel.com
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com

Reply via email to