For us, we need the ability to get the full framerate off the sensor, because right now it's only allowing around 9fps. Its averaging 5 frames together for each visible frame. By my math its about a 45fps sensor. Its a shame ITAR limits the fps on such a low resolution sensor.
9 fps not so bad -if moving average of 8 were used than even on MPU it can be fast while divide by 8 in assembler can be performed by shifting bits and will be fast -no integer divide needed, and output 1 Hz frequency could be fine in many applications if we were able improve image quality
I did manage to compile the seeker windows program on a dell venue tablet and run it with the camera plugged directly into the usb port.
Nice, so if you could add a few lines of code where raw sensor data is read and output it simply as
unsigned int or
uint16_t to text file (than compress) without any comparisions and changing to 0 those pixels with 0x800 condition in this code-raw data as it comes from the sensor in format below (and include also thermal image of catched object as well as its visual image to see what light conditions it was: dark, normal working light) they maybe someone from the forum could be able to figure out what is in those last 2 columns in those raw sensor images.
/**
* (C) 2014 Eneuro
*/
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <string.h>
#include <time.h>
void random_init() {
srand(time(0) );
}
double random_double() {
return ((double)rand())/RAND_MAX;
}
unsigned int random_14bit() {
// 2^14= 16384
unsigned int pixel= random_double()*16384;
if(pixel>=16384) {
pixel= 16384-1;
}
return pixel;
}
int main(int argc, char *argv ) {
unsigned int i, j, k, l, m, n;
unsigned int y,x, w= 208, h= 156, wh= w*h;
unsigned int img0, *img;
unsigned int f, frames= 8;
random_init();
img= (unsigned int*)malloc(sizeof(unsigned int)*wh );
// frames
for(f=0; f<frames; f++ ) {
// frame
// Create random image with 14bit data or read from sensor
for(i=0; i<wh; i++ ) {
img[i]= random_14bit();
} // Create random image with 14bit data or read from sensor
// Output frame
// rows
for(y=0; y<h; y++ ) {
// column
for(x=0; x<w; x++ ) {
img0= (unsigned int)img[y*w +x];
printf("%05u ", img0 );
} // column
printf("\n");
} // rows
printf("\n\n");
// Output frame
// frame
} // frames
return 0;
}
so, each frame in this text file could look like this below separated by 2 empty lines (it is LF 10 dec codes on Linux and CRLF 13 dec 10 dec on Window$ as text new line character(s) ).
Output text file looks like this in the case of C source code shown above:
This way if we compress such text file with many frames of row data from sensor one could for example to investigate how this gradient evolves in time.
You can add delay and output to such text file for example sequence of 8 frames than delay 10 seconds another one etc, for 10 minutes and this way if you had this thermal cam on tripod pointed to flat surface we could try to see how it changes in time, by applying moving average to each 8 frames and another ones after delay.
When applied from 4-1024 convolutions to some raw USB sensor image pointed to such flat surface I've got something like this
but it was 8bit per channel RGB, so 14bit degraded to 8bit by software we are talking about and gradient image made by
@marshallh,
but it could be interesting to see how it changes in time without any postprocessing-just raw 14bit sensor data with
iron 1024 LUT or 14bit.
BTW: Compressed 8 frames of 14 bit raw data in text format shown above is <1MB so easy to exchange for investigation of gradient issue and those strange 2 last columns in each frame
Home
Help
Search
Login
Register
