Products > Thermal Imaging
Yet another cheap thermal imager incoming.. Seek Thermal
blackboxdisease:
Not sure if this is what is expected. Dropbox contains the simple extracted apk which contains the libseekware.so which has also been decompiled (may not be of use), as well as the decompiled/disassebled apk file which includes all the java source.
https://www.dropbox.com/sh/7688u3m987max2q/AACBJ5hGIKm8H78m4S7dFAK7a?dl=0
miguelvp:
So I did some experiment tonight about timing using the query performance counter.
The frame counter pixel 40 wrapped around to a total of 54027 captured frames by the firmware (not captured by the application, since the application only captured 20000 frames including pre-cal and calibration frames) in 2696.23041648431 seconds giving an average frame rate of 20.04 fps (20.037975860552493637834483136496) not all visible just captured by the firmware, not visual frame rate.
Visible frame rate will be the number of frames with ID 3 in that time so it's probably around 7 fps (20000/2696.23041648431 = 7.4177636591158101089582923858427 minus pre-cal and calibration frames).
Smallest frame time was 0.122480146923205 for 4 frames in frame 12877 (55864 in counter)
Largest frame time was 0.125570133280043 for 4 frames in frame 12658 (54928 in counter)
It went up to 5 frames per count never 8 like on the previous dump by someone else.
Largest frame time was 0.16178046177331 for 5 frames in frame 870
Also both the pre-cal frame and the cal frame took up to 0.1868 seconds
I'm attaching the file with frame count out of pixel 40, frame ID and delta time, all captured into memory and only written when it was all done.
Also there is a total time at the end after rolling over 16 bits for a total of 20000 frames that took 44 minutes and 56 seconds.
So the fastest conceivable frame rate looking at that router of mine is 32.66 fps, but overall it's only 20.04 fps max speed with the current firmware, since the pre-cal and cal times take forever (Frames ID 6 and 1)
The line number (if you have an editor that shows it) reflects the actual captured frame number (not the frame counter) for that ID.
The delta on the frame counter is how many images it took for that one frame to be captured.
Edit: warning long text file with the data attached.
Edit2: 387 is the total of pre-cal and cal frames (each for a total of 774 out of the 20000 frames captured - 5 pre-captured frames, and it should be 6 but there is an extra cal frame, so 7.13 fps average displayed frames)
eneuro:
--- Quote from: miguelvp on November 24, 2014, 10:42:43 pm ---Video comparison from the article.
--- End quote ---
Probably different thermal LUTs used there or on Flir One the same trick was made which we saw above when very hot spots were present in Flir E4+ image-on Flir One they saturated so even if the same LUTs were used we'll get very different RGB output images recorded in this video :D
Anyway we now know how Flir deals with hot spots or maybe those spots are above its maximum limits.
When we make closer look into this magic MSX on Flir One it looks that edge detection is very bad on Flir One and in more complicated scenes like this below Flir's MSX simply damages thermal image by very noisy visual context while they are not able to detect contoures and skip another unwanted visual noise :o
They made closer look test in this article (image above is taken from this comparision) and didn't notice that while IR & visual camera are shifted those IR & visual pixels do not fit no more at such close distance and this image "enhanced" by Flir's MSX is a garbage :-DD
They have very limited processing power in Flir One, so of course can not do more advanced image processing, so probably that is why they also limited emissivity setting to four (4) options, than tested if output image is not complete garbage, but it is when there are many small details in visual image.
Of course there is a lot of filtering and this low res thermal 80x60 sensor output looks smooth, so when probably used in this article ancient first versions of Seek software (or newer versions are not upgraded for iPhone), Seek output looks very bad in the therms of nice image-a lot of noise present-but what we can expect when people writting this article never saw Seek frame raw data and talking about 32.1k thermal pixels which is only 206x156 result, while 2.1k of those pixels are... black hexagon pixels and we can find also a few dead pixels too in those Seek calibration frames.
--- Quote from: miguelvp on November 25, 2014, 09:47:13 am ---Edit: warning long text file with the data attached.
--- End quote ---
Compression turns this long file into 134KB only >:D
--- Code: ---$ gzip -9 dot40_20000frames_2696s.txt
$ ls -n dot40_20000frames_2696s.txt.gz
-rw-rw-r-- 1 501 501 37021 2014-11-25 11:21 dot40_20000frames_2696s.txt.gz
--- End code ---
Did you examined Seek PCB firmware and have conclusion that it can be >30fps before it is send via USB?
This frame_dot[40] word value can be simply timestamp not any frame count, so since we do not know what is going on in Seek firmware difficult to say anything, but 20000 catched from USB in 0.75 hour gives us: 7.4 fps, but there are not only thermal scene frames there, so it will be interesting to make histogram of frame IDs which were present in this what you were able to capture and get statistics-probablity of capturing each frame ID ;)
Update: Histogram of frames IDs provided by @miguelvp below:
--- Code: ---0x1 ( 1) 1.9% 388
0x3 ( 3) 96.1% 19219
0x4 ( 4) 0.0% 1
0x5 ( 5) 0.0% 1
0x6 ( 6) 1.9% 387
0x7 ( 7) 0.0% 1
0x8 ( 8) 0.0% 1
0x9 ( 9) 0.0% 1
0xa (10) 0.0% 1
--- End code ---
So, we had in thi scase 2% of shutter thermal images in frames 0x1 and 0x6, so about 96% frames was thermal scene image frames, but probably depending on temperature changes inside this Seek Thermal dongle maybe there will be more frequent shutter calibration.
However it looks like number of Seek usb frames per time is estimate FPS of different thermal images available-in this case: 20000*0.96/2696 gives us estimate 7.1fps < 9fps ONLY available for any averaging etc? ???
But ok in one of my custom applications with desired 1Hz output 4-8 image frames weighted averaging should be around needed 1Hz so its fine :-/O
miguelvp:
--- Quote from: eneuro on November 25, 2014, 10:51:52 am ---Did you examined Seek PCB firmware and have conclusion that it can be >30fps before it is send via USB?
--- End quote ---
No need to look at it, a simple image capture of a fast moving object show all the frames combined, search for Mike's video.
--- Quote from: eneuro on November 25, 2014, 10:51:52 am ---This frame_dot[40] word value can be simply timestamp not any frame count
--- End quote ---
It could be used as a time stamp but not a very accurate one (1/4th of a millisecond variance), all indications are that it is a frame count.
--- Quote from: eneuro on November 25, 2014, 10:51:52 am ---so since we do not know what is going on in Seek firmware difficult to say anything, but 20000 catched from USB in 0.75 hour gives us: 7.4 fps, but there are not only thermal scene frames there, so it will be interesting to make histogram of frame IDs which were present in this what you were able to capture and get statistics-probablity of capturing each frame ID ;)
...
--- End quote ---
There was no need for any of that, as I mentioned before:
--- Quote ---Edit2: 387 is the total of pre-cal and cal frames (each for a total of 774 out of the 20000 frames captured - 5 pre-captured frames, and it should be 6 but there is an extra cal frame, so 7.13 fps average displayed frames)
--- End quote ---
Well I guess 7.128100 if you want to be more precise. (from 7.1280999882273377242034710681756)
eneuro:
--- Quote from: tomas123 on November 24, 2014, 10:12:09 pm ---most of blurring comes from the lense
see my images here
https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg343791/#msg343791
--- End quote ---
Unfortunate those images attached in this thread are 800x600 8-bit grayscale, while it could be nice to work on 16bit 320x240 oryginal ones from Flir E4+: FLIR0238.jpg and FlirE40: IR_0480.jpg
--- Code: ---e40-gray.png: PNG image, 800 x 600, 8-bit grayscale, non-interlaced
e4-gray.png: PNG image, 800 x 600, 8-bit grayscale, non-interlaced
--- End code ---
I have latest Image-ExifTool-9.76 installed, so no problem to extract 16bit PNGs even from oryginal Flir's .JPG, so could you provide those oryginal images or 16bit ones for deeper analysis, please?
I'm very suspicious if those images are not additionaly smoothed, blured, etc. in Flir's firmware regardless of lens used and I'd like to try enhance its quality as well as Seek Thermal blured images in my software by using methods similar to those in aerial photography:
Right is deblurred left image. so it looks like image magic but it is filtered :o
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version