Author Topic: SeekThermal - How to correct the image received from the sensor? (Read 42246 times)

jadew · « **on:** June 12, 2015, 10:57:12 pm »

Hey guys,

I'm trying to get some software going for this camera but I'm having a hard time correcting for fixed pattern noise.

The problem is that even if I subtract the calibration frame from subsequent frames, the fixed pattern noise is still there. Flat Field correction was suggested to me, but I'm not entirely sure how to get that working with out manually calibrating the camera.

The mobile app manages to get proper images, which means it is possible. Any ideas on how to achieve the same result?

As soon as the camera is initialized, it sends out 6 frames, which I attached.
Once in a while, it sends 2 calibration frames, one before the shutter is heard, another one after or at the same time - can't tell. Also attached.

Blue pixel = min displayed value
Green pixel = max displayed value

Edit: The last picture is obtained by applying the offset from the calibration frame.

Let me know if you have any ideas. Thanks.

ranch varment · « **Reply #1 on:** June 13, 2015, 02:00:58 am »

Whats that noise even doing there, it looks like it was added by your program. (it looks computery)

Whats causing it, it actually looks to me like some software fault, not something youd get practically at all, besides i just reread and you said some other software was working - does it have a similar look to this? note - I dont know much about thermal cams.

miguelvp · « **Reply #2 on:** June 13, 2015, 03:29:41 am »

Not added noise, it's on the actual sensor:

Read this thread from this point on:
https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/msg533735/#msg533735

Be warned, many many pages but with source code etc.

John Coloccia · « **Reply #3 on:** June 13, 2015, 03:41:37 am »

What camera is it? Exactly what are the cal frames? Obviously, one is for a dark cal. Is the other one also dark current? It seems brighter. Different integration time? I have a funny feeling the second image might be for gain flattening. Perhaps some of the initial images are for gain flattening?

Typically, you would take many dark current frames and average them to get your dark cal. Initial Frame 3 looks like a dark cal also. At a minimum, try averaging the 2 cal frames, and maybe even initial frame 3, and use that as your dark cal. Worth a shot, anyhow.

Do you have more information, or are you trying to reverse engineer the camera output somehow, and it's some sort of proprietary rubbish?

miguelvp · « **Reply #4 on:** June 13, 2015, 04:02:13 am »

Here are my interpretations of those images but that was back in November:

https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/msg545910/#msg545910

Somewhere in there there is a zip file with the code for a windows app that I did based on sgstair's github code:
https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/msg534497/#msg534497

mine is buried somewhere in there.

Best image I got with an extra lens:

Someone else's camera using my program but I did make a custom version for him to get rid of his dead pixels:

Here is one of the versions on the zip file on this post
https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/msg552223/#msg552223

Not sure if there are more after that one.

John Coloccia · « **Reply #5 on:** June 13, 2015, 04:17:01 am »

Studying it some more, it looks to me like Frame 3 is a dark cal, and frame 4 is flat field...maybe from the factory? Are those frames identical every time the camera starts up?

If that's true, you can subtract frame 3 from frame 4 to get the pixel gain corrections.

miguelvp · « **Reply #6 on:** June 13, 2015, 04:27:38 am »

John, if you want to play with the images, here are some raw captures zipped on this post, including those first frames and visible frames. One set with the camera facing down, the other one pointing to my Verizon router, where the Z is in red so it doesn't really show in the closeup above, but the raw images are from farther away and without the close up lens I used for the one I embedded above.

https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/msg545880/#msg545880

I still have the project somewhere in my system and I'm not entirely sure what frames I used for calibration but I'll try to find the last revision.

miguelvp · « **Reply #7 on:** June 13, 2015, 04:47:01 am »

Don't know if this will help of confuse people more. I used Visiquest (no longer available, that came up from some old software called Khoros) to do my image processing.

This seems to be a test harness that I was using at the time:

It seems I used frame ID 4 (frame 1) and blend it with frame ID 1 subtracted from frame ID 3. Half a year and some work crunch time I don't quite recall what I was doing. But I'm still going to look for the current code.

miguelvp · « **Reply #8 on:** June 13, 2015, 05:05:45 am »

Of course not the same angle but should be close enough, here is what that section of the router (not on the raw data but the one image I linked above) looked like.

The red color of the Verizon logo doesn't seem to dissipate as much heat as the white letters.

jadew · « **Reply #9 on:** June 13, 2015, 01:40:49 pm »

Thanks for the replies guys. I'll follow your suggestions and I'll let you know what works and what doesn't.

@Miguel
I think frame ID4 (the first one) is very important too, but the problem is that for me it shows a horizontal line (this frame changes), while the raw frames don't have that sort of distortion.

On the other hand, your program seems to generate very nice images.

@John Coloccia
Frame 3 and 4 (IDs 8 and 7) are very similar between initializations, but they're not identical.

I will give it a try tho and see what happens.

Edit:
I gave that a try, didn't work - maybe I didn't do it properly.

For the record, the way I'm applying the calibration frame (ID 1), is by calculating the offset between each pixel and the average pixel value. I am then adding this offset to the actual frame.

I saved a list of 50 frames, in the order in which they are received, for anyone who feels like taking a look. They're saved as 206 x 156 x 16 bit, so every 206 x 2 bytes represents a row. Originally, there are 208 pixels per row, but the last two pixels are useless so I trimmed that out.

As sgstair discovered, pixel 10 (the first dead pixel in the repeating non-noise pattern), is the status/ID byte.

In order to identify a non-noise dead pixel from the repeating pattern you can use the following function:

Code: [Select]

static bool is_pattern_pixel(int x, int y)
{
	int pattern_start = (10 - y * 4) % 15;

	if (pattern_start < 0)
		pattern_start = 15 + pattern_start;

	return x >= pattern_start && ((x - pattern_start) % 15) == 0;
}

miguelvp · « **Reply #10 on:** June 13, 2015, 03:53:03 pm »

@jadew

I think your result looks very clean, you just need to do a bilinear interpolation or some kind of interpolation to despeckle the image.

jadew · « **Reply #11 on:** June 13, 2015, 04:19:33 pm »

@miguelvp

Yeah, it doesn't look bad, but I think it's possible to increase the image quality based on the calibration data. My guess is that once we do that properly we'll end up with a much better image that we can further process.

The rest of the 50 frames set is attached.

jadew · « **Reply #12 on:** June 14, 2015, 06:18:20 am »

Ok, I figured it out, but it turns out miguel already said that this is the case. Frame 1 (ID 4) is the gain compensation frame.

miguelvp · « **Reply #13 on:** June 14, 2015, 06:21:30 am »

That looks nice, any chance you share the code?

jadew · « **Reply #14 on:** June 14, 2015, 06:30:19 am »

I'm going to write a program in Qt and share it when that's done, so in a couple of days. Currently I'm making use of proprietary libraries that I can't opensource.

John Coloccia · « **Reply #15 on:** June 14, 2015, 09:56:33 am »

Did you subtract the dark cal from the flat field frame (i.e. the gain compensation frame?). I think I'd suggested that earlier. I think that's possibly what ID3 is for. Try subtracting ID3 from ID4, and then use THAT as the gain compensation. See if that improves the image even more.

jadew · « **Reply #16 on:** June 14, 2015, 01:45:10 pm »

@ John

ID3 is the image frame and besides ID4, all the other frames have big values for their pixels. In my camera's case, ID4 has values under 300, while all the other ones have values > 4000.

I think ID8 and ID7 can play a role in improving the image quality too, but I can't figure out how. Maybe they'll document these frames when they remove the SDK.

Edit:
I was wrong about the values, ID4 has values up to 4000+.

After a bit more fiddling around, I realized there's still a bunch of noise, but more subtle. It appears that either the gain or the offset drifts a lot, so even if you take a calibration frame to subtract from following frames, the noise will still resurface, fast.

On top of this noise there seems to be a lot of random noise too, so when the dynamic range is small, you get worse performance.

John Coloccia · « **Reply #17 on:** June 14, 2015, 02:44:03 pm »

I guess I'm confused with the frame numbering and such. I'm looking at initial frame 3 and 4. I guess I don't understand what the ID frames are. Glad to see you have it mostly working, though.

