Seek Compact Pro Radiometric JPEGs

[NiallxD]

Hello!

Been a lurker here for a while & love the work you guys get up to. I’m not savvy enough to help others but I am looking for some advice. I can’t find anything concrete on this so thought I’d ask.

Can you take radiometric JPEGS off of the Seek Compact Pro IOS version?

If anyone knows of a topic on this, please feel free to point me that way, and I appreciate any comments👍

Niall

[IwuzBornanerd]

The first time this topic was brought up is this thread:

https://www.eevblog.com/forum/thermal-imaging/seek-thermal-app-save-all-thermal-data/msg2537811/?PHPSESSID=edfomj7bnuhedval3lajdujut3#msg2537811

The latest app has a "save all data" option in the preferences.  With this selected it will save TIFF files that contain the temperature at each pixel (as 32 bit floating point numbers) in a separate block as well as the colorized image.  The TIFFs are saved in a different directory from where the usual JPEGs are stored.  I think it is "Pictures" vs. the usual "Images" directory.

I have not seen anything about software from Seek that reads or uses that temperature data but it is fairly simple to extract this data from the images using libtiff under Linux (I did it so it can't be too tough).  I also modified my Seek camera program to be able to read in that data & turn it into images, as you can see on that thread.

These programs are crude at this point but they proved the concept.

And I have not heard anyone begging me to let them have that software.   

I also have not seen anyone specify exactly what they expect to do with that data.  Do they merely want to apply different palettes or do they want to get histograms, apply smoothing, or change emissivity and other complicated stuff?

I wonder if it is proper to call it "radiometric" data if it is temperatures in degrees rather than sensor output values.

[NiallxD]

Hi!

Thanks for coming back to me! It seems the unit is capable of saving the data on Android versions but not IOS then? I’m interested to know why we can’t do it on IOS.

Maybe reaching out to Seek will get me some
Answers on that?

Read your other thread and looks like you can do some interesting things with the TIFF files.

Would be great to have this data to analyse like you can with the FLIR images.

Cheers again!
Niall

[Ben321]

The latest app has a "save all data" option in the preferences.  With this selected it will save TIFF files that contain the temperature at each pixel (as 32 bit floating point numbers) in a separate block as well as the colorized image.  The TIFFs are saved in a different directory from where the usual JPEGs are stored.  I think it is "Pictures" vs. the usual "Images" directory.

My copy of the app saves 3 blocks of data (not 2). One is 8bit color image, one is 16bits raw data, one is clearly multiples of 4-bytes per sample but doesn't seem to hold any data (all samples hold the same value). I too first thought that it was 32bit floating point temperatures, but it doesn't vary from sample-to-sample. It may be a feature they plan to add in the future, but it doesn't seem to be currently implemented (just holds a constant value as a placeholder for all the samples).

[IwuzBornanerd]

Now that I have been sort of forced to take a closer look at the third frame in the Seek tiff files I can say that the third frame does not look like any sort of "raw" data to me.  The values (mostly less than 3000 in the samples I have) are far too small to be sensor frame data which typically runs between 6000 & 10000.  They are also too large to be the difference between the scene frame & shutter frame.  And lastly, when palette colors are assigned to the values the resulting image is much too clean to be from "raw" data--as clean as the image from the floating point temperature numbers.

I thought maybe the values were just another set of values linearly proportional to temperature, but when I first pulled frame 3 into my program & assigned colors linearly I was able to see slight differences in the color distribution between that and the image from the floating point temperature values.

This suggests to me that there is a curve in the value vs. temperature line.  I posted an example showing the palette auto-ranged on the floating point temperature numbers on the left and the same palette auto-ranged on the values from tiff frame 3 on the right.

[IwuzBornanerd]

 Upon seeing the apparent curvature in the contents of the 3rd tiff frame vs the second frame I thought I would plot a graph of the 3rd frame data vs. the 2nd frame data and indeed there was a curvature.  So I decided to get a better idea of that curvature by setting up a scene that contained temperatures over the full range the camera is specified to sense, that is -40C to 330C, or a s close as I could get to that.  So I booted into Androidx86 & ran the Seek app in order to get some tiffs with a soldering iron, a sandwich box of food from the freezer & a custard dish of freshly boiled water.

Here is the image from the Slow Frame Pro, made from the list of temperatures in the 2nd tiff frame.  I apologize for the markers being upside down but my laptop pc has no accelerometer so Android doesn't know which way is up & rotates the image which screws up the tiff file.  You can see the reflection of the custard dish & sandwich box in the table surface.

SFProHotIron

Next is the plot of the data from the 3rd tiff frame vs. the temperatures from frame 2.  Could tiff frame 3 be radiance values?  The bump in the middle is strange.

SFPro frame 3 vs 2

Next I tried the same scene with the wide angle non-pro Seek Compact I bought in January 2017.  Here is the image.  If you can read the temperatures on the iron in both shots you see that the Pro gave a lower value.

wide angle non-pro hot iron

Now here is the plot of tiff frame 3 vs. frame 2 from the non-pro camera.

wide angle frame 3 vs 2

Big shock, huh?!  What is so shocking about this is that the Seek app is able to show temperatures above 300 C even though this data levels off after about 175 C!  According to their own numbers!  This looks very much like a plot posted by @bsaarel on this thread:

https://www.eevblog.com/forum/thermal-imaging/seekthermal-how-to-correct-the-image-received-from-the-sensor/msg2956460/?PHPSESSID=7iugb5848nj0hus96gm8b9a2o1#msg2956460

I did not respond to his post because I had no idea what was going on there but having seen this I pursued further.

I went back to my own software & had it capture the true raw pixel data (frameID 3) from that non-pro camera for a similar scene (Ice cream was handy at the time) & here is the data plotted vs the temperatures calculated by my software (which can be wrong).  This is what a plot of raw pixel values looks like, not like the data in the tiff file. :~)

