Yet another cheap thermal imager incoming.. Seek Thermal

[miguelvp]

You can look at the code and find out  (just using it because of your tendency to assume and use it)
should be raw unless he modified it.

[eneuro]

You can look at the code and find out

No need to look at any code.
You wrote this I made a new version of the program that will read the first 20 frames from a file as if they came from the camera as long as there is a data.dat in there.

In another "raw" sensor data provided by you in file which MD5 sum was:

Code: [Select]

75ecb0faf5916b2088eb0f2a03139350  facerouter20frames2.raw
After processing this file:

Code: [Select]

../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #1: type: 4  image (gray 16bit): facerouter20frames2.raw.000000001.0x4.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #2: type: 9  image (gray 16bit): facerouter20frames2.raw.000000002.0x9.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #3: type: 8  image (gray 16bit): facerouter20frames2.raw.000000003.0x8.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #4: type: 7  image (gray 16bit): facerouter20frames2.raw.000000004.0x7.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #5: type: 10  image (gray 16bit): facerouter20frames2.raw.000000005.0xa.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #6: type: 5  image (gray 16bit): facerouter20frames2.raw.000000006.0x5.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #7: type: 1  image (gray 16bit): facerouter20frames2.raw.000000007.0x1.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #8: type: 3  image (gray 16bit): facerouter20frames2.raw.000000008.0x3.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #9: type: 3  image (gray 16bit): facerouter20frames2.raw.000000009.0x3.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #10: type: 3  image (gray 16bit): facerouter20frames2.raw.000000010.0x3.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #11: type: 6  image (gray 16bit): facerouter20frames2.raw.000000011.0x6.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #12: type: 1  image (gray 16bit): facerouter20frames2.raw.000000012.0x1.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #13: type: 3  image (gray 16bit): facerouter20frames2.raw.000000013.0x3.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #14: type: 3  image (gray 16bit): facerouter20frames2.raw.000000014.0x3.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #15: type: 3  image (gray 16bit): facerouter20frames2.raw.000000015.0x3.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #16: type: 3  image (gray 16bit): facerouter20frames2.raw.000000016.0x3.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #17: type: 3  image (gray 16bit): facerouter20frames2.raw.000000017.0x3.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #18: type: 6  image (gray 16bit): facerouter20frames2.raw.000000018.0x6.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #19: type: 1  image (gray 16bit): facerouter20frames2.raw.000000019.0x1.png
../raw2png: Seek Thermal sensor raw frames file: facerouter20frames2.raw frame #20: type: 3  image (gray 16bit): facerouter20frames2.raw.000000020.0x3.png
and looking into first calibration frame which should be raw Seek sensor data BUT IT IS NOT  while there is no visible  any bad sensor dots and this is the same calibration frame I used above to compare with @Uho data provided there from your software I guess because simply his sensor look TOO PERFECT to be real raw sensor data

Code: [Select]

$ ../img2pat facerouter20frames2.raw.000000007.0x1.png
../img2pat: Seek Thermal sensor hexagon pattern image dimensions: 206 x 156 value min: 128
../img2pat: Seek Thermal raw sensor image patterns written to: pat.facerouter20frames2.raw.000000007.0x1.png  bad pattern pixels: 5/32136  (0.016 %)

First "raw" sensor calibration frame from this facerouter20frames2 provided by you @miguelvp with iron LUT appliet to show any not perfect pixels below.


Common @miguelvp I'm not newbie, but involved in IT for so many years....and there are also other people who remember Commodore 64 and LOGO programming 

[miguelvp]

You wrote this I made a new version of the program that will read the first 20 frames from a file as if they came from the camera as long as there is a data.dat in there.

I never published that code that reads the raw data and displays the image, so don't assume they have it.

Common @miguelvp I'm not newbie, but involved in IT for so many years....and there are also other people who remember Commodore 64 and LOGO programming 

