Yet another cheap thermal imager incoming.. Seek Thermal

[datsthat]

In our first post we thanked the collaborators in this forum for their professional and helpful comments and suggestions. Your response since has been even more impressive. We are grateful.
 
Thermal Gradient:  We have been able to reproduce the thermal gradient effect that several people have reported.  We are now working on a software solution and will incorporate it into an app update within the next month.

One goal for the Seek camera has been ease of operation since we are positioning it as the first general consumer thermal camera. Thus, while some have suggested a user triggered 'Secondary’ calibration, that is an extra step that could require a significant amount of user education for nonprofessionals, and lead to frustration when the gradient returns.  In that spirit we are focused on a fully automatic compensation solution in the upcoming application update.
 
Thanks again,
 
Seek Technical Team

Thank you for your quick reply!!!!!
This question is for Seek and/or anybody else...... how difficult would it be to add a "thermal outline" as an option that allows you to set the temp that you want outlined?  Thanks,

[miguelvp]

Pixel 207 looks suspiciously related to the horizontal banding, maybe a way to compensate for it?

[frenky]

We could try to subtract 207th value from each line pixel and see  if the image gets better/worse...

[bktemp]

We could try to subtract 207th value from each line pixel and see  if the image gets better/worse...

It gets much better!
I have added 207th value/10 to each pixel of the line after subtracting the reference frame.
I think it is some sort of reference pixel for each line.

[efahrenholz]

Aha, so I might be somewhat right that those pixels are reading the heat of each line being read out. They must be the average of each line, then subtracted from each pixel to normalize the data. Each line must be read out and will get hot as it does so. They were clever enough to add thermistors to reduce the line read thermal induced noise.

@bktemp,

Try subtracting the 207th value from each pixel in the line. I don't think you would need to divide, as it should already be the average of the line.

[eneuro]

Ploted in fv thi 207th column and... in those 4 images  regardless it is calibration frame or not they really looks the same, but as we can see some kind of pattern distributed around three values apears 


Anyway it is great those strange horizontal noisy lines  has gone away @bktemp

[miguelvp]

Also using the values you could even compensate for the now induced banding in the hot areas, maybe a linear correction based on the numbers. Can't play with it until after work and that's 8 hours away

[miguelvp]

I know this might be a shot in then dark, but perhaps the patent pixels are working thermistors...which means maybe they are reading the temperature of the sensor. Maybe each line is an average of the readings from those pixels? Declining values would point me to think that the resistance is falling (heating) and thus the values are mapped.

patent pixels are always 0 they don't vary. (other than the first one that tells you if it's a cal frame or not)

[bktemp]

In the darker lines the 207th value is higher (~5300 instead of ~4900). Therefore they have to be added to remove the dark lines. This is a bit strange, because this means the 207th value uses a different sensor, or it is an already processed value. Maybe it is even the absolute temperature: 5200/256=20.3°C
It is not possible to remove the horizontal noise completely from both hot and cold areas with the same scaling factor. To remove the dark lines completely there are probably more calculations to be done:
I do not know, but I think the data is the non linearized data from the adc. To get the absolute temperature, you have to know some constants (I think it works the same way for all bolometers):
http://u88.n24.queensu.ca/exiftool/forum/index.php?topic=4898.msg23972#msg23972
Therefore subtracting or adding raw values only works for a small temperature range before it gets nonlinear.

Does anybody know if other thermal cameras simply scale/offset the sensor data the same way we do, or do they linearize the data to temperature scale before applying the palette?

[efahrenholz]

I know this might be a shot in then dark, but perhaps the patent pixels are working thermistors...which means maybe they are reading the temperature of the sensor. Maybe each line is an average of the readings from those pixels? Declining values would point me to think that the resistance is falling (heating) and thus the values are mapped.

patent pixels are always 0 they don't vary. (other than the first one that tells you if it's a cal frame or not)