wide angle raw pixel values

So the raw pixel values do indeed bump up against the 14 bit maximum value (16383) in spite of Seek's constant fiddling with the pixel bias!  As @bsaarel observed but apparently not as bad as his.

I measured the temperature of the iron with a thermocouple & it was over 400 degrees C.  So it could be that the flat spot in the above plot is all above 330 degrees C, but that would mean that Seek's temperature for the soldering iron was unnecessarily low especially from the SF Pro which claimed it was 287C.

Because the soldering iron was over 400C in the prior test, I decided to re-run the test with the iron at 320C as measured by the thermocouple (my software said 184C).  Interestingly the plot is nearly the same so the pixels certainly DO saturate before the scene reaches 330C, at least in that camera:

wide angle with 320C iron


The raw pixel values off the SF Pro are similar (with the >400C iron):

SF Pro raw pixel values

This brings up an interesting dilemma.  The "gain" compensation factors in Seek's own NUC table on my first camera varied from around 40% to 150%, so many pixels will not be able to reach the value required to achieve a "normalized" value of 16383.  So what value do they design for at 330C?
 

[Fraser]

This is really interesting 

I have some professional Blackbodies that I was intending to use to test both my Reveal Pro FF and another Seek Pro based camera. I will carefully study this thread before doing so. 

Fraser

[Ben321]

Now that I have been sort of forced to take a closer look at the third frame in the Seek tiff files I can say that the third frame does not look like any sort of "raw" data to me.  The values (mostly less than 3000 in the samples I have) are far too small to be sensor frame data which typically runs between 6000 & 10000.  They are also too large to be the difference between the scene frame & shutter frame.  And lastly, when palette colors are assigned to the values the resulting image is much too clean to be from "raw" data--as clean as the image from the floating point temperature numbers.

I thought maybe the values were just another set of values linearly proportional to temperature, but when I first pulled frame 3 into my program & assigned colors linearly I was able to see slight differences in the color distribution between that and the image from the floating point temperature values.

This suggests to me that there is a curve in the value vs. temperature line.  I posted an example showing the palette auto-ranged on the floating point temperature numbers on the left and the same palette auto-ranged on the values from tiff frame 3 on the right.

(Attachment Link)

I have a hypothesis. The RAW data (TIFF frame-2) is linear sensor data (a doubling of the data value for a given pixel means a doubling of the intensity of the LWIR radiation hitting the pixel). The mystery data (TIFF frame-3) is absolute (Kelvin) temperature data (a doubling of the data value for a given pixel means a doubling of the temperature). I remember learning in a university class that the intensity of blackbody radiation emitted by an object is proportional to the 4th power of the temperature of an object. Blackbody_Intensity = (T^4) * Boltzmann_Constant * Emissivity. T is the Kelvin temperature, Boltzman_Constant is a fixed physical constant like the speed of light in a vacuum, and Emissivity is a constant that describes the emitting surface of the object you are looking at.

