Weird thing about flatfield calibration...if i do the magnet trick, obviously it takes whatever it sees and uses that to sub out each frame. But on the very next flat field where i let the shutter work, a ghost image of the last flat field (like hot objects) is still present, but less. l think Seeks software is averaging flat fields. A bug?
Not sure I can agree about the focus statement.
To be clear on MSX.
...
The idea of fusion was enhanced by allowing the transparency of the visible light image to be adjusted in order to have lower impact on the thermal image data that was being displayed.
Does anybode know how to convert the 16bit image data to absolute temperature values?
Close up lenses are used to provide detailed images of PCB's etc.
I've put up a simple holder for the 20mm ZnSe lenses over at Thingiverse. It's just a friction fit which depends on the asymmetry of the camera face to hold it in place, but it seems to do the trick. Should do well enough to keep handy in the toolbag. http://www.thingiverse.com/thing:525605have any pictures you've taken with this setup?
Does anybode know how to convert the 16bit image data to absolute temperature values?Those are pre getting the real images but the range is about the same.
208x156 16 bits unsigned only 14 bits used.
Pretty much you want to capture the max and min value (ignoring dead pixels and reference ones, under 0x800) and then stretch them ramp them from min to max to fit on a 256 look up table. So (max-min)/256 should get you started.
So I've managed to reduce the noise using a convoluted method.
Yep, there are a couple at Thingiverse. I'll stick 'em over here as well, one each with a 100mm and 50mm aux lens.
They are noisy and the resolution isn't world-changing but it's better than the "Ow! $#!% my finger!" test to answer the question "What's pulling all the current on this damned board?"
So I've managed to reduce the noise using a convoluted method.You mean http://en.wikipedia.org/wiki/Moving_average ? How many frames used and what is output frame rate from this sensor hardware catched by USB?
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.
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.
/**
* (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) ).Does anybode know how to convert the 16bit image data to absolute temperature values?Those are pre getting the real images but the range is about the same.
208x156 16 bits unsigned only 14 bits used.
Pretty much you want to capture the max and min value (ignoring dead pixels and reference ones, under 0x800) and then stretch them ramp them from min to max to fit on a 256 look up table. So (max-min)/256 should get you started.I made a look into that code since I'm interested in own Linux USB driver if they resolve those gradient issues.
This hardcoded 0x800 looks bad in this code, as well as fitting to 256 LUT- while we have 14bit using 1024 LUT could give much better results.
Also averaging/convolution methods used in this code are computational not efficient- it can be done much faster using a little bit memory which is not concern on modern devices while we'are processing 208x156 raw sensor data.
Also it does not use any moving average between frames, so no chance to make this image less noisy by mounting this thermal dongle on tripod to avoid any movements while it does not have any stabilization.
I suggest reading image processing publications to make this code more efficient, however USB communication part might be usefull if someone have no chance to make USB sniffing
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. I notice a lot of white specs along with dead pixels and the null pixels. We'll just call those patent pixels.
Since 16 bit grayscale doesn't seem to be supported, I had to do 48 bit color (with R=G=B).
"Flexible Image Transport System (FITS) is an open standard[3] defining a digital file format useful for storage, transmission and processing of scientific and other images."
Since 16 bit grayscale doesn't seem to be supported, I had to do 48 bit color (with R=G=B).Gray Alpha channels in PNG could be used-easy to write using libPNG
http://www.libpng.org/pub/png/book/chapter08.html#png.ch08.div.5.4
However, this FITS image format (http://en.wikipedia.org/wiki/FITS) can be very usefull thereQuote"Flexible Image Transport System (FITS) is an open standard[3] defining a digital file format useful for storage, transmission and processing of scientific and other images."
There is a few links to FITS docs, libs, sample files on NASA web pages:
The FITS Support Office at NASA/GSFC http://fits.gsfc.nasa.gov/
http://fits.gsfc.nasa.gov/fits_documentation.html
http://fits.gsfc.nasa.gov/fits_libraries.html
I've downloaded for research this simple:
The Interactive FITS File Editor fv: http://heasarc.gsfc.nasa.gov/docs/software/ftools/fv
http://heasarc.gsfc.nasa.gov/docs/software/ftools/fv/fv_download.html
ftp://heasarc.gsfc.nasa.gov/software/lheasoft/fv/fv53.exe
ftp://heasarc.gsfc.nasa.gov/software/lheasoft/fv/fv53_pc_linux64.tar.gz
With funtools library it should be easy add support for FITS images to application
https://www.cfa.harvard.edu/~john/funtools/
https://www.cfa.harvard.edu/~john/funtools/funtools.pdf
There is Definition of the Flexible Image Transport System (FITS)
Using mentioned above fv it is easy view and modify eg. sample Hubble telescope image I've downloaded from NASA website for testing (it is just 16bit):
Which is more interesting contours can be added to those FITS image files as well as other data incuding tables, etc, so Flir's MSX no longer needed to add edges while we can output thermal image in this FITS format with contours
No problem to load such FITS image even using GIMP, but probably this data is scalled to 8bit I guess,
so using software like fv is adwantage.
I've suggested simple text format for investigation purposes while no problem with bits order in different machines and it is easy to add only few lines of code to output this raw data while we have fixed size Seek Thermal sensor image data, so easier than include FITS library, but while NASA is using FITS and it is designed with backward compatibility for archives purposes, so it is well defined image format