Or perhaps in this case, you are reading them as zero in the image because their value isn't passed on as a value that can be individually read. Perhaps their value is found on the 207th pixel in the line, but as an average, seeing as there are 10 in a line, and the 207th pixel divided by 10 (mind you 10 patent pixels in a line) equals the approximate temperature of that line. But in this case we add the value to all the pixels in the line.

These pixels are not patent pixels. They are zone thermistors.

[miguelvp]

@bktemp:

based on the difference with other non banding lines you could compute slope depending on the difference and the actual value for a giving pixel value.

y = m * x + b

where:
y
   is the end value we want to display.
x
   is the current value of a given sensor pixel reading.
b
   is the lower value a pixel can read.
m
   is the slope based on the difference with other lines at pixel 207 (but I don't know what value m should have yet related to the other ones. A value of 1 will be as read. > 1 will make it brighter the higher x is linearly. < 1 will make it dimmer the higher x is linearly as well.

@efahrenholz
good point may be it is that, I think there are 13 total per row.

[efahrenholz]

@miguelvp,

Double check your count, I count 10 per line.

@bktemp, your math to divide should be correct.

Also, yes, you should be scaling the math to add the 207th data to each pixel. It is probably raw summed ADC values. The summed data divided by 10 puts it in range to be a 10 bit ADC.

[miguelvp]

@miguelvp,

Double check your count, I count 10 per line.

206 divided by 15 = 13.73
first row thermistor/patent pixel is at 10, then every 15 pixel, 25, 40, 55 ... all the way to 10+13*15 (205)

Edit so 14 total, my bad

[ricksastro]

The non-linearity is driving me crazy.  I was hoping that subtracting the flat paper image from the router image would remove the lines and even out some of the pixel noise.   And it did a great job for the darker areas, but the hotter areas actually really don't show the lines or the noise to begin with and subtracting out the flatpaper image increases the noise of the bright areas just as dramatically as it helped in the darker areas.

I'm really having to rethink my experience with linear CMOS or CCD sensors. 

I now appreciate the job seek has done with image quality even what's there right now in the Android app.   If somehow they can deal with the gradient, life would be even better.

I wonder if taking an equivalent of a bias frame (as short of an integration as possible with the shutter closed) and subtracting it off the real calibration (full integration time shutter closed) would allow them to "see" the gradient and then deal with it (assuming it's thermal sourced).    I guess I don't know the nature of the extreme noise that veils the images.   If it's read noise dominated, then that strategy would work.   If it's thermal/time based dominated then not so much.   They could do it by taking 2 calibration frames while the shutter is closed, one super short integration, one normal integration.   The user would never notice it.

This is my first foray into thermal and I've really enjoyed expanding my horizons here...I agree with Seek, this is an excellent and well behaved forum, concentrating on solving problems rather than threatening lawsuits for small problems.

Rick

In the darker lines the 207th value is higher (~5300 instead of ~4900). Therefore they have to be added to remove the dark lines. This is a bit strange, because this means the 207th value uses a different sensor, or it is an already processed value. Maybe it is even the absolute temperature: 5200/256=20.3°C
It is not possible to remove the horizontal noise completely from both hot and cold areas with the same scaling factor. To remove the dark lines completely there are probably more calculations to be done:
I do not know, but I think the data is the non linearized data from the adc. To get the absolute temperature, you have to know some constants (I think it works the same way for all bolometers):
http://u88.n24.queensu.ca/exiftool/forum/index.php?topic=4898.msg23972#msg23972
Therefore subtracting or adding raw values only works for a small temperature range before it gets nonlinear.

Does anybody know if other thermal cameras simply scale/offset the sensor data the same way we do, or do they linearize the data to temperature scale before applying the palette?

[efahrenholz]

We could try to subtract 207th value from each line pixel and see  if the image gets better/worse...

It gets much better!
I have added 207th value/10 to each pixel of the line after subtracting the reference frame.
I think it is some sort of reference pixel for each line.

@Miguelvp, sorry yes I am wrong, but I don't see 13 per line. I am referencing by his photo. I see 10 in first annd last line, and trying to randomly count in between I get 11? Is this a cropped image?

Never mind I see the 14 per line. I was counting per column.

Technically you should be dividing by the number of thermistors counted on each line, which seems to vary.

[efahrenholz]

@rickastro

The problem is measuring temperature isn't linear. As it gets warmer, the resistance decreases but not linear to the temperature. One degree change at low temperature could make a change of 100 on the ADC, while at high temperature it could be only 30 or less. That's why its hard to get accurate readings at high temperature, as the resolution drops.

[Fraser]

I have to agree with Rick, this thread is very interesting and is positive towards the product that SEEK Thermal have produced. A very positive attitude which is great to see these days.  I am very impressed with the clever work that is being done on the date that comes out of the SEEK. Though I understand little of it I appreciate the effort that is being made by all who are working to better understand the product and increases its usefullness for us all.

Thanks to SEEK thermal for making the camera and to those in this thread who have enlightened us on the hardware and data used in the product.

In a perfect world I would hope that SEEK can release information on the data stream and even the hardware architecture but they do need to protect their investment.

Aurora

[miguelvp]

Technically you should be dividing by the number of thermistors counted on each line, which seems to vary.

13 sensors rows:
row 4 and every 15 row from there.
row 8 and every 15 row from there.
row 12 and every 15 row from there.

The rest are all 14 count

But on the 13 count they could be using column 208 instead, might be there for a reason after all (other than making the row even count)

It doesn't matter much, seems like 207 helps clean up the image as suspected

[bktemp]

As it gets warmer, the resistance decreases but not linear to the temperature. One degree change at low temperature could make a change of 100 on the ADC, while at high temperature it could be only 30 or less. That's why its hard to get accurate readings at high temperature, as the resolution drops.

It is probably the reverse: I did some rough estimates with some old thermal images from a different camera using the min/max values on the thermal images and the min/max values of the raw data. The temperature to raw data conversion is more like exponential, higher temperatures have therefore a higher resolution. This matches the formula using ln() to calculate the temperature from the other forum I have posted.

I made a small animated gif out of several frames. The noise seems to be mostly static. It should be quite easy to remove it with a bit of additional processing. Furthermore there are a few pixels (always 2 adjacent) that seem to change constantly without any reference to the normal image. Maybe they contain other information?

[eneuro]

I was hoping that subtracting the flat paper image from the router image would remove the lines and even out some of the pixel noise.

Probably cats and human face are beter thermal objects than those router images 

Without knowledge of protocols used it is of course difficult reverse something, but it has to be done since I do not expect that Seek Thermal will add support for contures from visual cameras to those thermal images.
While it doesn't cost too much hours of coding it is worth to crack it and have own source code and user interface front end of thermal camera, than only plug Seek Thermal or other device with decent quality sensor

[ricksastro]

As it gets warmer, the resistance decreases but not linear to the temperature. One degree change at low temperature could make a change of 100 on the ADC, while at high temperature it could be only 30 or less. That's why its hard to get accurate readings at high temperature, as the resolution drops.

It is probably the reverse: I did some rough estimates with some old thermal images from a different camera using the min/max values on the thermal images and the min/max values of the raw data. The temperature to raw data conversion is more like exponential, higher temperatures have therefore a higher resolution. This matches the formula using ln() to calculate the temperature from the other forum I have posted.

I made a small animated gif out of several frames. The noise seems to be mostly static. It should be quite easy to remove it with a bit of additional processing. Furthermore there are a few pixels (always 2 adjacent) that seem to change constantly without any reference to the normal image. Maybe they contain other information?

Not sure if those are bright pixels or subtracted darker pixels from the calibration frame.   Regardless, you should be able to do a bad pixel map of the patent pixels and those and median them out.

Also if you are taking images of static objects, you could take many frames and move the camera slightly between frames (dithering) and then stack the images using a sigma reject type of combination (after alignment of the subject) do all but eliminate the noise.   This can also give you a "superresolution" if you align and combine higher res resampled iamges.       The lower noise will allow more sharpening as well.

Not practical for many objects, but an interesting exercise nonetheless.

[miguelvp]

We could try to subtract 207th value from each line pixel and see  if the image gets better/worse...

It gets much better!
I have added 207th value/10 to each pixel of the line after subtracting the reference frame.
I think it is some sort of reference pixel for each line.

Adding them after being divided by 10 would give you the same relative image as just adding it without dividing by 10 (other than when you get over 2^16 but that can be fixed by reducing our introduced 0x8000=32768 d offset, say to 24K instead of 32K leaving 8K (8192d) on the table).

The division just takes away some precision.

[efahrenholz]

As it gets warmer, the resistance decreases but not linear to the temperature. One degree change at low temperature could make a change of 100 on the ADC, while at high temperature it could be only 30 or less. That's why its hard to get accurate readings at high temperature, as the resolution drops.

It is probably the reverse: I did some rough estimates with some old thermal images from a different camera using the min/max values on the thermal images and the min/max values of the raw data. The temperature to raw data conversion is more like exponential, higher temperatures have therefore a higher resolution. This matches the formula using ln() to calculate the temperature from the other forum I have posted.

I made a small animated gif out of several frames. The noise seems to be mostly static. It should be quite easy to remove it with a bit of additional processing. Furthermore there are a few pixels (always 2 adjacent) that seem to change constantly without any reference to the normal image. Maybe they contain other information?

Not sure if those are bright pixels or subtracted darker pixels from the calibration frame.   Regardless, you should be able to do a bad pixel map of the patent pixels and those and median them out.

Also if you are taking images of static objects, you could take many frames and move the camera slightly between frames (dithering) and then stack the images using a sigma reject type of combination (after alignment of the subject) do all but eliminate the noise.   This can also give you a "superresolution" if you align and combine higher res resampled iamges.       The lower noise will allow more sharpening as well.

Not practical for many objects, but an interesting exercise nonetheless.

Another way to kill the noise and all the dirty pixels would be to first kill the line read noise with the data in 207, then build a loop that scans each pixels and compares it to its 4 neighbors. So find the average of x+1,x-1,y+1,y-1, divide that in to a variable. Subtract value of current pixel from the variable hosting the average, flip the sign so its positive, and replace the pixels value with the average if it is over or under the average by 10 (or however agressive you choose it to be.)

This essentially is a blurring algorithm but more selective. So you should be able to effectively dissolve dirty pixels and the thermistor pixels. Set difference low enough and it might even knock out all the noise.

[bktemp]

Adding them after being divided by 10 would give you the same relative image as just adding it without dividing by 10 (other than when you get over 2^16 but that can be fixed by reducing our introduced 0x8000=32768 d offset, say to 24K instead of 32K leaving 8K (8192d) on the table).

The division just takes away some precision.

If I do not divide by 10, the black line get white and white lines gets black. I need to scale the values down to reduce theie effect just so to compensation the lines in the original image.

I am now playing with noise reduction of the static noise: I have avaraged a few frames, and try to subtract this from all frames. This does not work well. The noise seems to be no offset than rather gain errors of each pixel. Next I am going to use the generated noise map to scale each pixel independently.

[frenky]

... build a loop that scans each pixels and compares it to its 4 neighbors. So find the average of x+1,x-1,y+1,y-1, divide that in to a variable. Subtract value of current pixel from the variable hosting the average, flip the sign so its positive, and replace the pixels value with the average if it is over or under the average by 10 (or however agressive you choose it to be.)

Already done that:
https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/msg538423/?topicseen#msg538423

I went a step futher by checking which pair (horizontal or vertical) has smallest difference in color.
(This is to keep details on vertical and horizontal edges)
The average value of this pair is the new pixel value.