jadew · « **Reply #18 on:** June 14, 2015, 03:01:32 pm »

Each frame has an ID that identifies it in its 10th pixel, which is one of the dead ones anyway (there's a pattern of dead pixels, by design).

The first frames have the following IDs:
frame 1: 4
frame 2: 9
frame 3: 8
frame 4: 7
frame 5: 10
frame 6: 5
frame 7: 1
frame 8: 3

After which, you'll periodically get ID 6 and then followed by ID 1 along with a shutter noise. These frames are similar and they serve as offset calibration.
After the offset calibration frames, you'll receive a number of ID 3 frames - actual images.

So, after the initialization sequence, you'll get something like this:
6, 1, 3, 3, 3, 6, 1, 3, 3, 3, 3, 3, 6, 1, 3, 3, 3, 3, 3, 3 etc.

Edit: Typo

Edit 2:
I think you're right. I'm only guessing but I think that those two frames can be used to derive the gain variation. From what I'm reading micorbolometer arrays don't have linear gain, which means that the gain has to be compensated differently based on the value being read.

jadew · « **Reply #19 on:** June 20, 2015, 04:09:01 am »

~~Alright, I attached the executable.~~ The source can be found at https://github.com/rzva/ThermalView.

It should compile on linux too.

~~You'll have to rename the files to ThermalView.zip.001 and ThermalView.zip.002 in order to unzip them - I couldn't upload them otherwise.~~

As you'll notice, the gain compensation is still a bit off, so if anyone can figure out why, I'd very much like to know.

Edit:
~~The files are compressed with the 7zip program.~~

Edit 2:
Single zip file: http://dumb.ro/files/ThermalView.zip

jadew · « **Reply #20 on:** June 20, 2015, 04:34:51 am »

Here's a couple of screenshots.

PS: Sorry for making another post, they didn't fit in the previous one.

miguelvp · « **Reply #21 on:** June 20, 2015, 04:51:04 am »

Thank you so much, I got them and will play with it soon after I'm done with a current project.

BTW, the images look great.

jadew · « **Reply #22 on:** June 21, 2015, 03:20:56 am »

You're welcome, let me know how it goes.

I just did another fix that affects offset calibration correction. The updated binary is on that link, I removed the attachments.

One thing that's worth mentioning is that once it gets to a stable temperature, the pixels stop drifting that much and using an extra calibration frame yields steady results.

frenky · « **Reply #23 on:** June 21, 2015, 05:30:25 pm »

Hi.
I did some comparison of our efforts...

Original seek:

JoeC:

Miguelvp:

jadew:

frenky:

I am really sorry if I didn't correctly use any of your apps. I really tried to get the best results possible out of it.

Together we could get better results than Seek that for sure... But Seeks software has really improved in the last few months.

It would be great is if someone would focus on a better android app. The original one really needs a feature to set fixed temperature range.
If you move the camera the colors matching temps are changing which is really annoying. And you should be able to manually fit color palette into desired temp range.
That is something that I would be really excited about.

BR,
Frenky

jadew · « **Reply #24 on:** June 22, 2015, 07:44:10 am »

@ frenky

Thank you for the comparison.

I was going to add a fixed span option to my program, but I'm still trying to figure out how temperature is calculated.

I suppose some of the values returned during the initialization routine would play a big role in this.

frenky · « **Reply #25 on:** June 22, 2015, 07:59:34 am »

That would be great, because compared to all other apps, yours seems to get the best details out of the sensor.

If you take a look at the pins of the IC. On the image taken with your app pins have really good detail.

jadew · « **Reply #26 on:** June 26, 2015, 07:48:40 am »

@frenky,

I updated the zip file.

I gave up on trying to figure out the temperature for now, but I did add the manual ranging feature. I really don't like this dual slider approach, but didn't have a better control, nor time to write one, so it will have to do for now.

If anyone figures out how to compute temperature reliably, please let me know.

miguelvp · « **Reply #27 on:** June 26, 2015, 08:17:16 am »

Ice, boiling water would be good references for 0 C and 100 C

9 C beer on an old version of my program was giving me 16077 (sensor - calibration)+16384 but not sure if that is the formula I used for the picture. Ambient temp was giving me 16460:

Lamp at 20.6C is room temperature giving me 16451 so about the same as the previous image.
Colder spot about 16C (winter and my office corners seem to leak heat out or let cold in. Value 16299

Ice tray and lighter, ice 14708 this was below freezing (maybe -6C) because I just took it out of the freezer.
Lighter reads 18801 but not sure what temperature that is.

I was borrowing a friend's thermal spot gun, but I never finished calibrating the values and I think this is an old version of the code so the formula might not apply anymore.

Edit: but maybe using the sensor data instead might be better, the ones I posted did subtract the calibration values and added the 16384 offset I used.
Edit2: nope just by looking at the values the only ones that make sense are after subtracting the calibration from the sensor, the offset (16384) helps for the computation to keep the values centered on a 32768 range, 32K values (the 1024 ones that is)

frenky · « **Reply #28 on:** June 26, 2015, 08:18:18 am »

Thank you for your effort.
This new version really is all I need for inspecting electronics from PC.

miguelvp · « **Reply #29 on:** June 26, 2015, 08:26:08 am »

That looks awesome!

jadew · « **Reply #30 on:** June 26, 2015, 08:35:37 am »

@frenky,
You're welcome. I like this feature too

@miguel,
I went that route too, but there are some problems:

1) The values are drifting, which means that the camera might be sending a temperature reading with the calibration frame - or it's telling us how to compensate in some way.

2) I don't think it's linear. I tried to calibrate it against a 250 °C span and I couldn't deduce the value count/degree. It's possible that there's an offset involved.

3) We don't know where this calibration data might be or how the camera figures out the temperature of the calibration frame.

miguelvp · « **Reply #31 on:** June 26, 2015, 07:22:40 pm »

I was running numbers last night and did find some correlation but I was too tired, So I'll continue later tonight.

I think it's a log base 6 ratio or something like that but my brain was fried so I probably was doing something stupid.

Trax · « **Reply #32 on:** June 26, 2015, 09:29:11 pm »

is the source for this custom application to be found some ware?

jadew · « **Reply #33 on:** June 26, 2015, 09:37:25 pm »

https://github.com/rzva/ThermalView

jadew · « **Reply #34 on:** July 04, 2015, 09:42:06 am »

I just added an option for bilinear and bicubic interpolation. Zip file updated.

frenky · « **Reply #35 on:** July 04, 2015, 10:10:34 am »

This is really great and image also resizes if you resize window.

A nice feature would be a checkbox below Save button with text "Capture image after calibration".
So the app would wait for shutter cal before taking image. Because those images contain the least noise.

And in this version I noticed some blinking of the image. Image vanishes for a few milliseconds and then reappear.

I hope you won't take my comments the wrong way.
In think you app is really great I'm just brainstorming on how to make it even better.

jadew · « **Reply #36 on:** July 04, 2015, 10:20:09 am »

Quote from: frenky on July 04, 2015, 10:10:34 am

A nice feature would be a checkbox below Save button with text "Capture image after calibration".
So the app would wait for shutter cal before taking image. Because those images contain the least noise.

It's been doing this since the first version, that's what the "Take One" button does

About the flickering, does it happen only when you resize or all the time?

Edit: I guess I should add a tooltip for when you hold your mouse over that button. I realize now that it's not particularly clear what it does.

frenky · « **Reply #37 on:** July 04, 2015, 10:47:58 am »

I see... I did't know that, then there is no need for checkbox I'll just use the button.

One more suggestion.

I would prefer to select location on fist save and then just press the "Save" button (to save new images with timestamp as a name) without browse function.
It would save a lot of time. But I guess it could be confusing to somebody else...

The flickering it's totally random... If I start app without changing any settings:
First blink could be 2 seconds after start or 30 seconds. And then there could be no blink between shutter cals or there were as much as 5.
Easiest solution would be to just use black color behind image on the form, so when image disappears our eyes wouldn't even notice it.

BTW: the quality of images is now really fascinating. I have absolutely no regrets of not waiting for Flir One v2.

jadew · « **Reply #38 on:** July 04, 2015, 12:40:46 pm »

