[Elphel-support] Some questions about Elphel 353

[Andrey Filippov]

On Sun, Jun 13, 2010 at 11:47 PM, Jens Bürger
<jens.buerger at cs.tu-dortmund.de> 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