So? I do remember LOGO since in high school I did help the math teacher setup all the CP/M 80 systems that he was going to use to teach LOGO I was already programming assembly on my zx81 and spectrum and knew enough CP/M 80 that my teacher seeked my help.

But regardless of that because it's irrelevant. The data should be raw data I don't modify it and if you don't believe it, then look at the source because that's the program that he is using.

And I'll add one of your face palms for good measure:
 

[eneuro]

I never published that code that reads the raw data and displays the image, so don't assume they have it.

No problem, while a few posts above we can see how to do it while Seek java source code was presented and it looks like python code presented by @cynafab in section where frames were taken from Seek device if fine, so from my point of view no need to look end examine other code than this python few lines of code and Seek java source code, but it looks like software you use and maybe other people too does something strange, so recomended look for other tool to grab Seek raw sensor data like mentioned by @cynafab python code example where it is easy modify this code to output compressed 16bit PNGs and analysis of calibration frame provided by @cynafab looked like real Seek sensor data, so it is WARNING for new Seek players and for you that this "raw" data provided by you might be useless and people need to do it yourself if want reliable data or use other raw usb dump provided there by other people if you do not know what is going on app at usb level-we know how it works in this python code and explained basic part which reads those Seek frames from USB in comparision to its java source code, so we know it should be fine for the moment 

[miguelvp]

You are looking at the wrong frame, that's is frame with ID 7. You are guessing it's the bad pixels but it's not, it might however hold where bad pixel clumps are concentrated.

But my camera and Uho's actually have more noise that the others, but not concentrated in spots.

[efahrenholz]

 

[eneuro]

You are looking at the wrong frame, that's is frame with ID 7.

Each 7th frame in Seek startup sequence is calibration frame with id 0x1 (1) and yuo know it while you printed this also in your text file data.txt 

     Frame 7 ID 1
8D1DD3D3BCABAA1
8D1DD3D3C08B7C5 <- 406,2500ms

Attached frame 7 from data.dat has of course id 0x1 (1) and everybody can verify this in imagej2 :

So, no need to guess anything on calibration frame to find dead pixels-just apply hexagon pixels first and then verify any other pixel outside this perfect pattern with some threshold (in my case choosen <128 ) and make dead pixels map like those I've shown above while temperature inside Seek dongle is above 30*C at ambient room temperature 23*C, so very low saensor values outside  those expected hexagon pattern are dead pixels when we take a few such calibration frames and I examine not only first calibration frame but other too to ensure that not noise pixel are marked as dead one.

But my camera and Uho's actually have more noise that the others, but not concentrated in spots.

Yep, you have special Seek dongle version  made for @miguelvp 

Hopefully, we know now how to grab frames from Seek dongle using python code or java code and no need to mess with those data.dat and data.txt files from other amateur Seek devel apps.

Update:
Also data.dat send by @marshallh shows he used not "improved" version of oryginal Seek app and in 7th startup frame id 0x1 of course those dead pixels visible (showed this above) and what is interesting there are 4 forming 2x2 box of dead pixels, so that is why I was asking about any quality measured if any are used in Seek Thermal assembly proces to avoid this, while 1x1 dead pixel is not a big issue since there are already 2.1k hexagon useless black pixels, but mny pixels close together creates much bigger destruction to thermal image while we have there 4 dead+2hexagon=6 connected useless pixels group in @marshallh raw data  posted in this thread many posts above


So, if someone knows more about QC procedures used in microbolometer selection to final assembly let us know, while it is interesting that customers gets units which can have worse performance than other devices due to different distribution of dead looking pixels in theris sensors.

[frenky]

Today I've build panorama head for stepper motor. 



I modified VS software to automatically:
- capture calibration frame
- capture image frame
- move stepper motor 4,5 degress
- repeat that 14x

That is 28 frames in total (14 calibration and 14 real images).
Each new frame is 4.5 degrees to the right.
Data file is here: http://goo.gl/KAgmnt (I hope you'll be able to download it)
The idea is to stack files to remove noise like this: http://goo.gl/VGnNY
But I didn't have time to do that yet.