I updated the zip with the flicker fix. Please let me know if it works.

About the auto-naming suggestion, I like it but I won't have time to implement it until next weekend.

Also, do you think it could use more color profiles? They're rather easy to make but I'm not sure what else to add.

frenky · « **Reply #39 on:** July 04, 2015, 01:07:27 pm »

Take your time...

I don't know about more color palettes because 99% of the time I use "iron" and the other 1% the "rainbow".

What you could also improve is manual correction of the range.
Currently only a very small section of the sliders is usefull, so you have to click very carefully to not overdue it.
It would be better if the auto calculated range would account for 50% of the whole sliders so that it would be easier to precise tune the sliders manually.
I hope you understand what I mean since my english is mediocre at best...

frenky · « **Reply #40 on:** July 04, 2015, 01:13:14 pm »

And flickering is gone in new version.

I waited 1 minute before clicking anything and after that I changed all the settings. No flickering.

jadew · « **Reply #41 on:** July 04, 2015, 05:13:18 pm »

I know what you mean about the range thing and I thought about that too. It can't be done like that because it would wiggle a lot.

I already thought of a solution, but it requires a bit more time than I have available right now.

Trax · « **Reply #42 on:** July 04, 2015, 08:38:45 pm »

What do you think is better the normal seek or the XR one?

jadew · « **Reply #43 on:** July 05, 2015, 01:43:38 am »

@ Trax,

The XR, it can focus down to 12 cm or so, out of the box. For what we're doing it perfect, for surveillance you might want the regular one, which has wider field of view.

frenky · « **Reply #44 on:** July 07, 2015, 10:08:50 am »

Quote from: jadew on July 04, 2015, 05:13:18 pm

I know what you mean about the range thing and I thought about that too. It can't be done like that because it would wiggle a lot.

One way to do it would be to just hide both sliders while in auto-range mode.
Because sliders do not add any usefull function to the app if you have auto-range on.

So show the sliders only when autorange is off and there will be no wiggle...

frenky · « **Reply #45 on:** July 08, 2015, 07:42:39 am »

I was thinking about palettes...
Real cool feature would be to let users design their own palettes.
You could read user defined palettes from files on the root with extension ".palette".

Your "iron.palette" would contain:
#000000
#000066
#7C009D
#F07000
#FFCC00
#FFF060
#FFFFFF

So user could go to http://html-color-codes.info/ and pick their own colors like this:

And put color codes in file mynewpal.palette :
#000000
#070719
#0B0B61
#0000FF
#BF00FF
#FF00BF
#FF8000
#FFFF00
#FFFFFF

I think that would be really cool.

And could you please explain to me how to open your ThermalView solution in VS. I got bunch of errors when I tried to build it.

Tnx.

jadew · « **Reply #46 on:** July 13, 2015, 07:32:32 pm »

Sorry for the late reply, I was on vacation.

I suppose there's no way around the custom palette thing, I'll find some free time and do it like that.

The auto-hide thing for the sliders - tried it before releasing it, it's not working well because the available space for the image changes and it looks weird. On top of that, having it always on gives you a bit more info on the temperature spectrum.

I understand that while I was on vacation they announced the beta version of the SDK. Hopefully some more complete and better applications will emerge.

frenky · « **Reply #47 on:** July 14, 2015, 08:24:52 am »

No pressure, take your time.

I doubt that we will be able to get better images with SDK than with your app.
Quality will probably be the same as with android app.
(I hope I'm wrong)

jadew · « **Reply #48 on:** July 17, 2015, 01:46:09 pm »

I made another update. Now the profiles are file based and it has a rudimentary profile editor you can use to create your own profiles.

I also added the option to save in raw format (when saving 206 x 156 images), because I saw that requested in the other thread.

PS: Please share if you come up with some nice profiles.

frenky · « **Reply #49 on:** July 17, 2015, 03:32:08 pm »

Great. I'm on vacation but I'll test it when I came back.

Sent from my LG-D855 using Tapatalk

jadew · « **Reply #50 on:** July 17, 2015, 04:07:40 pm »

Nice. Have a good vacation!

Edit:
Made some changes to the editor and added a new theme that I think adds more contrast when inspecting PCBs.

Edit 2:
I added a little histogram. It should be possible to create a profile that adjusts itself based on the distribution of values, but I'm not sure it's worth the time.

frenky · « **Reply #51 on:** July 20, 2015, 05:44:01 pm »

Tnx for this new palette editor.

I've converted 12 Flir and 3 Therm-App palettes. All are in the attachment.
F-*=Flir
TA-*=Therm-App

frenky · « **Reply #52 on:** July 20, 2015, 05:46:07 pm »

Demo:

F-Arctic:

F-BlueRed:

F-Glowbow:

F-GrayRed:

F-Iron:

F-Lava:

F-Rain:

F-Rainbow:

F-RainHC:

F-Saturation:

F-Yellow:

TA-BlueYellow:

TA-PurpleYellow:

TA-Rainbow:

jadew · « **Reply #53 on:** July 20, 2015, 07:57:47 pm »

Thanks a lot, that's absolutely awesome!

Edit:
Any idea on weather Flir or ThermApp have any legal rights over these palettes? I was going to ask if I could add them to the app, but then this came to my mind.

Now I'm actually considering removing the Iron and Amber theme too, because they're inspired from the ones in the app.

frenky · « **Reply #54 on:** July 20, 2015, 08:42:24 pm »

I don't know about legal rights.
I guess there could be a problem if we used exact Flir or Therm-App palettes (or files) in the app, but this ones are only a approximation of those palettes...

jadew · « **Reply #55 on:** July 20, 2015, 09:21:59 pm »

Yeah, I don't know either. Maybe someone with some legal experience can shed some light on how these things go.

kingjamez · « **Reply #56 on:** July 22, 2015, 01:47:23 pm »

I'd like to try out Thermal View. I've downloaded the zip. I've searched and I can't find windows drivers for the seek thermal camera. When I click "connect" it says "Failed to communicate with the USB device". Where can I find the drivers?

It seems the rest of the members have figured this out... but I'm beating my head against the wall.

Help!

-Jim

frenky · « **Reply #57 on:** July 22, 2015, 01:52:16 pm »

Install this:
http://zadig.akeo.ie/

Follow the instructions:
https://github.com/pbatard/libwdi/wiki/Zadig

frenky · « **Reply #58 on:** July 22, 2015, 01:58:28 pm »

You should also check that your USB cable has sense pin in female micro usb connected to ground like this:

Good option is also to use regular USB cable and solder this pcb to it:

http://goo.gl/2VAaOp
And connect ID pin to the ground...

kingjamez · « **Reply #59 on:** July 22, 2015, 02:14:35 pm »

Wow, that was fast. Thank you very much.

-Jim

jadew · « **Reply #60 on:** July 22, 2015, 02:19:03 pm »

Did it work?

kingjamez · « **Reply #61 on:** July 22, 2015, 02:51:20 pm »

Indeed it did, got it working within 5 minutes of reading the post. I'm currently at work so can't really dive deep, but so far so good. I'm running it on my Teclast X98 windows 8 tablet.

-Jim

sguyader · « **Reply #62 on:** September 15, 2015, 01:37:44 pm »

Hi,

I'm new to this board, I got interested in this topic because for my research, I need to get thermal images of plants leaves with fungal disease necrotic lesions. More precisely, I want to investigate temperature differences between center, border necrotic, and healthy leaf areas.
As a starting project, I don't want to invest a lot of money, so the Seek Thermal XR seems to fit a good part of the bill.

In the end, I need to retrieve data from the camera frames, that I can translate to temperature, or at least to be able to compute température differences between different image areas. How far are you guys from getting this kind of data out of the Seek Thermal using your the software you develop?
Some collegues of mine will probably also be interested to get thermal images and control the camera from a Raspeberry Pi board in programmed time lapse.

Thanks in advance, and if I didn't ask my question to the right forum, feel free to let me know!

-Sebastien

encryptededdy · « **Reply #63 on:** September 17, 2015, 12:25:32 pm »

It sounds like for your project you will be dealing with low temperature differentials. Perhaps the Seek is not the best for that use, as the sensitivity of the Seek is not particularly good.

It also sounds like resolution isn't a huge deal. If that is the case, I would try the FLIR Lepton dev kit. It'll hook up to a Pi easily and it also has better sensitivity than the Seek. However it is only 80x60 resolution so you have to be aware of that.

sguyader · « **Reply #64 on:** September 17, 2015, 01:46:48 pm »

Thanks encryptededdy!

kc-in-ual · « **Reply #65 on:** January 22, 2016, 03:18:33 am »

The link seems not working:
http://dumb.ro/files/ThermalView.zip
That would be great if the file can be uploaded again

To compile ThermalView https://github.com/rzva/ThermalView, I encountered errors like this:

Code: [Select]

1>MainDialog.cpp(482): error C2039: 'value_type' : is not a member of '`global namespace''
1>MainDialog.cpp(482): error C2146: syntax error : missing ')' before identifier 'value_type'
1>MainDialog.cpp(482): error C2059: syntax error : ')'
1>  thermal.cpp
1>  wxcrafter.cpp
1>  wxcrafter_bitmaps.cpp
1>  wximageview.cpp
1>thermal.cpp(342): error C2675: unary '!' : 'boost::synchronized_value<T>' does not define this operator or a conversion to a type acceptable to the predefined operator
1>          with
1>          [
1>              T=bool
1>          ]
1>thermal.cpp(359): error C2451: conditional expression of type 'boost::synchronized_value<T>' is illegal
1>          with
1>          [
1>              T=bool
1>          ]
1>          No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
1>thermal.cpp(388): error C2675: unary '!' : 'boost::synchronized_value<T>' does not define this operator or a conversion to a type acceptable to the predefined operator
1>          with
1>          [
1>              T=bool
1>          ]

Just to make sure I get the libraries right:

wxWidget 3.0.2 vc110
libusb-1.0.20
boost 1.58 vc110
Visual Studio 2013
Platform toolset Visual Studio 2012 (v110)

Am I missing anything? Any advice will help! Thanks~

kc-in-ual · « **Reply #66 on:** January 22, 2016, 06:52:42 am »

Problem solved.

wxWidget 3.0.2 vc120
libusb-1.0.20
boost 1.58 vc120
Visual Studio 2013 with platform toolset v120

Also

Compile the wxWidget and boost for the *.lib. Pre-built binaries may work but didn't work on me (using win10, maybe it was the problem)
You may want to add "boost_thread-vc120-mt-gd-1_58.lib" to your library path in the project setting before compiling
Make sure you are using USB OTG cable to connect SEEK to your PC's usb port

Just in case someone want to try it without compiling: http://www.megafileupload.com/eksJ/ThermalView_debug.rar

frenky · « **Reply #67 on:** January 22, 2016, 08:10:19 am »

Tnx for this.
I was trying to get this VS project running without success in the past. Now I'll try again...

I did manage to build it in CodeLite (Win7 32bit) but when I run the executable I get:

Quote

Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1008,STL containers,compatible with 2.8 ),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1002,STL containers,compatible with 2.8 ).

