Products > Thermal Imaging

Problems with RAW 14bit image in FLIR One

<< < (3/3)

I think I hear an echo ;)

Ok, I think I've figured out more about how this "raw" image is calculated now.

It includes the shutter "dark frame" correction. I can tell this, because when I took a picture of a hot object (my toast being made in the toaster this morning) it left a brighter than average spot on the sensor where the image of the heating element was (apparantly the IR radiation was so strong that it actually caused localized heating of part of the microbolometer array in the Lepton chip in the FLIR One). However, after manually sending the signal to do a shutter correction, that bright afterimage disappeared (was able to be calibrated out of the image), so obviously this isn't the true raw image (which would have no corrections applied). This effect was just temporary though, as after the localized heating started to cool down to the correct temperature, the shutter corrected region actually started to look darker, so I had to do another shutter correction once the localized heating effect was completely gone, in order to now remove the darker region

A can also now tell you why it looked like it wrapped around to 0. The truth is it didn't actually wrap around to 0. If it had have done so, some of the pixel values in the center of this "sensor overload" region would have been just above 0, where it was at its absolute hottest. But that's not what I observed. When I looked at the raw data, it instead had ALL of the overload region EXACTLY equal to 0. This suggests that 0 is actually used as an error indicator value, to signal a sensor overload. If 0 is used as an error value, then that means it can't be a valid actual signal value (no possible valid sensor value, either hot or cold, will produce a value of 0 in the raw data). This means that there must be some additive offset applied to the raw data, to make it so that 0 IR radiation intensity (the amount of IR radiation emitted by an object with a temperature of 0 Kelvins, absolute zero) does not actually produce a value of 0 in the raw data. Instead it would be stored as a value just above 0, so that the value 0 is reserved as an error value.

Now that I know this, it should be pretty easy to correct for this error indicator value, and bring it back to showing the actual saturated sensor value, by writing a program that takes this raw data, and simply fills in all pixels that have a 0 value with the value 65535 instead. Though I haven't tested it yet, my one concern might be that values that are "too cold" might also be indicated by a sensor overload error (raw value = 0) instead of indicating the actual sensor value. In that case, it would be impossible to tell if an error was caused by it being too strong of an IR signal or too weak of one. Hopefully, if there is a cold overload value, it will be indicated by a different error indicator value (maybe 1, instead of 0), so that it could be corrected for as well. The only remaining question then is what is the actual lowest raw IR sensor value supposed to be?

It should still, as I said before, actually be called ThermalLinearFlux16BitImage, instead of ThermalLinearFlux14BitImage. This is because all 16 bits are used to store this processed copy of the raw data. It is dishonest on FLIR's part to call it ThermalLinearFlux14BitImage, as this gives the false impression that it's raw-er than it actually is. It gives the impression that you are accessing the 14 bit raw data directly from the sensor, without processing, when you are in fact not doing that. Sadly, I think that is the impression that FLIR was trying to give, intentionally to deceive users of the SDK, so that they would think they were getting a purer, more raw form of the data than they actually are. I don't like companies that use dishonest business practices.

This are old news.

I wrote above something about 14 bit raw and FFC.

This overload pixels you  also see in raw images of Flir Exx

I just realized I made a mistake in my most recent assessment. The 0 value is NOT an overflow indicator. Instead what I had originally thought was happening is actually happening. It is going above 65535 and wrapping around back to 0, and continuing up from there. I can tell that because I got a better picture to work with now, and used the levels control in Photoshop several times consecutively (dragging the highlights slider all the way to the left) to boost the brightness dramatically (making even the darkest, most black-like, pixels have a value in the visible gray range) while in 16bits per pixel mode. This has allowed me to confirm my original suspicion, that there is an overflow occurring that goes above the value 65535.

However, there may be a dedicated "overflow range" down near the bottom of the brightness scale, that is below the value that would indicate no detected IR radiation, in order to indicate that there is an overflow on the upper end of the scale. If this is the case, then that still means that an offset is being added to the detector's raw values. Unfortunately I don't know how to determine what this offset is, as the only accurate way to do this would be to point it at an object that is at a temperature of absolute zero (or within a few millionth's of a degree above absolute zero, like is found in some very specialized physics experiments). If I'm going to detect overflows, I'm going to need to be able to find the range of values dedicated to indicating an overflow, and to do this I will need to know what the raw value offset for absolute zero IR radiation is. Can somebody help me out here with this?


[0] Message Index

[*] Previous page

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