[Fraser]

@frenky,

One of the reasons that I am so pleased that an affordable small thermal  imaging camera has become available is demonstrated by you experimentation with the pan unit. The SEEK is barely larger than some optical imaging assemblies and is eminently suitable for all manner of experiments in thermal imaging.

My greatest disappointment with the SEEK is that it has such high noise levels in the output image and the gradient issue that affects some cameras more than others. If SEEK manage to overcome the gradient issue and the noise processing challenge, I would certainly buy more of these cameras. I just hope SEEK still have enough drive left in them to finish this product development properly. they are so near to a great product, but sadly so far away from decent image quality at the moment under APP 1.4.

I have stated previously that FLIR are past masters of noise processing. They have been working on it since the PM570 was released in 1997 so they have developed a lot of software tools in that time. Sadly the SEEK software coders may be experiencing a steep learning curve on that front so we need to be patient.

Aurora 

[cynfab]

frenky,

Looks like you have made great progress.
I have not been able to download your data file, 404 error.
Will you be making your code available? I have been unable to remove the banding in my python code, I've tried various methods including frame ID 4, pixel 207, and several other methods. It is probably my poor coding skills, but I'd love to see your solution, as it looks great.

   ...ken...

[frenky]

Hi.

I've put the data file on dropbox: https://www.dropbox.com/s/bxkzblgw55iwpsq/seq2.zip?dl=0

The source for displaying and manipulating frames is in the attachement....
I have hard-coded file names so you should go trough code before trying to run the project.
You will also need file iron1000.png file (palette).

[eneuro]

That is 28 frames in total (14 calibration and 14 real images).
Each new frame is 4.5 degrees to the right.

Thinking of using steppers but in different setup: 2 axis x and y controlled by simple motors with IR encoders to count number of turns and make very small less than 1mm movements by such created rectangle area 
I think good idea will be add 3 hot point sources to the scene to augument it and have reference points to fine align those many frames into one while we have hot spots small reference points.

Anyway got the same error as @cynafab when tried to look into your calibration frames - dropbox is fine and it looks like ziped 28 frames is about 1.4MB, so around 51KB per raw Seek sensor frame-16bit PNGs compressed with non default maximum 9 level are about 57KB, so I'm using this method below when saving raw Seek frames.

Tip in OpenCV PNG write of 16bit gray images is to change default compression level from 3 to 9 and than each Seek sensor frame is only about 50KB per frame, so you could simply post those calibration and image frames in two posts without any problems even there.

Code: [Select]

Mat img(156,208,CV_16U );
...
// PNG9
vector<int> compression_params;
compression_params.push_back(CV_IMWRITE_PNG_COMPRESSION);
compression_params.push_back(9);
...
imwrite(fout, img, compression_params );
In similar fashion you will be able write in OpenCV jpeg files with forced 100% quality, so this tip with 3rd parameter in OpenCV imwrite  is worth to add those 3 lines of code to your C++ app 

We could discuss different debanding methods, while I'm also looking to improve my method and after finishing thermal scale management and adding rainbow thermal LUT i'm working on, so it could be nice to work on the same Seek raw sensor test data and discuss and compare results 

Edit: Quick check of those dead looking pixels on your calibration frames showed more, but other Seek devices have more than 100 sometimes, so 79 there is not a big supprise and it would be interesting to see how it will look in other ambient temperatures, etc -if it differs somehow:

Run this test on most of those calibration frames not only this last, but on first it is the same amount:

Code: [Select]

../img2pat: Seek Thermal raw sensor image patterns written to: pat.frenky_osc_motor.raw.000000001.0x1.png  bad pattern pixels: 79/32136  (0.246 %)


[Uho]

Maybe someone of you has the following information:
 1. Why need android 4.4. Not entirely clear requirement.
 2. What is the minimum RAM required to run the program.
 3. The minimum number of cores and CPU frequency phone.
