ATA1-2, ATB1-2, ATX are no constants

[ReneHeim]

Dear Glenn,

in your temp2raw function description you are stating that the above-mentioned parameters are supposed to be used as implemented as they are constants (Line 40-41):

Keep these humidity parameters in since they are set constants required for a calculation
ATA1<-0.006569; ATA2<-0.01262; ATB1<--0.002276; ATB2<--0.00667; ATX<-1.9

Looking through my images and their EXIF information it seems that these constants change depending on the camera model. For my images/camera the "constants" are:

AtmosphericTransAlpha1 , Value : 1.23900001369748e-08
Key : APP1:AtmosphericTransAlpha2 , Value : 1.10949995857368e-08
Key : APP1:AtmosphericTransBeta1 , Value : 0.00317999999970198
Key : APP1:AtmosphericTransBeta2 , Value : 0.00318020000122488
Key : APP1:AtmosphericTransX , Value : 0.73199999332428

I have not tested yet how this impacts the conversion, but I thought I let you know.

Cheers,
René

Please find attached another example image for you to check my statement.

[gtatters]

Thanks for that! Hmm...maybe the UAV cams have been given different constants for the typical distances they are used at (I built my functions from SC series - research grade cams, often used at closer ranges). I will see about adding/checking what sort of error that might create and follow up on this thread my results/thoughts. If it looks bad, I might have to change the functions to account for these parameters. I wasn't sure how often the ATA values were being reported in all jpgs when I first put this together. good sleuthing.

[ReneHeim]

Glad I could be helpful after you helped me on a regular basis over the last months.

Cheers,
Rene

[gtatters]

So, to help de-crypt the function, these values are used to calculate tau values for the atmospheric attenuation of IR between object and the window and then between window and camera. Usually there is no window, so this will resolve to one common tau value for transmission through atmosphere. I can confirm that at 10 m distance, these will lead to different tau values (~1.0 vs. 0.97 for your values), and so I need to investigate how to include the values derived from the particular JPG, rather than use a fixed.

To fix I will need to update the flirsettings function and then the raw2temp and temp2raw functions.

Once I calculate what kind of error this might produce, although it will be distant dependent and worse for larger distances, I will post.

[gtatters]

it's even more embarassing! two of the constants I had in place were meant to be negative numbers, but rookie coding error on my part had forgot the brackets. So, I definitely need to fix this. Luckily, I've only used this for calculating <1 to 3 m away and the error would be minimal.

[ReneHeim]

Interestingly the calculated temperatures are not too far off from the ones calculated by the FLIR software. I am currently comparing this for a calibration method paper.

[gtatters]

yeah, I did check all the calcs myself to confirm that even using FLIR software (3 difference versions) yielded small differences (see https://github.com/gtatters/ThermimageCalibration), but Thermimage calcs were, on average, within 0.05oC. But I know that at longer distances, the error would be larger and need to fix that. working on an update to the functions to allow user to include the atmospheric attenuation constants.

I still plan to write Thermimage up as a paper, but these shared corrections are very helpful.

[ReneHeim]

I could send you an early update on my manuscript in January. Maybe a bit earlier. I was using in-scene calibration panels with known temperatures. Some measurements were made under a rain-out shelter others with the shelter. I want to compare your package conversion with another temperature retrieval method (Maes WH, Huete AR, Steppe K, 2017. Optimizing the processing of UAV-based thermal imagery. Remote Sensing 9.) and maybe even with the FLIR conversion and see how stable and useful our calibration is over time.

[gtatters]

sounds like a plan. Hopefully I can follow it. Recall, my intent with Thermimage was to recapitulate the calculations in use by FLIR, not to derive new approaches, so hopefully the minor error is fixed.

[gtatters]

So I've issued an update (v4, since I think an error in a function should require an update to make tracking easier).

The update affects raw2temp and temp2raw and allows the user to include the 5 atmospheric attenuation constants, but I have included default ones that are verified correct.

The error (if using <4 versus version >=4) can be calculated as:

# set a range of raw values from which to calculation temperature:
r<-seq(13000,22000)

# t1 would calculate based on version >= 4
t1<-raw2temp(r, E = 0.95, OD = 1, RTemp = 20, ATemp = 20, IRWTemp = 20, IRT = 1,
            RH = 50, PR1 = 21106.77, PB = 1501, PF = 1, PO = -7340, PR2 = 0.012545258, 
            ATA1=0.006569, ATA2=0.01262, ATB1=-0.002276, ATB2=-0.00667, ATX=1.9)

# t2 would calculation from < version 4 (where ATB1 and ATB2 were incorrect)

t2<-raw2temp(r, E = 0.95, OD = 1, RTemp = 20, ATemp = 20, IRWTemp = 20, IRT = 1,
            RH = 50, PR1 = 21106.77, PB = 1501, PF = 1, PO = -7340, PR2 = 0.012545258, 
            ATA1=0.006569, ATA2=0.01262, ATB1=0.002276, ATB2=0.00667, ATX=1.9)

e<-t1-t2

#  error from old calculations vs. updated:
mean(e)
sd(e)

Note: error could be quite unacceptable for long distances (>3 m), and users are advised to update to version 4, or do an error check using the sample calculations above.

For an object of 1 m distance, the offset error I found above was negligible (~0.03C), standard error of the difference was 0.22C.

The function, flirsettings, has also been updated to return the atmospheric attenuation constants from jpg files. Users are advised to verify the constants obtained from their images are used in the function above.

[ReneHeim]

Cool. Couldn´t you just retrieve the atmospheric attenuation constants from the EXIF information and hard-code them?

[gtatters]

retrieving those constants is part of the flirsettings function. Adding too many assumptions on my part would be dangerous. It was surprising to see them using different constants in the first place. Users need to be aware of these data.

Besides, I hard-coded them originally (thinking like you), but then discovered they can differ.

At the moment, if you leave the attenuation constants blank, the default values will be what I've worked out for my cameras and I imagine would apply as well as any other.

When I get a chance I'll post how the tau values differ. I think Minkina's book on Uncertainty in Thermal Imaging has a number of empirical curves for taus as a function of distance and humidity from different sources.

[gtatters]

Here is how the two different tau calculations would differ between my camera (1) and the image you updated earlier (cam 2):

As I suspected, the atmospheric attenuations differ between our cameras, for reasons related to the sensor (wavelengths of light being captured), and lens material, most likely? Distance, humidity and temperature effects should be common to a specific range of wavelengths, but not constant between SW and LW cameras.

So, yes it might be nice to auto-detect this from each file, but going down the auto-detection route requires continued troubleshooting on my part when new images with new information come out. I wanted the raw2temp and temp2raw functions to be the bare bones calculations without complicating things with file info extraction which is often platform dependent.

Plus, Exiftool already provides a versatile means to capture that information and the user will then be able to scrutinise the information and set the values themselves. For most people, following the examples should guide them to finding or modelling all of the necessary inputs for their calculations. Or so I hope.

[gtatters]

I'll close this for now, but feel free to comment further if things arise on this topic.