It seems to be a wxWidgets bug:
https://groups.google.com/forum/#!topic/wx-users/bzXESX__828

frenky · « **Reply #68 on:** January 23, 2016, 03:45:09 pm »

I gave up trying to get this jadew's project run successfully in CodeLite or VS.
So I went with another approach...

I studied his code and used his algorithm for fixing gain and offset of the pixels.
Then I applied my own noise reduction and the result is something that I'm very pleased with.

This is image of a room corner with approx 3*C temp range:

Android app produces this (notice the big dust circle top right...; not sure why app crops the image)

"My" new app (Most credits should go to: sgstair, miguelvp, jadew):
Image has a lot more details and contrast in it. And on the left you can clearly see the stud in the wall (drywall).

And with some median averaging of multiple frames the image becomes really clean:

miguelvp · « **Reply #69 on:** January 23, 2016, 05:04:17 pm »

Quote from: frenky on January 23, 2016, 03:45:09 pm

...
This is image of a room corner with approx 3*C temp range:

"My" new app ... with some median averaging of multiple frames the image becomes really clean:

Very, very, very NICE

frenky · « **Reply #70 on:** January 23, 2016, 07:57:54 pm »

Tnx.

I'll post the code here after I clean it up a bit...

efahrenholz · « **Reply #71 on:** January 23, 2016, 09:30:32 pm »

Could any of you post some shots outside? I'm curious to see the resolution at a distance with variations in thermal contrast. I honestly doubted that the sensor was capable of anything useful but you guys have made real progress here. With some smart image processing, you all have managed to squeeze the near real resolution out of this thing and that increases the value tremendously. Also, any chance you might port this code to android? I'm half tempted to buy another seek. I was very close to buying the i3 thermal expert but they require a bank wire and to me that seems to be a bit too much effort... How do you develop a product without a storefront or transaction system? Anyways, with this improvement, it starts looking more like a 320x240 camera and not a 160x120 camera.

frenky · « **Reply #72 on:** January 24, 2016, 12:53:44 pm »

I did this in a few minutes because it's freezing outside and I have no desire to be out with a laptop for an hour trying to make a good thermal photo...

Scene:

Seek image (perhaps I did not pick the best thermal range, but it is what it is...)
In IrfanView I resized it to 200% (B-spline) and corrected gamma for better contrast:

Original:

frenky · « **Reply #73 on:** January 24, 2016, 10:27:05 pm »

Edit: I started a new thread: https://www.eevblog.com/forum/thermal-imaging/seekofix-new-windows-software-for-seekthermal/

jadew · « **Reply #74 on:** January 24, 2016, 10:48:22 pm »

@frenky, nice job!

Was hoping that someone will continue working on this. Looking forward for your releases

frenky · « **Reply #75 on:** January 24, 2016, 10:56:31 pm »

A BIG THANKS to you for showing us how to get nice clear images out of the sensor.

That pixel gain stuff with frame ID4 is golden.

frenky · « **Reply #76 on:** April 14, 2016, 07:00:43 pm »

Let's continue this topic (https://www.eevblog.com/forum/thermal-imaging/seekofix-new-windows-software-for-seekthermal/msg918372/#msg918372) here:

I have now extracted ID9 values as suggested. The chart really looks the same.

So does this mean that value 2000 is -40*C and value 13316 is 350*C? What about the last "bump" with values from 15819 to 16383?

IwuzBornanerd · « **Reply #77 on:** April 16, 2016, 04:53:37 pm »

Quote from: frenky on April 14, 2016, 07:00:43 pm

Let's continue this topic (https://www.eevblog.com/forum/thermal-imaging/seekofix-new-windows-software-for-seekthermal/msg918372/#msg918372) here:

I have now extracted ID9 values as suggested. The chart really looks the same.

So does this mean that value 2000 is -40*C and value 13316 is 350*C? What about the last "bump" with values from 15819 to 16383?

That is the way I have been using it, except I use 626F.

My data also starts at 2000 & peaks at 13316, with 13316 in pixel 14635. It works out to something like 21.95 "pixels" per degree Fahrenheit. The number wasn't any nicer for Celsius so I kept the more familiar (to me) units.

Is your 13316 value in pixel 14635? It would be nice if everybody has the same thing in frameID9--easier to handle it in software. I re-load it into an array with the pixel's value as the index and the new array value as 22 times the temperature above -40. Then once I obtain the "diff" scaled by the frameID10 correction factor, I pull the temperature out of the array element number that matches that "diff". The "diff" is taken from the location of the sensor/shutter on the curve.

The next key to this is that pixel 1 in the image & cal frames gives an indication of the temperature of, well, "somewhere" in the camera. I say "somewhere" because it lags the sensor/shutter temperature during warmup and once the camera has stabilized the pixel 1 indicator is around 15(?) degrees F below the sensor/shutter temperature. The number in pixel 1 drops by about 10 per degree F as the camera warms up and appears to be a difference value from a seemingly arbitrary reference point on the curve. I currently define that reference point as 7679, empirically determined from tests I have run. I think that puts the reference point at about 180C.

I have not been able to conjure up any reasons for that squiggle after the discontinuity. I wonder if it means something, but have no clue what it would be.

frenky · « **Reply #78 on:** April 18, 2016, 08:45:32 am »