I have several phones and tablets on the android. But with android 4.4 not. I bought a new phone. While he was still on the way. I had doubts.

[cynfab]

frenky,

Thanks for posting that code. As I don't do Windoze, I'll be analysing your code with an eye towards incorporating your methods in my Python program. I've already seen some things I will be trying. The order of applying the hex pattern & noise removal may be important. I'm just getting into it now so I probably won't have anything running for a day or so, depending on the weather & phase of the moon. ;>)

   ...ken...

[miguelvp]

You are looking at the wrong frame, that's is frame with ID 7.

Each 7th frame in Seek startup sequence is calibration frame with id 0x1 (1) and yuo know it while you printed this also in your text file data.txt 

     Frame 7 ID 1
8D1DD3D3BCABAA1
8D1DD3D3C08B7C5 <- 406,2500ms

That is indeed the reference image from that series, and it's unmodified raw data.
Here it is with the Iron LUT Frenky linked and indeed it looks exactly like yours after processing.

But my camera and Uho's actually have more noise that the others, but not concentrated in spots.

Yep, you have special Seek dongle version  made for @miguelvp 

I think your method to find unresponsive pixels is flawed because mine does have plenty of them.

Hopefully, we know now how to grab frames from Seek dongle using python code or java code and no need to mess with those data.dat and data.txt files from other amateur Seek devel apps.

You sir are an Ass!
But I digress, since that's an insult to those fine animals that actually produce decent work.

Update:
Also data.dat send by @marshallh shows he used not "improved" version of oryginal Seek app and in 7th startup frame id 0x1 of course those dead pixels visible (showed this above).

Edit: First because of your "improved" in quotes, I guess it's not far fetched that you are just an arrogant prick! with total lack of respect to others!

Actually the original version of the Seek app, didn't save the raw data, only my version did, and it uses the same code to capture it. So that data that you claim is unaltered while you claim mine is,both come from the same program. The processing to screen never alters the raw data.

But since you are too lazy to look at the code, here it is:

Code: [Select]

                // Get frame
                lastFrame = thermal.GetFrameBlocking();

                // Save data and metadata for the first framesToCapture frames
                if (frameCount <= framesToCapture)
                {
                    // Write frame in binary file.
                    bw.Write(lastFrame.RawData);
...
No manipulation is done in the raw data, before writing it to disc.

So stop looking for a fight and get on with your work 

[-jeffB]

Okay, here's a really dumb question for those of you who are hacking on the Seek with a non-mobile device:

What kind of USB adapter are you using to connect it, and where did you find it?

It's dead easy to find USB OTG adapters with a male microUSB end and a female USB-A end, but of course we need the opposite (male USB-A to female microUSB). The only ones I can find ship via slow boat from China -- there are maybe one or two domestic (USA) suppliers, but no place that I can just run out and get one.

Am I overlooking something obvious, or did you cut up other adapters and build your own?

[miguelvp]

I made my own while waiting for the adapter, don't recall where I got it from but here is a listing for 2 of them.

http://www.ebay.com/itm/2X-USB-2-0-A-type-male-to-Micro-USB-B-type-5p-female-Connector-Adapter-convertor-/151445719442

So you want a USB A male to Micro USB B female adapter.

Edit: Also you can use a micro usb b extender and cut it up and hook it to a usb a male like this:


http://www.ebay.com/sch/i.html?_nkw=Micro+USB+B+extension

[eneuro]

I think your method to find unresponsive pixels is flawed because mine does have plenty of them.

Yep, if you take random pixels maybe 

Try to apply your methods to @frenky calibration frame and calculate how many those bad dots in your opinion is, but even human without colors blindness can see which is the range of values in this calibration frames when we add my 16bit iron LUT which was applied to this frame and its mean and standard devaition statistics are in this range.

[cynfab]

I got this:
http://www.amazon.com/gp/product/B009AWA3VK/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1
Looks to be the same as miguelvp is waiting for.
It works well. Plugs into the front USB port on my desktop, when I need to "look around" with the camera, I add a male-female usb extender cable.
I also have a variety of USB OTG adapters, mostly from e-bay, some are more flaky than others, but all were cheap...

   ...ken...

[miguelvp]

One problem with some OTG cables is that the female header only has the power hooked up and no data.
BTW I did get mine a while back (the adaptor) and with a usb A extension cable it works great, I probably got it from Amazon and might be the same as the one cynfab linked. Usually if I find something like that I send the link to my wife and she gets it  because I'm not making an amazon or ebay account for random bits like those, and she already has accounts on both.

[-jeffB]

I made my own while waiting for the adapter, don't recall where I got it from but here is a listing for 2 of them.

http://www.ebay.com/itm/2X-USB-2-0-A-type-male-to-Micro-USB-B-type-5p-female-Connector-Adapter-convertor-/151445719442

So you want a USB A male to Micro USB B female adapter.

Edit: Also you can use a micro usb b extender and cut it up and hook it to a usb a male like this:


http://www.ebay.com/sch/i.html?_nkw=Micro+USB+B+extension

Perfect -- ordered a pair just now, and with luck, I'll have them next week! I haven't yet written anything that talks directly to USB, but the code on this thread looks clear enough.

I might consider your homebrew approach, too. I'm using the Seek on a Nexus 7, and when I ordered the short USB extender ("180-degree adapter"), I also bought a longer one (1-meter). That longer one worked for an hour or so, and now has gone intermittent, apparently at the Nexus (male) end, so I may sacrifice it.

Thanks!

[frenky]

Progress! 

I've blended together 10 images that were taken 0.225 degrees apart and stacked on top of each-other.
The end result is great. More details less noise:


Basic capture for comparison:

[eneuro]

I've blended together 10 images that were taken 0.225 degrees apart and stacked on top of each-other.
The end result is great. More details less noise:

Which is distance from your Seek to this captured thermal object?
We could estimate displacements on thermal object surface based on this 0.225 DEG angle 

It looks like that my idea with 2 AXIS circular driving of this Seek dongle put perpendicular to circuit board with very tinny displacements <<1mm should give maybe even better quality output, while when you are turning your Seek from distance lets say 0.5m at given angle 0.00392699 RAD gives 0.00196 m (~2mm) displacement on thermal object surface and rotation will change object dimensions taken on sensor frames-additionaly Seek sensor is not at the center of rotation in your setup.

Anyway did you tried stack similar amount of frames from stationary mounted tripod and compare what you get?
It looks much better than 1 image frame only but what if you get bigger amount of stationary frames?

Of course small displacements are needed, so that is why I'm going into 2 axis circular motion solution with very small diameter <<1mm depending of output precision needed and thermal object distance from Seek dongle 

Edit: It looks like this horizontal movement is visible in your enhanced stacked by motion final thermal image, so I think 2 axis circular motion will be fine and we should get better results with very small 2 axis movements in the same plane 

[frenky]

Offset of each frame is 0.255 DEG which is approx 1.35 pixel. (the 4th frame is aligned with the first one)
So I'm getting into super-resolution waters here.(3 times the original resolution).
Idea of circular motion is nothing new. I was considering it from the start (October 28th): http://goo.gl/QpAk2a

It's just that I'm just a diy guy and it's a lot easier for me to put together something that does small horizontal movements then circular...

Edit:
If I would go into making circular motion I would do something like this: https://static.hackaday.io/images/9207121405936029200.jpeg
Because If you are changing the angle of camera in circular motion the pixel offset between frames is always the same.
But if you move camera only on one plane the pixel offset will be different. It will depend on the distance to the subject.

[efahrenholz]

Frenky it looks great. It's a shame we can't get clean images like that without using a pan head.

@miguelvp, I believe eneuro isn't trying to be an ass. His interpretation of English is a bit lacking. He hasn't got a polite way to say things without it coming off insulting. I have a hard time figuring out what he's saying most of the time. Lots of pictures and cryptic sentence structure.