-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Temp info getting #23
base: master
Are you sure you want to change the base?
Conversation
Thanks for your contribution. I will merge your code after my holidays. |
Hi Andrey, I tried your contribution concerning temperature on Maarten Project. However, i still can't understand how you managed to get these informations. Can you please explain a bit more your method and eventually how you did to obtain your linear trend line on excel. Thank you in advance for your help. |
@AchrefDash I'm curious, was the information you got meaningful? Did it match real world temperatures? The method is trivial: I have googled out that raw pixel values from camera are absolute. This means they contain actual temperature data, expressed in Kelvin value with some linear representation. Thus, I made some experiments to figure out linear law for these values, based on ice, boiling water and human body. The values for trend line are expessed in my source code comments. |
Hi @undera Thank you for your quick response. So, the results I have are almost similar to the results obtained with Seek App with a coefficient in addition. After doing some tests on human body, the soldering iron, lamps, electrical cabinets and others, I got an average coefficient of 0.8 to get almost the same Seek App tempetures values but this approach remains very approximate depending on the tests conditions. |
I modified your version a little bit to show the max/min hot/cold points with colored circles in the image and show the temperature with one decimal point at that location. It's not very nice but it works as a proof of concept. My problem at this point is that the shown temperatures are a bit too high. But i have to verify this with a known reference temperature. Source file: |
The ways to visualize the point may vary. |
just as a side note, Seek Thermal states that
I got a new CompactPro last week that had a offset of ~6-7°C after 5! minutes... |
@undera can you please explain how you came to this line of code? |
@pauledd Yes, I took it from excel function. |
@undera thanks, just one more question:
in your seek_viewer.cpp. Can you pls explain where you got this 15bits from? |
I don't remember exactly. In my experiments, I used candle as maxed temp value, and probably got this 32768 raw number. |
ah, okay. I will try that too :) |
Added more things to this PR:
|
What do you mean with this? Isn't the Seek Pro restricted to ~9fps? |
@pauledd Discrard what I've wrote there, I found I was confused |
Ok, my latest hypothesis is that formula is simple linear calculation, assuming 330C is max of 14bit value. Would be cool to gather some more observations. |
Values from app when camera self-temp is ~26C: Same setup, camera cooled down to ~18C: And after 10minutes: Which makes me conclude that camera self-temperature highly relates to values measured. I'll look for a way to use |
I have spent a lot of time calibrating dev sensor versus known temperatures, and I came up with compensation model that should react on device temperature and compensate it. I have added my Excel file |
@undera Great work! However, from my Seek Compact, I read measurements like
. Did you do your research with a CompactXR or CompactPRO? I suspect there could be different formulae for each model. |
I have only one CompactPro for Android device. |
@undera Good to know. So I want to do experiments with a Seek Compact and share my findings. |
Id did a series of calibration experiments. In the process, I wrote a viewer which stores the raw data in 16bit images for later processing. Unfortunately, finding a function to infer the actual device temperature from the raw value leaves me stumped. @undera How did you find the NTC information? Did you open your camera? I gave up and resorted to a linear approximation which seems to be exact within ±1°C after the device has warmed up. I published the adjustments in the temp-info_compact in my fork. |
vignetting is a known thing for cameras, it is known that Seek uses software way to compensate it in their apps. The problem of simple linear approach is that device's temperature will affect measurements, and I perfectly see that in my experiments. My approach of making sure sensor has certain temperature is simple: I turn camera off in a room with air conditioner set to certain temp, I let it quite of time to stabilize temp, then I quickly turn it on and record values. I also use trustworthy thermometer to tell what was the temp around it (and inside it). |
Thats not practical at all if you want a quick location-independent measurement without doing heavy cool-down calibration measurements and waiting for the sensor to finally settle after 30 minutes (that's what my device takes). My guess is Seek uses some kind of forward prediction math with a predefined characteristic curve for that thermal-sensors that it produces good temp values just right after powering up... just my 2 cents ;) |
Yes, I have same feeling that they have some formula they know. |
Thank you for your input.
Unfortunately, I currently have no options to produce environments with a range of stable temperatures wide enough to explore the non-linear parts of the assumed NTC reading. For the non-PRO variant of the Seek Compact, we are left with a linear approximation best fitting for a device temperature of whatever raw value of 4236 is standing for. Which is better than nothing, I guess.
Fortunately, I want to do a long-term fixed-location measurement (for quick measurements on the go, I'd actually use the official app). |
Hello,
Thank you in advance |
Nothing has changed. My impression is that people get different temperature because my formula is somehow wrong. But I have just one camera, so I have no way to validate this. Nobody brought any reliable measurements to compare, still. |
Until we somehow find a reliable formula, you can resort to static calibration:
I have an example application at my branch which stores the raw frames so you can do corrective temperature processing after the measurements. |
@hoehermann - In step 2 above, don’t we need an image with (at least) two different reference temperatures to make a linear interpolation of the relationship? Or how do you do it using only one reference temperature? |
@cjnqt I measured a plane of known temperature. As the device temperature changes, the reading changes. I calculated the offset of "reading should be" and "actual reading". Then I did a linear fit along |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice additional functionality! I have a few suggested changes here.
@@ -197,6 +206,8 @@ bool SeekCam::get_frame() | |||
if (!m_dev.fetch_frame(m_raw_data, m_raw_data_size)) | |||
return false; | |||
|
|||
// save_frame_img(m_raw_frame, frame_id()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left over debugging code?
double maxtemp=temp_from_raw(max, device_k); | ||
double centraltemp=temp_from_raw(central, device_k); | ||
|
||
printf("rmin,rmax,central,devtempsns: %d %d %d %d\t", (int)min, (int)max, (int)central, (int)device_temp_sensor); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to be pushing two lines to stdout for every frame? If these need to stay can you control their output with a command line parameter.
resize(frame_g8, frame_g8, Size(), scale, scale, INTER_LINEAR); | ||
resize(frame_g8_nograd, frame_g8_nograd, Size(), scale, scale, INTER_LINEAR); | ||
|
||
// add gradient |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you consider extending the image frame do that you don't end up overdrawing the thermal data so much?
|
||
// Apply colormap: http://docs.opencv.org/3.2.0/d3/d50/group__imgproc__colormap.html#ga9a805d8262bcbe273f16be9ea2055a65 | ||
if (colormap != -1) { | ||
applyColorMap(frame_g8, outframe, colormap); | ||
} else { | ||
cv::cvtColor(frame_g8, outframe, cv::COLOR_GRAY2BGR); | ||
} | ||
|
||
// overlay marks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of these overlays need to be controlled by a command line option defaulting to false.
void draw_temp(Mat &outframe, double temp, Point coord, Scalar color) { | ||
char txt [64]; | ||
sprintf(txt, "%5.1f", temp); | ||
putText(outframe, txt, coord-Point(20, -20), FONT_HERSHEY_COMPLEX_SMALL, 0.75, color, 1, CV_AA); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer FONT_HERSHEY_PLAIN, screen interfaces should use san-serif fonts.
Feel free to take from this PR whatever code you want and close it. I have no spare time now to spend on it, sorry. |
Would you mind flipping on the reviewers can edit setting so I can make those changes and merge it up. That way your contributions will get attributed correctly. If that's not possible to change after starting a PR I'll fork your branch and merge it under a separate PR. Thanks for all the work you put in here by the way.
edit: Actually that may have already been on. Sorry, I guess since I was looking at the first file (the binary one) GitHub wasn't offering up any options in the webUI and I assumed that wasn't enabled. |
The converting flux values to temperatures is not so easy task. Each sensor is different, so you will need to do calibration for each piece of camera separately. The conversion model is also not linear, but it should be done according to Planck's law (or its RBFO approximation) including thermal parameters of the viewed scene, such as emissivity, background temperature or atmospheric transmissivity. There is also an issue in this library, because it normalizes flat-field to value 0x4000. This can be correct only in the situation when the shutter temperature is constant (and is always the same as it was during the calibration). The correct way would be the normalization to mean value of FFC image, or better, to some value that corresponds to real flux emitted by the shutter. Because if shutter temperature is known (e.g. derived from camera temperature) it can be used for radiometric correction (flux viewed on shutter => shutter temperature). You just need to include some coefficient to correlate between shutter image and scene image to compensate for lens influence. |
Unfortunately, I am not a physicist and cannot implement this approximation without spending considerable time on educating myself first. :/
I just noticed that the data is actually available in |
It does not work on OpenCV v4 I changed |
Are you talking about just this branch or master? |
only this branch. master branch works for me :-) |
This branch reports values like So it seems more info is required? Still, super neat that this all "just worked" for the most part :) |
This forum and the corresponding Rpi2SeekDevA code suggest that the temperature profiles, calibration info etc can be sourced via specific pixels. https://www.eevblog.com/forum/thermal-imaging/running-seek-thermal-cameras-(-others)-on-a-raspberry-pi/ |
A useful link I used to get some info: https://github.com/lod/seek-thermal-documentation/wiki/Temperature-Values