Flir E4 Thermal imaging camera teardown

[tomas123]

and I get a collection of very ugly .png images. Great
...
Something is wrong in the byte order switch thing

before you use a loop, try a single command pipe (works in windows and linux)

Code: [Select]

convert 001.png gray:- | convert -size 320x240 -depth 16 -endian msb gray:- 001.tifyou can convert the 16 bit tiff image to visible range (don't stitch it!)

Code: [Select]

convert 001.tif -auto-level preview.jpg
please upload a camera image and I convert a sample for you

[tomas123]

@larky
I found here my old post for converting Flir E4 radiometric image step-by-step
https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg348398/#msg348398

[mrflibble]

convert *.tif -resize 480x -sharpen 0x1 a_%03d.png

convert: no decode delegate for this image format `_FLIR0172.png.tif' @ error/constitute.c/ReadImage/555.   

Something is wrong in the byte order switch thing

Or you know, user error... Take a look at the file name (_FLIR0172.png.tif) and how that was built up. Then consider IM might have a problem guessing what format you mean to convert to. My guess is, fix the filenames, fix this particular error.

The seperate issue of changing byte order can be fixed with an IM oneliner.

Code: [Select]

convert has_wrong_byteorder.png gray:- | convert -depth 16 -endian msb -size 320x240 gray:- yay_byteorder_fixed.png


[larky]

Of course, I get a lot of user errors!
I was a little, OK, a lot, fooled by the fact that the png images all look completly gray. 

So this is the complete process now,

exiftool -b -RawThermalImage -if '$RawThermalImageType eq "PNG"' FLIR*.jpg -w %f.png

for i in FLIR*.png; do convert $i gray:- | convert -size 320x240 -depth 16 -endian msb gray:- 2$i ; done
convert 2FLIR*.png -resize 480x -sharpen 0x1 a_%03d.png

Import the gray png images to MS ICE, crop and export a stitched.tiff
php splitjpg.php -i FLIR0172.jpg -r stitch.tiff -o pano1
Open i FLIR tools, save and be happy!

thank you for the support, now out to shoot some panoramas!
 

[tomas123]

@larky
 

most questions about exiftool/convert scripts caused by the reversed byte order in embedded Flir PNG
it's painful
most Flir cams use 16Bit uncompressed RAW and some cams use compressed (!) 16 Bit PNG

the PNG spec defines only big endian
http://www.w3.org/TR/PNG/#7Integers-and-byte-order
the byte order is a result of processor architecture in Flir cameras and a no public PNG implementation

[mrflibble]

most questions about exiftool/convert scripts caused by the reversed byte order in embedded Flir PNG
it's painful
most Flir cams use 16Bit uncompressed RAW and some cams use compressed (!) 16 Bit PNG

It is indeed quite annoying. I have already gone over the Exiftool code (the Flir part of it), but as far as I can see there is not reasonable fix for the PNG situation. AFAIK some Flir camera's will use big endian and others user little endian. I could be wrong about that, and in fact I HOPE I am wrong about that because then there would be an easy fix.

Best compromise I can think of is to detect what flavor camera you are dealing with, and then based on that swap byte order or not. As in, if it's for example an E4 we know the embedded PNG is going to be crap because Flir decided to go non-standard on us. So extract PNG, swap bytes, repack PNG.

I already patched the latest exiftool version to have your extra tags in it (so I don't have to provide the extra .txt file with extra flir tags all the time). So if I'm going to patch it for use with a Flir camera I might just as well do aworkaround for this silly byte order business.

Do you (or anyone else) know what byte order is used by the various Flir cameras? I could fix it easy enough by always swapping byte order, but that wouldn't be very nice for owners of a Flir camera that actually does adhere to the PNG standard.

[tomas123]

Do you (or anyone else) know what byte order is used by the various Flir cameras? I could fix it easy enough by always swapping byte order, but that wouldn't be very nice for owners of a Flir camera that actually does adhere to the PNG standard.

Phil collect sample images from all cams
http://owl.phy.queensu.ca/~phil/exiftool/sample_images.html

Code: [Select]

$ exiftool -RawThermalImageType *
======== FLIR_B20HS.jpg
Raw Thermal Image Type          : PNG
======== FLIR_B335.jpg
Raw Thermal Image Type          : PNG
======== FLIR_Bertha3.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_E30.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_E30bx.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_E40.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_E40bx.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_E50.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_E60.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_P60.jpg
Raw Thermal Image Type          : PNG
======== FLIR_P60NTSC.jpg
Raw Thermal Image Type          : PNG
======== FLIR_P60PAL.jpg
Raw Thermal Image Type          : PNG
======== FLIR_P640.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_P660.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_T250_Western.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_T360_Western.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_T400.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_T400Western.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_T425.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_T620.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_T620bx.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_T640.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_ThermaCAM_A320.jpg
======== FLIR_ThermaCAM_E65.jpg
Raw Thermal Image Type          : PNG
======== FLIR_ThermaCAM_EX320.jpg
Raw Thermal Image Type          : PNG
======== FLIR_ThermaCAM_P640.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_ThermaCAM_P660West.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_ThermaCAM_SC640.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_ThermaCAM_SC660Wes.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_ThermaCAM_T-400.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_ThermaCamP660Wes.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_ThermaCamSC660WES.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_Z-Camera.jpg
Raw Thermal Image Type          : PNG
======== FLIR_b40.jpg
Raw Thermal Image Type          : PNG
======== FLIR_b50.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_i3.jpg
Raw Thermal Image Type          : PNG
======== FLIR_i5.jpg
Raw Thermal Image Type          : PNG
======== FLIR_i50.jpg
Raw Thermal Image Type          : PNG
======== FLIR_i60.jpg
Raw Thermal Image Type          : TIFF
======== FLIR_i7.jpg
Raw Thermal Image Type          : PNG
I published some php scripts for decoding radiometric flir images and they changes the reverse byte order automatic.
I also published some sample with IM pipes.
I don't know, how can we more help.
Change in exiftools are also not end user friendly, while Phil this changes not integrates in Exiftool Repository

Phil answered to my question about PNG byte order
http://u88.n24.queensu.ca/exiftool/forum/index.php/topic,4898.msg23672.html#msg23672

I don't plan to modify the raw data.  I just return the PNG as is, or tack a TIFF header onto the raw data, but that's as far as I'll go.  (ExifTool doesn't do image manipulations -- that's for other software.)

... but he has kindly exported 16 Bit RAW Data as Tif Images 

it's slow, but works:
changing the byte order with fx operator

Code: [Select]

$ echo -n ABCDEF | convert -size "3X1" -depth 16  gray:-  -fx '(u+int(u*65536)%256))/256' - | hexdump -C
00000000  42 41 44 43 46 45                                 |BADCFE|

$ convert FLIR0074.png -fx '(u+int(u*65536)%256))/256' FLIR0074.tif
http://www.imagemagick.org/script/fx.php
range of pixel intensity u is float 0...1 (independent of 8/16/32 Bit)

[tomas123]

I already patched the latest exiftool version to have your extra tags in it (so I don't have to provide the extra .txt file with extra flir tags all the time).

Which new tags do you found?

I posted here some extensions:
https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg343464/#msg343464 ?

Phil is a great fan for new tags.
post the tags (with my changes) here
http://u88.n24.queensu.ca/exiftool/forum/index.php/topic,4898.90.html
and give Phil an E4 jpg sample (see post above)
He will take over the new tags

[mrflibble]

I already patched the latest exiftool version to have your extra tags in it (so I don't have to provide the extra .txt file with extra flir tags all the time).

Which new tags do you found?

None whatsoever. What I tried to say is that I used your user config file you posted some time ago with your extra tags, and patched that into Exiftool source code. That way I don't have to specify that user config file on the command line every time.

[mrflibble]

I published some php scripts for decoding radiometric flir images and they changes the reverse byte order automatic.
I also published some sample with IM pipes.
I don't know, how can we more help.

Stricly speaking the problem is already solved. You have it in your php scripts, I have it in my python scripts. But despite us considering it problem solved we still get the occasional post with confusion related to swapped byte order.

That is easy enough to fix in exiftool, but this fix is really only going to be user friendly if it works out of the box. As in if I post a patch and that doesn't make it into mainstream then it is of no use. Because then the clueless would need even more clues (how to apply patch) than the clue required for fixing byte order with a imagemagick pipe.

Change in exiftools are also not end user friendly, while Phil this changes not integrates in Exiftool Repository

Phil answered to my question about PNG byte order
http://u88.n24.queensu.ca/exiftool/forum/index.php/topic,4898.msg23672.html#msg23672

I don't plan to modify the raw data.  I just return the PNG as is, or tack a TIFF header onto the raw data, but that's as far as I'll go.  (ExifTool doesn't do image manipulations -- that's for other software.)

... but he has kindly exported 16 Bit RAW Data as Tif Images 

In which case I'm not going to bother. My stuff works, your stuff works, the rest can RTFM and find the appropriate posts on how to swap byte order.

Best way would probably be to start a wiki page. Yes I noticed your posts about it, but not enough time back then. And among other things we could explain the byte swapping in the PNG file and how to fix it with a simple command line.

Main challenge then is to have new arrivals actually RTFW. But linking to a single url for the wiki page is less work than finding an old post in this rather large thread. 2600+ bloody hell.

[tomas123]

I prefer a public Wiki Site like
http://www.wikidot.com/plans
they have free community sites

and google give some hits with search

Code: [Select]

site:wikidot.com hack
but we need an admin with enough time 

[tomas123]

for all E4 users have trouble with pipes and reverse byte order I add third solution to my Flir Panorama Tutorial

https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg348715/#msg348715

Variant B.2: if you don't use pipes try Imagemagick mogrify
a sample with reverse byte order (like Flir Ex)

Code: [Select]

$ exiftool -b -RawThermalImage FLIR*.jpg -w %f.png
$ mogrify -format tif -fx 'u/256+int(u*65536)%256)/256' *.png

[OrBy]

Code: [Select]

$ exiftool -b -RawThermalImage FLIR*.jpg -w %f.png
$ mogrify -format tif -fx 'u/256+int(u*65536)%256)/256' *.png

This works very well!
I have managed to make a few now and have a very rough cmd file I can process them with (use at own risk):

Code: [Select]

@echo off
REM This cmd file assumes you have PHP, exiftool, and ImageMagick in the system path and have already edited splitjpg.php.
REM You also need to have MS ICE and FLIR Tools installed.
REM
REM Start the process by making sure that Panoramic.cmd and splitjpg.php are in the same folder as your source files for one shot.
REM Then run Panoramic.cmd by dragging the a file from the image set on top of of it.

exiftool -b -RawThermalImage FLIR*.jpg -w %%f.png

mogrify -format tif -fx u/256+int(u*65536)%%256)/256 *.png

del FLIR*.png

@echo Drag all the tiff files into MS ICE and crop and save them to a TIFF as stitch.tiff in the same folder as the source files then exit MS ICE.
@echo You will only see the images as grey - this is normal.
@echo Pressing any key will open MS ICE.

pause

C:\"Program Files"\"Microsoft Research"\"Image Composite Editor"\ICE.exe

@echo stitch.tiff should now be in the same folder as your source files and Panoramic.cmd/splitjpg.php.
@echo If it's not - move it there NOW before pressing a key.
pause

php splitjpg.php -i %1 -r stitch.tiff -o panoramic

@echo Open the panoramic.jpg file in FLIR Tools and resave it to rebuild the JPG preview.
@echo Pressing any key will open FLIR Tools.

pause

C:\ProgramData\Microsoft\Windows\"Start Menu"\Programs\"FLIR Systems"\"FLIR Tools.lnk"

pause

@echo You should now have a panoramic.jpg that can be used as you see fit.

del FLIR*.tif
del stitch.tiff
del *.fff
del raw.hex

On that note - I am trying to run one of the panoramic.jpg's I built through flir.php and keep getting an error:

Code: [Select]

Reflected Apparent Temperature: 20.0 degree Celsius
Emissivity: 0.95
Plancks values: 14020.368 0.02656248 1382.9 -7342 2.5

RAW Temp Range FLIR setting: 11115 12641
RAW Temp Range select      : 11115 12641
RAW reflected: 12167
Warning: GPS pointer references previous ExifIFD directory - C:/Users/OrBy/Downl
oads/FLIR E4/Manual Convert/panoramic.jpg
Warning: GPS pointer references previous ExifIFD directory - C:/Users/OrBy/Downl
oads/FLIR E4/Manual Convert/panoramic.jpg
RAW Temp Range from sensor : 0 27773
convert.exe: divide by zero `14020.368/(0.02656248*(65535*u+-1.0*7342))' @ error
/fx.c/FxEvaluateSubexpression/2191.
wrote "done.jpg" with Temp-Range: 4.9 / 26.1 degree Celsius
The output file is kinda half written but the end is corrupt.
Anyone have any insight?

[ixfd64]

FYI: TEquipment.NET just got a new stock of 20 E4's.

[steve1515]

The website still says zero. Where did you hear that?

EDIT: Nevermind... Different places on their website list different things. 

[tomas123]

@OrBy
you must open the "cripple" panorama.jpg with flir tools and rewrite (edit+save)  the jpg to write all  neccessary Flir Exif Tags

the fx operator is very slow, use a raw pipe in your batch (better solution)

[mrflibble]

convert.exe: divide by zero `14020.368/(0.02656248*(65535*u+-1.0*7342))' @ error/fx.c/FxEvaluateSubexpression/2191.
wrote "done.jpg" with Temp-Range: 4.9 / 26.1 degree Celsius

The output file is kinda half written but the end is corrupt.
Anyone have any insight?

Sure. Divide by zero is bad m'kay. So if that expression I emphasized in bold is getting close enough to zero so it gets rounded down to zero before division (due to precision limitations in convert or whatever) then you're boned.

I also like the numerical capabilites of ImageMagick, but personally I wouldn't use it for this for precisely this kind of reason. But I will admit, it seems to work better than I would expect.  As in, it took longer for this kind of problem to surface.

Doesn't php have reasonable PNG read + write + matrix operation support? That, or you could rescale the numbers a bit to avoid rounding errors if that is the case here.

[tomas123]

convert.exe: divide by zero `14020.368/(0.02656248*(65535*u+-1.0*7342))' @ error/fx.c/FxEvaluateSubexpression/2191.
wrote "done.jpg" with Temp-Range: 4.9 / 26.1 degree Celsius

The output file is kinda half written but the end is corrupt.
Anyone have any insight?

Sure. Divide by zero is bad m'kay. So if that expression I emphasized in bold is getting close enough to zero so it gets rounded down to zero before division (due to precision limitations in convert or whatever) then you're boned.

http://www.imagemagick.org/script/fx.php
I don't think, that the bold expression goes to zero

@OrBy
Do you have rewrite your panorama with Flir Tools?
Please post your jpg sample, if the error still occurs

I can open my panoramas with flir.php:

Code: [Select]

$ exiftool -raw* P1.jpg
Raw Value Median                : 14769
Raw Value Range                 : 1566
Raw Thermal Image Width         : 1410
Raw Thermal Image Height        : 638
Raw Thermal Image Type          : TIFF
Raw Thermal Image               : (Binary data 1799364 bytes, use -b option to extract)

$ ./flir.php -i P1.jpg -o test1.jpg

Reflected Apparent Temperature: -0.0 degree Celsius
Emissivity: 0.95

RAW Temp Range FLIR setting: 13986 15552
RAW Temp Range select      : 13986 15552
RAW reflected: 14005
RAW Temp Range from sensor : 13708 16000
wrote "test1.jpg" with Temp-Range: -0.1 / 10.0 degree Celsius

[mrflibble]

convert.exe: divide by zero `14020.368/(0.02656248*(65535*u+-1.0*7342))' @ error/fx.c/FxEvaluateSubexpression/2191.
wrote "done.jpg" with Temp-Range: 4.9 / 26.1 degree Celsius

The output file is kinda half written but the end is corrupt.
Anyone have any insight?

Sure. Divide by zero is bad m'kay. So if that expression I emphasized in bold is getting close enough to zero so it gets rounded down to zero before division (due to precision limitations in convert or whatever) then you're boned.

http://www.imagemagick.org/script/fx.php
I don't think, that the bold expression goes to zero

The FxEvaluateSubexpression related error message begs to differ. It only has to barf for one single pixel and you will get that error.

[tomas123]

I don't think, that the bold expression goes to zero:

u is RAW Sensor value => Integer

u   (0.02656248*(65535*u+-1.0*7342)
0   -195,0217282
1   1545,750399
2   3286,522525
3   5027,294652
4   6768,066779
5   8508,838906
6   10249,61103
7   11990,38316
8   13731,15529
9   15471,92741
10   17212,69954
11   18953,47167
12   20694,24379
13   22435,01592

let's post OrBy a sample

[mrflibble]

Can you tell me what the scaling factor of 65535 is doing there? Because if u is a 16-bit unsigned RAW sensor value then you might as well ditch the 1.0*7342 because that is vanishingly small to 65535*uint16 in the typical range for E4 raw images. But agreed, best just wait for the picture and test it.

[tomas123]

a good question and the answer for the error

I wrote formulas here:
http://u88.n24.queensu.ca/exiftool/forum/index.php/topic,4898.60.html

Code: [Select]

T = B / ln(R1/(R2*(S+O))+F)

T = object temperature in Kelvins
S = 16 Bit RAW value
R1 Planck R1 constant
R2     Planck R2 constant
B    Planck B constant. Value range 1300 - 1600.
F     Planck F constant. Value range 0.5 - 2.
O    Planck O (offset) constant. Its a negative value.
S = 16 Bit RAW value [0...65535]
ImageMagick u has a brightness range from 0...1  (float) , independent of 8/16 Bit
S= 65535 * u

the error comes from
ln(R1/(R2*(S+O))+F) => with  (R1/(R2*(S+O))+F)<0
if OrBy stitched a panorama with transparent edges he has a brightness of Zero
Flir Tools processed zero without errors

u   (0.02656248*(65535*u+-1.0*7342)
0   -195,0217282
1   1545,750399

snip from flir.php

Code: [Select]

// convert every RAW-16-Bit Pixel with Planck's Law to a Temperature Grayscale value and append temp scale
$Smax=$B/log($R1/($R2*($RAWmax+$O))+$F);
$Smin=$B/log($R1/($R2*($RAWmin+$O))+$F);
$Sdelta=$Smax-$Smin;
exec($convert." raw.png -fx \"($B/ln($R1/($R2*(65535*u+$O))+$F)-$Smin)/$Sdelta\" ir.png");

[mrflibble]

S = 16 Bit RAW value [0...65535]
ImageMagick has a brightness range from 0...1  (float) , independent of 8/16 Bit
S= 65535 * u

This was sort of my hint to you, in the form of a leading question.

So given that u is a float in the 0...1 range, what can we now deduce about the chances that the bit I put in bold actually does go to zero, and will cause an Fxsubexpressiondivbyzerothingyerror?

[tomas123]

I have converted thousend images with the fx operator without errors.
The fx operator is the fastet way for calculating 320*240 = 76.800 Pixel inside a script
http://www.imagemagick.org/script/fx.php
fx can also handle conditional expressions, but I see no need for changes.

[mrflibble]

I implied none of the <your_list_of_defenses>. All I'm saying is that the error is caused by a div by zero. Which for u=0...1 (you know, like you just said after my leading question will in fact happen. Your nice table of u=0,1,2,3,4 is nice, but has nothing to do with the computational reality of what the FX evaluate actually sees. Case in point. The stuff in bold is 1st order. For 0 your table entry is negative, check. For 1 your table entry is positive, check, Guess what the behavior of that 1st order function is for u values between 0 and 1. Exactly, it has a zero crossing. The u value where the bold stuff hits zero is left as an excercise for the reader.

I am not responding to your intentions, which I am sure are nice and positive and stuffs. Nor am I responding to your loads of images that have not resulted in a problem. (If I got $1 for every time I heard that one from a pouty dev I would be rich indeed ). I am responding to the error message, which says div by zero on an expression that indeed has a zero crossing for the denominator on the domain [0,1] for u.

But anyways, that's all from me on the subject. If it works for you it works for you.