Quote from: IwuzBornanerd on April 16, 2016, 04:53:37 pm

Is your 13316 value in pixel 14635?

Yes it is.
I've attached all ID9 values in text file.

Quote from: IwuzBornanerd on April 16, 2016, 04:53:37 pm

The next key to this is that pixel 1 in the image & cal frames gives an indication of the temperature of, well, "somewhere" in the camera.

Wow that is really interesting and very useful.

I will sure look into it.

IwuzBornanerd · « **Reply #79 on:** April 19, 2016, 12:25:29 am »

Thanks for the upload frenky. Except for a few extra carriage returns and corrupted numbers at line 6210 and 22785, yours is exactly the same as mine. I'll put mine up here for good measure.

According to the view counter on your graph image, this page has been popular since you posted that...but nobody else is chiming in to say "Hey mine's different." or otherwise. Maybe not enough time yet...

miguelvp · « **Reply #80 on:** April 19, 2016, 12:48:09 am »

Quote from: IwuzBornanerd on April 19, 2016, 12:25:29 am

Thanks for the upload frenky. Except for a few extra carriage returns and corrupted numbers at line 6210 and 22785, yours is exactly the same as mine. I'll put mine up here for good measure.

According to the view counter on your graph image, this page has been popular since you posted that...but nobody else is chiming in to say "Hey mine's different." or otherwise. Maybe not enough time yet...

Not enough time here to look, but I did post a while back the raw data for the first 20 raw frames in this post:
https://www.eevblog.com/forum/thermal-imaging/yet-another-cheap-thermal-imager-incoming/msg545880/#msg545880

ID9 should be the 2nd frame.
They are 16 bits per pixel, little endian. Each frame is 208 by 156, 2 bytes per pixel unsigned int16, so the 2nd frame would start at byte 64896 (if 0 based) and it should be also 64896 bytes long.

Note that the data is from a very old firmware, but that will indicate if it has changed in future releases.

frenky · « **Reply #81 on:** April 19, 2016, 08:23:30 am »

My next step will be to record values for 1 hour of:
- second pixel of calibration frame ID1
- average value of calibration frame ID1
- average value of isothermal plate at room temp

So we can see what is exact correlation between sensor temp and shutter temp.

Then I'll strap Peltier module on the back of the Seek to cool it down and repeat the process while trying too keep it's temp at 10*C (50*F).
Housing is made from magnesium alloy so it should be a good thermal conductor.

IwuzBornanerd · « **Reply #82 on:** April 19, 2016, 07:37:35 pm »

You will therefore find the attached file interesting. I did a similar thing about a week ago, while considering how to track the startup variation. Rather than taking the average of the entire frame, I chose a pixel for which the correction factor in frameID10 is 100 percent. That pixel was #118. For a total of 12000 frames (starting with the very first image frame from a cold camera) I had the code write the following to a file: frame number, pixel 1 value, pixel #118 value for image & cal frame, difference between the image & cal pixel 118 values, and the value of pixel 40 from the image frame. Pixel 40 appears to be a frame count from the sensor itself. It increments 4 for every image frame and 17 when there is a cal frame. You might toss that in for your run just to watch it roll over at around half an hour.

I didn't get to see that because mine is only about 20 minutes.

The most surprising thing I see in the file is that the pixel values start out (for 2 frames) in the 6000 range and then jump over 2000 before slowly dropping to below 6800 and then jumping more than 2000 again at frame 1741. I have not read up on how they implement these sensors, but I am guessing that the way they read them is by applying a known current to the pixel & reading the voltage. If that is the case then perhaps what they are doing here is when the voltage gets below a certain point they up the current in order to keep the voltage in the upper range of the A/D that is reading it. After frame 1741 the values never got below 8000, so I didn't see another jump. I think I saw a jump at the 3rd frame even with a warmed-up camera, but it wasn't as big a jump, and I only ran it 12000 frames one time.

Based on this test, I suspect you will find things stable long before your hour is up.

frenky · « **Reply #83 on:** April 19, 2016, 07:45:00 pm »

I know what you mean by pixel values jumping. Here are charts that capture that: https://www.eevblog.com/forum/thermal-imaging/yet-another-cheap-thermal-imager-incoming/msg791796/#msg791796
From those charts (that show 1 hour of data) you can see that Seek needs approximately half an hour to stabilise.
Best seen here:
https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/?action=dlattach;attach=179925;image

IwuzBornanerd · « **Reply #84 on:** April 19, 2016, 07:53:42 pm »

Oh, I forgot I was going to say you might try using that Peltier module to make a uniform temperature surface & look for the temperature at which the image-cal diffs are around zero--that would be the temperature of the shutter. You would probably want the diffs scaled by frameID10 factors to be the ones around 0, though. I used a tray of heated water to sort of zoom in on that value & that is where I got my empirical value for the reference point on the curve. I think I didn't scale the diffs, though...

I hit "post" and it came back saying someone replied while I was typing, so I'll reply to your reply here...I think I saw those graphs before. The old "picture is worth 1k words"; it's just that the variation is not fast enough to see in the list of numbers.

frenky · « **Reply #85 on:** April 19, 2016, 08:03:43 pm »

Your captured data is interesting... Pixel1 data (sensor temp) goes down by 200 in half an hour while difference between shutter temp and external temp changes by 400 (approx) because of shutter heating up.

IwuzBornanerd · « **Reply #86 on:** April 19, 2016, 08:15:28 pm »

Kind of makes you wonder if maybe pixel 1 variation is supposed to be only half of the diff, huh? But the diff keeps changing after pixel 1 settles down...but they bounce up & down too much.

frenky · « **Reply #87 on:** April 19, 2016, 08:23:09 pm »

I'm not at my pc any more so I can't post charts showing diff and pixel1 change. Both looked very similar but pixel1 chart was much smoother.

frenky · « **Reply #88 on:** April 20, 2016, 10:49:03 am »

Top line shows "increase" in sensor temp.
Bottom line shows difference between shutter and external temp though time.

IwuzBornanerd · « **Reply #89 on:** April 20, 2016, 08:42:53 pm »

That makes it look like they both settle at about the same time, except for that drop in diff at the end. I finally pulled that into LibreOffice here & looked to see if there was a smoothing function to apply to the diff curve but I didn't find one.

I think in his teardown video mikeselectricstuff identified a temperature sensor chip on the back of the board, so I expect that is where the pixel 1 value comes from, and why it is less noisy. The sensor output seems to have several degrees F of random noise. Again, the graphs suggest that I should use 2x the change in pixel 1 to adjust the temperature readings. Doing so would move what I call the sensor (actually shutter) reference point up on the curve--ALMOST to the top of the curve. If it was exactly at the top or close enough to be reasonable I would say "That's it", but my calculation puts it at 12110 which is about 55*F from the top of the curve.

frenky · « **Reply #90 on:** April 25, 2016, 07:16:55 pm »

Today I had time to play with Seek...

I recorded 1.5h of data. Seek was facing black alu plate with temp approx 20*C/68*F.
Log file is in the attachment.

Columns:
- ID1pix1   (Sensor temp, value of second pixel in calibration frame ID1)
- ID1avg   (average value of calibration frame)
- ID3avg   (average value of first image frame after calibration)
- FinalAvg    (average value of final-corrected image with gain data)
- FinalMode (mode of this final frame)

If I take avg of final image and subtract ID1pix1*1.6 from it I get stable temp reading after 5min. So for my Seek this would work. I'm not sure if this is the same for all modules.

Blue is sensor temp (values go down but the temp actually goes up).
Red is difference in avg avalues of calibration and image frame (shutter is heating up).
Green is final image corrected by sensor temp.

Without this pixel1 fix we would have to wait at least 20min for temp readings to stabilise. But with this fix 5min is enough.

(Chart shows 1h of data)

frenky · « **Reply #91 on:** April 26, 2016, 08:26:11 am »

Another interesting observation from this data...

If we look at the ID3avg data we can see as the sensor was heating up the raw values went down even though the actual temperature of the alu plate was constant.
So by actively cooling sensor we should gain on thermal sensitivity. (Probably old news to thermal experts

)

IwuzBornanerd · « **Reply #92 on:** April 27, 2016, 06:08:37 am »

You had a long day!

