On Sun, Jun 13, 2010 at 11:47 PM, Jens Bürger <[email protected]> wrote: > > What is the difference between the elphel_wait_frame_abs and > elphel_wait_frame functions? > > As I unterstood it, elphel_wait_frame 'syncs' to completed, compressed > images, but to what does the _abs-function 'sync'? I think I read somewhere > that it 'syncs' to 'all' images.
Jens, I'm sorry fro the late reply. Do you have all the Elphel development environment installed (http://wiki.elphel.com/index.php?title=Elphel_Software_Kit_for_Ubuntu , http://wiki.elphel.com/index.php?title=KDevelop )? If you have and ran prep_kdevelop.php script, it will allow you to open the complete project in KDevelop (should be 3.5.x, not yet 4.x), with it you can easily navigate through the code using integrated CTags. Here is the explanation about those two functions - one just gets the next frame that became ready after the function call, the other sleeps until the (absolute) frame number reaches specified value. When setting parameters you can specify to what exactly frame should they be applied (in advance), but not too far as the hardware command buffer is only 8 frames deep. With parsedit.php you can specify any frame number to which parameters should be applied - it uses software to wait until the specified frame number almost happens, then applies command to the hardware sequencer. The command buffer is used to reduce real-time requirements to the software and account for the latency in the sensor (has different latencies for different parameters) and FPGA. http://elphel.cvs.sourceforge.net/viewvc/elphel/elphel353-8.0/apps/php-5.2.9/ext/elphel/elphel_php.c?view=markup 97 *! Revision 1.13 2008/10/19 06:56:05 elphel 98 *! elphel_wait_frame() now works only for compressed frames, new elphel_skip_frames() and elphel_wait_frame_abs() wait sequencer frames (all sensor frames, even those that are not compressed) 388 PHP_FUNCTION(elphel_wait_frame_abs) 389 { 390 long target_frame; 391 if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "l", &target_frame) == FAILURE) { 392 RETURN_NULL(); 393 } 394 if ((target_frame<0) || (target_frame > 0x7ffffdff)) RETURN_NULL(); /// Out of limit for skip frames 395 RETURN_LONG(lseek((int) ELPHEL_G( fd_fparmsall), target_frame + LSEEK_FRAME_WAIT_ABS, SEEK_END )); 396 } 1755 //! wait for the next frame to be compressed (and related parameters updated 1756 PHP_FUNCTION(elphel_wait_frame) 1757 { 1758 lseek((int) ELPHEL_G( fd_circ), LSEEK_CIRC_TOWP, SEEK_END ); 1759 lseek((int) ELPHEL_G( fd_circ), LSEEK_CIRC_WAIT, SEEK_END ); 1760 RETURN_NULL(); 1761 } > Does this mean, that uncompressed image-data is also available via the >Linux-System? If yes: where are they available and how / when do they bypass >compressor.v ? > It is possible to read raw images from the camera bypassing compressor, but it is very slow, we use it only to compare the results of compression. image.raw driver does it, you may also find some php examples. I suggest you a better way to get the "raw" sensor data - use jp46 compression, keep gamma ~=0.5 (matches noise performance of the pixels) and then try imageJ (http://rsbweb.nih.gov/ij/ ) plugin (http://elphel.git.sourceforge.net/git/gitweb.cgi?p=elphel/ImageJ-Elphel ) that reads jp46-compressed images, reads Exif MakerNote with settings of the analog gain and gamma values, un-applies gains/gammas, re-orders pixels and generate a floating-point image. Of course, for the best result you need to keep compression quality equal (or close to) 100% - with 100% there is no quantization in the compressor. Andrey _______________________________________________ Support-list mailing list [email protected] http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