So solving for temperature, T = (Blackbody_Intensity/(Boltzmann_Constant*Emissivity))^0.25
Keep in mind that Blackbody_Intensity refers to ALL radiation emitted by an object at a given temperature, but your LWIR camera only sees a limited portion of this this, basically acting like a bandpass filter. Furthermore, the linear raw data values aren't scientific values themselves (they aren't measured in normal intensity units of Watts_per_Square_Meter), but rather are ADC (analog to digital converter) units, ranging from 0 to 65535.

So after correcting for the bandpass filter effect, and the fact that your values are normalized values within the range of 0 to 65535, you will get some new equation that will let you calculate temperature (or at least some values that are linear to temperature, rather than linear to intensity) from the raw data. My hypothesis, is that if you can discover this equation, you will be able to take the values from TIFF frame-2 and get the values that are in TIFF frame-3, such that after applying the function to TIFF frame-2 you will get a set of values that when subtracted from TIFF frame-3 will result in the value 0 (zero) for all the pixels.

[Fraser]

Regarding the possible saturation of the Seek Pro Core at higher temperatures. I can advise that having tested two Seek Reveal Pro cameras and a Seek J3-630-320 core, none of them showed evidence of saturation. Why some cores appear to saturate I do not know. The Seek specification states a guaranteed maximum measurement temperature but the Core is known to measure higher than that figure, but without any guaranteed accuracy. My test exceeded that maximum temperature specification of +330C by some margin.

In the following data please ignore the measurement error as this is a test on a J3-630-320 core that has not been 2 point calibrated. It is purely a test of the cores temperature measuring capability. The measurement error can be reduced significantly by applying a calibration of at least 2 points to the built in default response curve. The data shown is from a single point calibration.

My seek Reveal Pro provides accuracy with a tolerance of only fractions of a Degree C after a 3 minute warm up and the error at switch on with a 50C target was only +1C.

I attach a PDF and screen grab of the test data.

Fraser

[IwuzBornanerd]

Regarding the possible saturation of the Seek Pro Core at higher temperatures. I can advise that having tested two Seek Reveal Pro cameras and a Seek J3-630-320 core, none of them showed evidence of saturation.

Nice, but did you check ALL pixels? 

[Fraser]

No but all were visible as I was using a large emission plate professional Blackbody

Scene uniformity remained excellent throughout the test. A 6x6 pixel group at the centre of the scene were used in the measurement.

Fraser

[JimM]

Regarding the temperature measurements, it's interesting that the error is almost always in the same direction (all measurements are high). Also, as the temperature increases, the error increases. Maybe that's why the measurement error specs always say +/-2 deg C or +/-2%. So according to this data, for nominal air temperatures of say 5C to 50C, the error is less than 2 deg C. One thing I noticed, is the measurement error for the Seek Reveal PRO is really large at low temperatures (i.e. less the 0 deg C). The error seems to be more than 10 deg C at those temperatures.

[NiallxD]

I've got to say awesome work from you all, especially IwuzBornanerd!

A lot of that has gone over my head but I think the short answer is, no!

Now, 2nd part of my questions, which I kinda think IwuzBornanerd answered with the bit about a curve but, do the colours tend to map equally to a temperature? I.e 0c = 0, 0, 0(Black) & 100c = 255, 255, 255(White), so 127, 127, 127 = 50c?

Just a thought, if so some analysis software could take the max & min temps, where max is fully white and min is full black, and calculate any temp for any colour?

Tah

[IwuzBornanerd]

The colors map however the programmer wants them to.    So I wouldn't bet on it being linear unless it's my own code.  I map the colors linearly with temperature because it's easy & I don't have any reasons to like it otherwise. 

What I was showing above with the curved plot was that the 2 lists in the Seek TIFF files do not map linearly with respect to each other.  So Seek has probably done some "massaging" to get the temperature values in the first list while the second list is perhaps the linear one.  And you still won't know if they map those "nonlinear" temperatures linearly to colors. 

[NiallxD]

Right, I see!

I basically it's just magic for someone like me.

Really appreciate your insights here to how these things are working!

Cheers!