I was confused for a while but I think I understand now...

The fact that you only captured the cal frames & the one image immediately after them makes it look like the pixel1 value changes faster than mine does. When I looked at my 20 minute warmup run I thought that pixel1 did not change enough to be used to compensate for the warmup drift because it hardly changes between image frames and the warmup change in the image is mostly due to the infrequency of the cal frames. The first 4 cal frames last no more than 5 image frames but it then switches to 20 images per cal frame--on my camera at least--and then 60. You can see by the slope of your chart that the image "diff" changes faster in the first 5 or 10 minutes than the pixel1 value does. I was looking into tracking the startup change when I ran that 20 minute test. What I decided to do was use the "corrected" diff from one pixel in consecutive cal frames to decide whether and how much to adjust the temperature. I don't get as much variation in the image with that scheme, but the temperature is still off until the camera is stable. The temperature is off anyway now because I keep messing with things.

I see a "red flag" here too, in that your pixel1 is about 1000 less than mine for the same temperature, but the delta from "cold" is the same once the temperature is stabilized. I was thinking this would be a knowable measure of temperature for all cameras, but I guess we have not found that link yet...

IwuzBornanerd · « **Reply #93 on:** May 24, 2016, 07:45:27 am »

On the topic of improving (or "correcting") the image, I have tried averaging pixels from 4 consecutive frames and did not see any improvement--it only slowed down the dancing pixels, but I get a much nicer image if I average adjacent pixels of the same frame. I am amazed at how this brings out details rather than obscuring them.

I tried it with averaging in the 4 pixels above & below and to each side (for a total of 5), and then the 4 diagonal pixels, and then all 8 surrounding pixels (for a total of 9). The 9 pixel average looks less noisy but seems to have a bit less detail--more "mushy".

I originally did the averaging AFTER the curve 9 temperature lookup, but it looks about the same if I do the averaging on the scaled "diffs".

I have uploaded sample images of my test wall corner with my cathedral ceiling; the first is with no averaging, then the 5 pixel "+" configuration, then the 5 pixel "x" configuration, then the 9 pixel average. The hot spot in the images is the heat register in the ceiling. I had it "toasty" warm in the house at the time.

Bill W · « **Reply #94 on:** May 24, 2016, 09:20:06 am »

If averaging sucessive frames does not work, this is potentially very interesting. Had you made s to average 'live' frames, not duplicates produced to drop to 9Hz ?

If so then this suggests that the main problem is in the 'ffc' frame and is therefor correctable if you can get access to the right point in data processing

Bill

www.fire-tics.co.uk

IwuzBornanerd · « **Reply #95 on:** May 25, 2016, 02:14:55 am »

What I did was what I'd call a moving average of the 9fps camera frames. I defined a set of arrays, frame1, frame2, frame3, frame4 and as each frameID3 came along I'd shift the saved frames down the line & put the new one in frame1. I'd make an average of each pixel across the 4 arrays & use those averaged pixels for the output image.

After making that last post I saw the new activity on https://www.eevblog.com/forum/thermal-imaging/seek-thermal-hardware-modification-to-improve-image-quality/25/ in which frenky got improvement with 20 "stacked" frames. If by "stacked" he means averaged, then perhaps I did something wrong in my code OR maybe my 1 degree Fahrenheit granularity masks the improvement (OR maybe a mere 4 frames wasn't enough!). All of my images are one color per degree Fahrenheit (or half degree C if I show temp in C). I don't know what degree resolution frenky is showing there. If he's displaying 1-bit "diff" resolution then he has about 3 bits finer than mine. By the way, frenky, that's quite a nifty cooling system you have there.

You might have noticed in the images in my preceding post that there is a splotchy pattern in the image, sort of a remaining "fixed pattern noise" even after applying the fremeID10 (or "user generated" scaling factors). I see the same sort of thing in some of the images people have posted on these Seek threads, such as those posted by havaloc here https://www.eevblog.com/forum/thermal-imaging/seek-vs-flir-one-g2-images/?topicseen . I have found that this is related to the correction factors, as I get a different pattern if I use my own set as opposed to frameID10.

It has become my obsession to get rid of that pattern but I have yet to be truly successful at it. I finally just subtracted the actual temperature from the lookup values of each pixel of one frame from a uniform temperature surface and used the remainder as a correction in my software. Dividing the pixel temperature by the actual temperature to create scaling factors had about the same effect. This produces a rather nice image, but only at temperatures near the temperature where I made the correction values. So the pattern is related not only to the correction factors but also to the camera temperature and maybe the scene temperature.

The first image attached below is the wall corner with the 9 pixel average from before AND the pattern subtracted. The second one is a few feet to the right, the wall above my fireplace, with the pattern. The third one is that image with the pattern subtracted.

I have pretty much given up on using frameID4, 7, & 10 and am trying to come up with my own correction schemes. Doing so, I recently discovered that if I take an image of a room temperature surface with the camera stabilized and create a set of pixel correction factors by dividing each "diff" by -400 (or maybe even any number between -400 & -500) I get just as clean an image without doing any pattern subtraction, but still only at temperatures within a few degrees of that particular room ambient. The non-averaged image is much better with that set of correction factors also.

The 4th image attached is the fireplace wall with those correction factors but NO pattern subtraction.

A bit later I made a similar set of cal factors using 5 averaged frames and that is what I am using now. The 5th image is a fresh one from just now with the camera hung about 10 inches above my tabletop & set to minimum focus distance. The 6th image is the same with NO pixel averaging. Compare those with the averaged & non averaged images in my preceding post!

As a point of comparison, I edited my code to use the frmeID10 correction factors instead of my latest ones and the last 2 images are the tabletop with those factors and with the 9 pixel averaging (7th image) and without the 9 pixel averaging (8th image). Since I had to restart the program, I couldn't put the markers back in the same spot.

I find that the pattern returns at other camera temperatures. The 9th image is the ceiling above the camera with the camera's pixel 1 value at 4192, close to the 4198 value where the cal values were made. The 10th image is the same ceiling with the camera lying in this laptop's "exhaust", heating it to a pixel 1 value of 4060. I'm not sure if the temperatures are off due to the camera not being stable yet or what; I didn't note whether it was stable.

I am now trying to figure out what the temperature dependance is; it may be a while...especially since I need to get something else done.

frenky · « **Reply #96 on:** May 25, 2016, 10:21:43 am »

Quote

If by "stacked" he means averaged

Yes I'm using ImageMagick "convert *.png -evaluate-sequence median OUT.png" to get median average of multiple images.

Quote

I don't know what degree resolution frenky is showing there.

If I take an image of isothemal plane I get about 5*C of temp difference. That is because of shutter heating up.
It seems that your Seek does not have that issue?

