ThermalExpert reverse engineering jar & dll

[mahony]

I basically just took the WinUSB class and the ThermalExpert class from this project and used it in a quick and dirty winforms app without any threading and so on that was put together in like 5 minutes.  Just click button, connect, read the first 50 frames from the TE and dump them to disk as raw binary data. Maybe the issue just sorts out when doing a proper setup with a separate thread to read from USB and pass the data on to where it is going to be processed.

I will double-check and get back to you. Your last ThermoVision worked like a charm so I am quite confident. 

 By the way: is it o.k. to PN or Email you if I am having further questions on this topic - could talk in german then 

[joe-c]

Sadly the formula doesn't woks for me yet.
With raw values 6994-6996 (collected 766 Values each frame) I get 17.08 and the expected Temperature was around 25° (with fresh connected Camera).
But I see your values are around 7275. I should make a measurement RawValue vs. Measured Case Temp later.

By the way: is it o.k. to PN or Email you if I am having further questions on this topic - could talk in german then 

Sure, everyone can contact me over email or PN. I guess the better way is email, because the PN don’t allow attachments.
Ansonsten auch gern in Deutsch, da versaue ich es nicht so oft mit der Grammatik 

Joe-c

[mahony]

Ansonsten auch gern in Deutsch, da versaue ich es nicht so oft mit der Grammatik 

Ja, da bin ich dabei ... 
I think for the forum it better to keep it english - they will forgive us our mistakes I think.

Hmm, strange for my values it produces absolutely reasonable results (see attached image) it was starting around 24°C which should be roughly room temperature and is climbing now - currently reaching ~29°C. Maybe they got different DLL versions?

I just check your code vs. mine and I am still not sure why i get the timeout in WinUSBDevice.ReadExactPipe ... with no 'sleeping' it happens after the first frame, with sleep of 200ms I still get this error after some 50-100 frames.
Using your code its totally fine... I will check this maybe tomorrow.

EDIT: I found/fixed my error WinUSBDevice.ReadExactPipe raised the exception when nothing could be read from the pipe, removed this exception and just return null, now everything works fine for the moment. Maybe later i set a different value for pipe read timeout.
 

[joe-c]

EDIT: I found/fixed my error WinUSBDevice.ReadExactPipe raised the exception when nothing could be read from the pipe, removed this exception and just return null, now everything works fine for the moment. Maybe later i set a different value for pipe read timeout.

well done. 

I tried a little bit with the warm-up of the Seek and the TE.
Next time I plan to use the collected "warm-up characterization".
I guess it should be possible to use the raw device temperature with a internal Look up table to get a offset for the raw value.
The Seek Thermal has much more drift while warm-up, if that LUT way works, the Seek can deliver usable temperatures while warm-up.

Btw... am I the only with the mystic glitch while warm-up of the TE?
 

[mahony]

Very nice comparision. Regarding the warm-up glitch: maybe this is due to the corrections that are applied. For display calculations the TE selects one of 4 offset maps (each corresponding to a factory set FPA temperature - read in ReadFlashMultiOffset). It selects the map that is closest to the current FPA temperature reading - so a switch between different offset maps may produce different average pixel values.

If you do a shutter calibration those factory offset table are ignored and the offsets derived from the shutter cal are used instead...

The most intersting thing to notice is that for calculation of temperatures non of those offsets is considered at all (see the lengthy post...) - this seems to be for display only.

I also had some time over the weekend to put some (very raw but working) code together. It will read all the neccessary data (gains, offsets, factory FPA temperatures and temp gain and offset) when the TE is first connected and store it to disk. If the software is shut down and restarted without disconnecting the TE the flash data isn't read from the cam but from disk instead... The pixels values are converted to the double values (as described earlier) and on click a temperature calculation is done over an 3x3 neighboorhood.
Additionally a cold and/or hot frame may be captured for 1 or 2 point correction of the available double valued images.

I am actually not totally sure anymore if the FPA temperature as calculated is actually are 'real' temperature in °C or some arbitrary scaled value, but I want to check this sometime this week with a cam at room temperature and doing a full 'warm-up run' as joe-c. Anyway it seems to work very good in the conversion of raw 16bit ints to doubles and further to temperatures as well.

Feel free to use modify or whatever the code. I compiled it with VS Community 2013 against .NET Framework 4.5 but it should be fine on older versions too (not the project files for sure). The code needs to be compiled with the 'allow unsafe' flag because the drawing routine (FastPainter class) uses some pointer stuff. There is no executable included atm. but I can attach it too if someone has use for it.

[tomas123]

@joe-c

nice charts 
I thought the seek did not have a shutter.

A year ago a posted here a warm-up chart from the Flir One:
https://www.eevblog.com/forum/thermal-imaging/flir-one-thermal-imaging-camera-teardown-and-hacks/msg848878/#msg848878

[mahony]

I did a 'warm-up run' yesterday using the posted code (with minor modifications for logging).
I will definetaly check my FPA temperature calculation again, because it was already starting ~43°C while it should have been around 25ish. I have already seen one mistake: in the DLL the used only values from row 3 an above in both 'temperature lines' - I just took one full line 

But anyway I post the charts and maybe update them some time later. What I captured was a room wall from ~1m distance with significant defocus because I also wanted to kind of characterize the noise over time. I captured/analyzed the frames converted to double values (so no raw DLs!). So in every frame I got I did some statistics: min, max, mean and standard deviation plus I did a calculation of temperature for a 3x3 pixel patch in the image center.

The first chart shows min, max and mean over roughly 55 minutes (scale is seconds) while the second shows the std deviation over the full frame.
After ~45 minutes i captured a cold frame (using the wall) and from there on it is using a 1 point correction. 4 to 5 minutes later i also did a hot frame (using my hand) and from there on it is doing the 2 point correction. You can see the significant drop in min/max and std-deviation after the cold frame.

The last chart shows the FPA temperture in red on the right scale (possibly wrong calculated) and the wall temperature from the center 3x3 pixels in blue vs. the left scaling.

After roughly 2-3 minutes all the readings become quite stable, altough the wall temperature still goes down a bit until the end. That might actually be true because one window in the room was partially open and it was in the evening so the wall may have cooled down a bit?

[joe-c]

I thought the seek did not have a shutter.

The TE has no shutter, but the Seek has. but it's a bad plastic shutter directly over the sensor. and the shutter rises pretty often (3-8 Seconds, depended from camera run time and warm-up).

After roughly 2-3 minutes all the readings become quite stable, altough the wall temperature still goes down a bit until the end. That might actually be true because one window in the room was partially open and it was in the evening so the wall may have cooled down a bit?

sounds true. I have the same problem with my wall.
I have to work on a stable temperature field... later.

I had a idea to compensate the warmup... just use a offset table.
I point the cold camera to the wall and start recording. I grab the raw device temperature and the frame avr (mean of all pixels).
this was stored in a WDC file (warmup drift correction).
then I use the raw value after warmup as reference and calculate the difference to all points before.
after connecting the cold seek again, this file was used to calculate a offset for each raw value in relation to the device raw value.
the results look interesting. but it works only if the camera is in a "calibrated temperature range".
and I use the normal mode, as you can see on the shutter drifts.

additional here is a graph from the TE. I made 2 times a 2 point map calibration, this is why the raw avr value has some break outs.

maybe I should faster think about a temperature stable calibration field to record the raw drift while the camera warm up to get a more accurate curve.

btw... thanks for your code sample mahony, I will look on it next time.

[mahony]

Nice plots again!  Interesting to see data from the Seek too. (always wanted to buy one - until I saw images from the TE... )

I didn't manage to do some more warm-up testing but couldn't stop thinking about the fact that the i3 DLL seems to be ignoring all the offsets from the flash and the shutter calibration when doing temperature calculations. So I did a quick test and took to image both in raw and temperature calculated mode (using i3 DLL mode) directly before and after a shutter calibration. I had the lens cap on to have a more or less uniform image. The result proved my interpretation of the code right (see attachments) - the raw double value image improved significantly after shutter calibration, while the temperatures calculated from those images did not change at all!

By the way: I am a big fan of the WinUSB mode now, partly because cam start-up is way faster now. When first connecting the cam I do the flash read which is faster than the DLL in itself (not sure what they are doing there?) and I also store all relevant data to disk. So on next startup (with out physically disconnecting the TE) the software just reads the flash data from disk, which gives immediate response. The other big pro (at least for me) is the fact that calculating a full temperature image is not blurring the image now. Plus my additional offset correction is also included in the temperature image = reduced noise and more homogeneous image without the blur when using the DLL.