Products > Thermal Imaging

Problems with RAW 14bit image in FLIR One

(1/3) > >>

By pushing it to its upper limit by pointing it at the heating element on an electric stove and taking a picture using raw 14bit mode in the SDK sample app (which I'd modified to be able to save the full 2-byte-per-pixel image data), I discovered 2 problems with the raw image, that indicate it is in fact NOT truly raw:

1) The hottest part that should saturate the sensor, and be constantly at the maximum value, instead wraps around back to 0 making the hottest part of the image look like it's actually colder than the coldest part of the image.

2) The largest number I found the image should have been 16383, the maximum value that can be stored in 14 bits. But it wasn't. The maximum value I found in the image was 65535, which is the largest value that can be stored in 16 bits. Rather than simply having the 14bit data be alligned to 16 bits by having 2 unused bits, it seems that they chose to scale the 14 bit data to 16 bits (calculated by outputvalue=inputvalue*65535/16383).

Why not call this high-bit-depth data, instead of raw data? It's not raw data. Raw means "unaltered", not "mostly unaltered". Even worse, they are very specific in how many bits are used in the name of the constant that defines this image type. The official name for the constant in the FLIR One SDK that defines this image type is "ThermalLinearFlux14BitImage". That is a lie. It seems like they are trying to make the users of the SDK think that the image is more raw than it is. It is NOT a 14 bit image. It is a 16 bit image, that got scaled to 16 bits.

Is it really that hard for them to create an SDK function that exposes the TRULY RAW 14 bits per pixel sensor data?
Or does this conversion take place in the thermal imager itself, via the firmware running on the device's microcontroller?

Do you know, that all sensor values in radiometric mode are not really RAW values, got from ADC!

Also I wrote in your thread, that the raw values send over USB divided by factor 4:

--- Quote from: tomas123 on January 18, 2016, 10:16:23 am ---I found a simple solution to check the factor 4 between "Lepton RAW" and "Flir radiometric jpg RAW":

The tea bag simulator of Flir SDK use real Lepton sensor values. You found it in the SDK file (6MB).
I made with the SDK App a shot from the (random) tea bag frame 00051.
Thereby we got a Flir radiometric jpg with an embedded calibrated RawThermalImage with a good temperature range from min/max=34°C/65°C ;)
(the unrealistic min temperature is a result of bad calibration values for the simulator)

first some image magick steps with the lepton sensor values of frame 00051 (file 00051-lep) from SDK
("-chop 2x0+0+0 -chop 2x0+80+0" removes the 4 additional vertical lines with extra unknown informations)

--- Code: ---// convert sample frame 00051 from SDK
> convert -depth 16 -size 164x120 gray:00051-lep gray:- | convert -depth 16 -endian lsb -size 164x120 gray:- -chop 2x0+0+0 -chop 2x0+80+0 -rotate 90 00051-lep.png
// multiply with factor 4
> convert 00051-lep.png -fx "4*u" 00051-lep4x.png
// get channel statistics
> identify -verbose 00051-lep4x.png
  Channel statistics:
    Pixels: 19200
      min: 14220 (0.216983)
      max: 20840 (0.317998)
      mean: 15014.9 (0.229113)
      standard deviation: 1218.95 (0.0186)
      kurtosis: 5.54453
      skewness: 2.30479
--- End code ---

and now compare the statistics with the "real" Flir radiometric image from the SDK app

--- Code: ---// extract RawThermalImage from a Flir radiometric image
> exiftool -b -RawThermalImage FLIROne-2016-01-18-10-33-07+0100.jpg > 00051exif.png
// image is postprocessed and resized to 320x240
> convert 00051exif.png -resize 160x FlirAppRAW120x160.png
// get channel statistics
>identify -verbose FlirAppRAW120x160.png
  Channel statistics:
    Pixels: 19200
      min: 14266 (0.217685)
      max: 20831 (0.317861)
      mean: 15021.4 (0.229212)
      standard deviation: 1221.27 (0.0186354)
      kurtosis: 5.44004
      skewness: 2.28451
--- End code ---

By deducting the Flir post processing steps to the original RAW values (see patterns below) we got a great result!
A sample:

max-min=20831-14266=6565 digits
-> 1 digit = 31/6565=0.0047 Kelvin
The difference between mean in this images is:
(15021.4-15014.9)*0.0047 Kelvin= 0.031 Kelvin  :-+

You also see, that the last digit ADC "resolution" of Lepton in this range is > 0.0047*4 = 19mK (useless because of strong noise, see second image below with 4 Kelvin scale)

--- Quote from: tomas123 on November 16, 2015, 11:58:16 am ---here is a real live sample from Flir One G2 (shot after a small warm up time of about 2 minutes):

I saved with the simultaneously a upscaled Flir Radiometric JPG  and a real Lepton ThermalLinearFlux14BitImage.

Afterwards I rebuild with my old panorama script (see my footer) a real size 160x120 Lepton radiometric jpg (a Flir format).
You can load this sample jpg images in Flir Tools and compare the quality.

First a original image shot with the Flir App.
The App crop  >:(  the Lepton sensor to about 120x90 Pixel.
Please note the artefacts/patterns!
Flir makes a nice lens distortion correction of the Lepton sensor for best MSX overlaying  ;)

real  Lepton sensor 160x120 (no image postprocessing and with noise/grain because the temperature spread is only 4 Kelvin)

--- End quote ---

--- End quote ---

Bill W:
Told you !

So FLIR's use of the term 'RAW' offends ?  It seems in line with 'RAW' as used on visual cameras, see
ie inherent sensor nonuniformity and dead pixels are removed before saving.  The maths to do this will go to 32 bits and be truncated back to 16. 

Do you get all the possible LSB values ( 0,1,2,3,4,5,6,......255) or simply two trailing zeros instead of two leading ones (eg 0,4,8,12,16,20...252 )?



--- Quote from: tomas123 on May 01, 2016, 09:17:06 pm ---Do you know, that all sensor values in radiometric mode are not really RAW values, got from ADC!

--- End quote ---

I'm not talking about radiometric mode (what FLIR One SDK calls ThermalRadiometricKelvinImage). I'm talking about what is SUPPOSED TO BE a true raw image (what FLIR One SDK calls ThermalLinearFlux14BitImage). That is supposed to be a completely raw, uncalibrated signal, straight from the microbolometer to your Android phone or tablet, with the intent that the app designer using that mode will write their own calibration routine (calibration done in software rather than in hardware). But FLIR's name for it (ThermalLinearFlux14BitImage) is a lie, because it is NOT 14 bits. It's stretched to fill the entire 16bit range possible using 2-bytes-per-pixel. And even worse, an overflow causes it to wrap around to 0, instead of simply saturating at 65535. I consider this to be a flaw in their SDK, and hope it is corrected in future versions of their SDK.

Or maybe, somebody will figure out how to alter the FLIROneSDK.aar file itself, and implement true raw image as a feature in their hacked version of the SDK. Since AAR files are just zip files, it would be easy to extract the Java classes from it, then a good hacker should be able to disassemble the .class files into .java source code files, edit these files in the way they handle the FLIR One USB protocol, so that they will attempt to actually get true raw images from the FLIR One, then recompile the .java files to .class files, and finally put these java class files back into the AAR file to replace the defective ones that FLIR created.

Believe me, I hacked since years some steps of image processing of the Flir cameras.

The noticeable market edge of Flir is the post processing of the sensor values.
The true sensor raw is a useless signal for you.

The microbolometer generates some noise and drifts, which are filtered with the flat-field correction (FFC):
Pixel Noise
Row Noise
Column Noise

The next step is the bad pixel mapping.

After then the Flir firmware converts (in radiometry mode) this post processed signal to a value which is linear to radiance [W / m^2 (per nm)].
This computational result is the so-called 14 Bit Raw signal (like ThermalLinearFlux14BitImage)

If you are interested in such things, then you can download interesting knowledge papers and sensor manuals from the Flir Web Site.
A good entry point is the datasheet of die Lepton 3 sensor;attach=206832

I have a Flir Exx. There is a service menu, where I can deactivate some postpressing features.
The result is "impressive".

If you are interested in the image quality of really raw microbolometer values, then read the seek thread in this forum..


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version
Powered by SMFPacks WYSIWYG Editor
Powered by SMFPacks Advanced Attachments Uploader Mod