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?
PS:
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.