I will put all my efforts now into effectively cooling Seek with heatsink small as possible. (I'll put precise temp sensor inside for realtime temp regulation.)

IwuzBornanerd · « **Reply #97 on:** May 26, 2016, 07:09:39 am »

Quote from: frenky on May 25, 2016, 10:21:43 am

Quote
If by "stacked" he means averaged

Yes I'm using ImageMagick "convert *.png -evaluate-sequence median OUT.png" to get median average of multiple images.

Thank you. For comparison purposes, do you see noticeable improvement if you only average 4 frames?

Quote from: frenky on May 25, 2016, 10:21:43 am

Quote
I don't know what degree resolution frenky is showing there.

If I take an image of isothemal plane I get about 5*C of temp difference. That is because of shutter heating up.
It seems that your Seek does not have that issue?

I will put all my efforts now into effectively cooling Seek with heatsink small as possible. (I'll put precise temp sensor inside for realtime temp regulation.)

By "resolution" I was referring to how you assign the colors. Does a change of 1 in the diff value cause a color change or is it more like a change of 10 in the diff? OR is it based on a fraction of a degree C? The image will appear more noisy, of course, if a difference of a tenth of a degree is displayed as a different color. In my images I only display a different color for differences of 1*F, or half degree C when C is displayed. Oh, and are you using the frameID9 curve to determine temperature now?

As for whether I have a 5*C variation across the image, I have seen about that much at times, but right now it seems not that bad. I'm attaching some samples. You already have the room temp. table top above, here are ice at -14*F (per IR thermometer), water at 40*F from the refrigerator, and water at 145*F from the microwave oven. The hot water is swirling as it cools so it apparently is not uniform temp anyway.

frenky · « **Reply #98 on:** May 26, 2016, 07:54:59 am »

Quote from: IwuzBornanerd on May 26, 2016, 07:09:39 am

Thank you. For comparison purposes, do you see noticeable improvement if you only average 4 frames?

I'm at work so I can't do it right now but I would say that it does show improvement. If its a lot better with 20 frames then it's probably is at least a little better with 4 frames.
But you have to know that I don't average sequenced frames. Instead I take many "first after calibration" frames because this frames have least noise.

Quote from: IwuzBornanerd on May 26, 2016, 07:09:39 am

By "resolution" I was referring to how you assign the colors. Does a change of 1 in the diff value cause a color change or is it more like a change of 10 in the diff? OR is it based on a fraction of a degree C? The image will appear more noisy, of course, if a difference of a tenth of a degree is displayed as a different color. In my images I only display a different color for differences of 1*F, or half degree C when C is displayed.

I do it like this. If temp range on image is 5 degrees then this 5 degrees get mapped to 1000px color palette which has 1000 different colors. If we say that 1 degree is 40 raw diff then I map 200 raw values to 1000 colors. So each raw value has it's own color.

Quote from: IwuzBornanerd on May 26, 2016, 07:09:39 am

Oh, and are you using the frameID9 curve to determine temperature now?

No I'm totally focused on cooling sensor.
With cooled sensor I'll get stable values and will be able to to map actual raw values to exact temperatures. No need for sensor to stabilise or to fix values with ID9 frame.

I probably could use ID9 for reference temp for cooling sensor but I prefer more PC independant solution: NTC resistor inside seek -> microcontroller -> mosfet -> peltier

IwuzBornanerd · « **Reply #99 on:** May 26, 2016, 08:15:14 pm »

Quote from: frenky on May 26, 2016, 07:54:59 am

But you have to know that I don't average sequenced frames. Instead I take many "first after calibration" frames because this frames have least noise.

I suspected that.

Quote from: frenky on May 26, 2016, 07:54:59 am

I do it like this. If temp range on image is 5 degrees then this 5 degrees get mapped to 1000px color palette which has 1000 different colors. If we say that 1 degree is 40 raw diff then I map 200 raw values to 1000 colors. So each raw value has it's own color.

I see. That's good, and it explains why so much noise shows. I use one degree per color not to hide the noise but just because it's pointless to show more if the accuracy is not there. I did finally add a "marker zoom" feature to allow quarter degree C resolution, though, in case I ever get the pattern out of there.

What pixel values are you seeing in frameID 1 & 3 with the camera cold? 14k to 16k range??

frenky · « **Reply #100 on:** May 26, 2016, 08:49:25 pm »

With 0.5A and 2.4V to peltier module the back of the seek (on the outside) is cooled to 15*C. Room temperature is 25*C.
Average ID1 is 7800 and average ID3 is 7900 which would suggest that shutter temperature is about 22.5*C.

IwuzBornanerd · « **Reply #101 on:** May 26, 2016, 08:59:30 pm »

Oh, you aren't cooling it as cold as I thought you were. I put mine in the refrigerator one time (near freezing) & as I recall the histogram of the first image I got after removing it from the frige showed a narrow span of values near the 16k end.

IwuzBornanerd · « **Reply #102 on:** August 13, 2016, 01:18:32 am »

Sadly I have not found out how to get rid of the blotchy pattern in the images, but I think I have found a way to make my code useful to other people. I did that by adding a config file which will allow others to "massage" things a bit without messing with the code itself. The user interface is in Python with all the intense math in a C module. The program displays images real time, saves stills and video and can display up to 5 real-time updating temperature markers (which also show on saved images & video). It will use either frameID10 or an external file for pixel correction factors and utilizes frameID9 to determine temperature values.

I do my development on a 2.4GHz laptop running Debian Wheezy and the program runs well on that. The program also runs on my Raspberry Pi 2B (900MHz) with a couple caveats:
It will display the images at 8-9fps if image scaling is set to 1 or 2
It will only record video at full frame rate if scaling is set to 1
For some reason it requires "sudo" on my Pi

This is a disappointment to me because I have mobilized my Pi with a 5" touchscreen & it takes scaling of 3x to fill that screen & be most visible.

At any rate, I can upload it here or if there is enough interest to warrant a new thread like Seekofix & Thermovision have, I can start a new thread & upload the code there. If there is no interest, I'll just go back in my hole...

joe-c · « **Reply #103 on:** August 13, 2016, 09:19:50 pm »

Quote from: IwuzBornanerd on August 13, 2016, 01:18:32 am

The program also runs on my Raspberry Pi 2B (900MHz) with a couple caveats:
It will display the images at 8-9fps if image scaling is set to 1 or 2
It will only record video at full frame rate if scaling is set to 1
For some reason it requires "sudo" on my Pi

At any rate, I can upload it here or if there is enough interest to warrant a new thread like Seekofix & Thermovision have, I can start a new thread & upload the code there. If there is no interest, I'll just go back in my hole...

I am very interested to get the Seek working on my Raspberry. I tried the Seek with a Tablet (With Windows 8.1) and the Thermovision, it works...

but a Raspberry (and his analog Video output) will allow me to use my internal Car Monitor or some other tiny display.

i would enhance my car with a Seek Night vision, so please share your program.

IwuzBornanerd · « **Reply #104 on:** August 16, 2016, 06:50:45 am »

Okay, I guess I can't just go back in my hole, then. I started with cynfab's code I got off of this blog and git-hub, so my "enhanced" version is my contribution to the effort. I'll upload it here and if there turns out to be a lot of commentary we can put it on it's own thread.

How does that standard disclaimer go?...This software is provided "as-is, no warranty", in hope that others may find it useful... I am not a trained programmer, so I am sure there are many things not done properly in the minds of those who write code for a living, but it works for me. Hopefully it works for someone else. I had never touched python before but I figured it would be easier to take cynfab's code which had all the USB stuff and image display than to figure out how to use libusb (which I had never done) & display the images using gtk (which I have done very little of). There were many screaming moments, as with any new programming language, but I still think it was the easier route for me.

I think I have everything covered in the readme file, so here it goes...

[Edit 1-10-2019]
I see that this is still getting an occasional download. I suggest that you would like revision A better. I have posted it on a separate thread which also serves as a discussion forum for my code: https://www.eevblog.com/forum/thermal-imaging/running-seek-thermal-cameras-(-others)-on-a-raspberry-pi/msg1941499/#msg1941499

joe-c · « **Reply #105 on:** August 19, 2016, 12:32:43 pm »

Thanks for share.

Well, I have the best image quality while using my own calculated Gain and Offset Map, but only if the camera has passed the warm-up and the map was fresh generated.
If the same Camera was started later (after cool down) the map is unusable.
That is because the Pixels shift gain and offset if the internal camera processing was activated.
I tried to get the internal Sensor map while using the "GET_RDAC_ARRAY" command, which should have the same size as the Frame:
IMAGE_BUFFER_SIZE_IN_WORDS = 32448
RDAC_ARRAY_SIZE_IN_WORDS = 32448
Sadly... there was no success. I want to readout the Map after warm-up and reload after a cold start, but it won't work.

IwuzBornanerd · « **Reply #106 on:** August 19, 2016, 06:52:44 pm »

Quote from: joe-c on August 19, 2016, 12:32:43 pm

Thanks for share.

Well, I have the best image quality while using my own calculated Gain and Offset Map, but only if the camera has passed the warm-up and the map was fresh generated.
If the same Camera was started later (after cool down) the map is unusable.
That is because the Pixels shift gain and offset if the internal camera processing was activated.

Yes the "user generated" correction factors will yield the best image only when the camera is at the temperature it was at when the factors were generated. And, of course, it needs to be stable there when the correction factors are generated. I believe that is the case with the ones stored in the camera also, which makes me wonder if they were generated with the camera at 15*C as that would explain why frenky gets good images there.

Quote

I tried to get the internal Sensor map while using the "GET_RDAC_ARRAY" command, which should have the same size as the Frame:
IMAGE_BUFFER_SIZE_IN_WORDS = 32448
RDAC_ARRAY_SIZE_IN_WORDS = 32448
Sadly... there was no success. I want to readout the Map after warm-up and reload after a cold start, but it won't work.

I don't have sufficient documentation to know what "GET_RDAC_ARRAY" does, but it and "GET_VDAC_ARRAY" sound interesting. My code strips off the 2 end columns before generating the external correction factor file and when reading correction factors from a file on disk my code expects that the 2 end columns have been stripped off so if you are expecting RDAC_ARRAY_SIZE_IN_WORDS = 32448 and treat it as a 208x156 array it will be a huge mess. When using the frameID10 correction factors, my code strips off the 2 end columns before applying them.

Does this sound like it addresses what you are seeing?
What is the VDAC array? Is that the bias settings used for reading each pixel, by chance? IF so, it would be something that changes at each frameID1. That could be a big help...

joe-c · « **Reply #107 on:** August 19, 2016, 09:36:11 pm »

Quote from: IwuzBornanerd on August 19, 2016, 06:52:44 pm

Does this sound like it addresses what you are seeing?

No, for my images i don't use this line. i tried a little bit with it but get not really better results.
But additional, i work only with Raw Frames, the Camera delivers only Frame ID 3 and no shutter rises.
If the Temperature of the Core is stable, the Quality is quite use full.

Quote from: IwuzBornanerd on August 19, 2016, 06:52:44 pm

What is the VDAC array? Is that the bias settings used for reading each pixel, by chance? IF so, it would be something that changes at each frameID1. That could be a big help...

I think yes... and it clearly change at the startup and only after some Frame ID 1 Images.
i can remember , that the Seek still has changes if the Device was cool down and reinitialize only in raw mode.

I can confirm, that the Frame ID1 change some pixel, and after my reference Map and a uniform image, the Pixels appear darker as the surrounding Pixels if i Spot on a warmer surface. So Frame ID 1 not only change an offset, it change the Gain of the Pixel too.

And for those who have a FLIR E4 (or other with remote access), with the Ex-Tools it is possible to Change the Values of the Digital filters and disable them. its quite interesting how the "unfiltered" Image looks, its a low difference to the Seek image.
if i had more time i make some comparison images.

IwuzBornanerd · « **Reply #108 on:** August 20, 2016, 07:12:45 am »

I think I was (and may still be) confused. When you said "thanks for the share" I thought the following stuff was referring to running my code on your Rpi (or other machine) and it was confusing that you referred to offsets, which my code does not currently use, so I though maybe you had modified my code to use some of your own tactics (which is fine).

But now I think you were talking entirely about using your own code. Is that true? And then the main point was that you cannot save correction factors and use them later successfully? Since you are not using frame ID 1, I can see that being a problem. My camera has many pixels that are very near the threshold of switching the bias when the ambient temperature is near 80 degrees Fahrenheit. I picked 3 of them and ran a test file listing their values after every frame ID 1 and they toggled back & forth every frame ID 1 at that temperature and as the temperature warmed or cooled on either side of the magic point they stopped toggling.

Something you might try is when the camera is warmed up & stable save a frame ID 3 with the camera aimed at a uniform temperature surface and load that when you start the program. Once the camera is stable, compare the saved frame ID 3 with a fresh one of the same (or close) temperature surface. Calculate the differences between the pixel values of those 2 frames. The pixels where the difference is around 2000-3500 are the ones where the bias has changed. You might be able to use that information to adjust your map. Having said that, I tried something like that and couldn't see any improvement, but I was using it to correct gain where I already was using frame ID 1 and it might not have been enough pixels to really notice.

Oh, and I take it you have not been able to actually access the VDAC or RDAC arrays? Darn, I would have asked how. I tried editing some of my cynfab code to request that and got nothing but "broken pipe" errors, or maybe "invalid parameter"...I don't know what the thing requires.

joe-c · « **Reply #109 on:** September 15, 2016, 08:04:23 am »

Sorry for late answer...

I don’t had the time to play with the Raspi and the code you shared.
First I will have a good and stable core, than I will port it to the Raspi using your code base.

To the "switching" after a FrameID1, yes, this will be a problem, but only in "Normal" mode.
If I use the "Raw" mode, no shutter rises, no Frame ID1 is send and no Pixel would be shifted.

The idea to use a stored frame to calculate a actual offset is not bad, I tried before but it works only until the Sensor has reached the "Pixel Shift Temperature".
I use a Cold ID3 and a WarmID3 Frame to calculate a Gain and a Offset Map. If I connect the seek later and load the maps there is some offset... than NUC (Shutterles Frame offset) and the Image looks better. But some Seconds later (20-280), some Pixel starts shifting.

To the VADC and RDAC arrays... I tried the commands (somebody extracted from java) but get no response or a stuck device (needs USB reconnection).

Joe-c

IwuzBornanerd · « **Reply #110 on:** September 17, 2016, 12:39:37 am »

I found the old post from @blackboxdisease with the command info. https://www.eevblog.com/forum/thermal-imaging/yet-another-cheap-thermal-imager-incoming/1110/?wap2 and I see that it says VDAC_ARRAY_SIZE_IN_WORDS = 156. This makes me think it cannot be values for pixel bias because I don't see entire lines of pixels changing value between the 6000 range & the 8000 range. I only see isolated pixels change that much; although there are hundreds that have changed they are not grouped together.

Regarding the shutter, something I have observed is that once the camera is warmed up it takes a shutter frame every 60 image frames, but I have not captured data to see if if it ever reduces that number if the camera temperature changes such as it would during outdoor use. It might be more responsive in such situations if the decision to grab a shutter frame was based on the change in the value of pixel 1. It looks like if pixel 1 varies more than 2 or 3 a new shutter frame is needed to get clean images. I also saw TOGGLE_SHUTTER_SIZE_IN_BYTES = 4. Curious...Why 4 bytes?? Open/closed and a dwell time maybe?

Maybe nobody has had time to play with my code. I see there have been dozens of downloads but no comments or complaints. maybe I should be happy about that. I'm curious whether others have been able to get reasonable temperature readings with it & how the images compare with other code. With my camera the images appear to be comparable to those from Seek's app., which I admit is nothing fantastic...

joe-c · « **Reply #111 on:** September 17, 2016, 10:00:58 pm »

well, I not tried much with the VADC, more with the RDAC:
RDAC_ARRAY_SIZE_IN_WORDS = 32448
my hope was to read that automatically generated setup if the seek move on from warm-up.
than store that setup and load it next time, the rest of shift will be done with the normal nuc.

and yes, 4 bytes for a TOGGLE_SHUTTER_SIZE sounds curios, but a Chip_ID with 12 bytes containing 50% 0 values is also curios.

if the RADC Map way will not work I have another idea... maybe we could wait until the seek is done with the wamup and prohibit additional a using of the Normal mode, but for this we need a hardware change, because the shutter is off at next startup.
And then just change the init to a way without the normal mode, just re Raw mode. If the RADC setting was saved in the camera, it maybe hold this state. i guess the RDAC changes only around the FrameID1 time.

kiranjayaraj · « **Reply #112 on:** September 29, 2018, 04:36:09 pm »

Hi Sebastian,
I see that the post is old and I just wanted to say that I am doing something very similar to yours.
Using a Raspberry Pii and Seek to get into plant temp measurements. Are you still working on this by anychance?
Thanks in advance for your response.
Kiran

bsaarel · « **Reply #113 on:** March 09, 2020, 09:09:38 pm »

Hi everyone- I'm new to the seek thermal threads. I noticed when I tried calibrating my camera to a hot plate that the camera looks like it saturates- it gives me the same raw pixel values above ~420K. I'm getting the 'raw' pixel values from the 'SeekOFix' app in the same command that arrID3 is read in, which uses a device.ReadExactPipe(0x81, 0x7ec0 *2) to get the camera data formatted as a ushort. Could anyone tell me why it looks saturated? If this has already been posted about, could someone point me to the correct thread? I attached two plots- 'comparison_plot' is the most frequent pixel value as a function of temperature (read from hot plate). 'RawPixHist' shows the histogram of pixel values as I increase temperature on the hot plate.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee