RPi/SBC/Topdon TC001/clone Tester request (Thermal Camera Redux v0.9.3) Github

[Quincy]

I've seen the message (letters are big enough ), but as there was neither an update here or there I did not think more closely about it.

Back on topic of thermal cameras:
I really like the offline mode very much - you can go back to whatever snapshot one has taken and work with it as if it were live. Also the locking is very useful for various reasons. IMHO it is not stated clear enough, that in this mode the thermal image itself is used for generating the main image. I would not be able to recognize as (except for the colors) it looks so similar to the original output of the camera.

In offline mode I can even produce a side by side comparison of what I found as erroneous earlier:



I took my old raw image fro offline mode, locked it and applied "Map 1" which is according to console output "Mapping filter: LINEAR".
On the left side there is the original camera image with added "Inv HSV" mapping, where the scale labels do not fit with labelled temps. Applying some color map to the obviously already mapped image fails - especially obvious if the range is large. On the right side the colors match the scale given for the left image: Power supply and lamp head with some blueish color indicating 30 °C and not in the mid of the images total temp range.

The left image definitely gives more visual guidance because there are more objects/contours visible, but I think no information in the image should be contradicting each other. According to screenshots of the original app it only labels the extremes of the scale with temperature, but nothing in between - to avoid the problem of non-linearity? As stated earlier I'm not too much into resource effectiveness in the first line in my current use case, but definitely not when content is wrong because of that.

So easiest way to solve this with minimal impact to current functionality and optimization for low-power platforms IMHO would be:
- do not display intermediate temperature labels next to the scale if we are not sure about its calculation
- as this is seems to always be the case with post-processing the 1st camera sub-stream, indicate the stream used for generation of the (sub-)window somewhere (as it is has already been started by "Img" and "Therm" indicators)
- add a scale bar (like it is now with intermediate labels) to the self-produced image with known mapping if it is present (generated from 2nd sub-stream because of locking and such)

Another track would be to fiddle out how the camera transforms the scale and reverse that processing to end up with something that we know. But I assume that also is computationally intensive like "forward processing" the raw temperature image due to the fact we need to apply some transformation function to all pixels present?

BTW: In offline mode there is no display change between "Clip" and "Grow" (obviously because it makes no sense with static information), but I still need to press "l" two times to get back to default, while nothing changes in display with the second key press. Perhaps it cycles through both modes in the background?
 

[G28]

I used a technique from the film era to do the edge enhancements called GaussianBlur, which contrary to its name Blur, actually increases image quality. 

Gaussian blur, a common image processing technique, can be used to enhance edges by
reducing noise and smoothing out unwanted details, making edges appear clearer and more defined.

Now that there are AI queries, there might be better alternate methods to employ. 

Maybe hook up the camera to AI for extreme image processing and deep fakes ? 

To address the color gradient linearity, I would rather try to reverse engineer what the camera is doing offline and then emulate its behavior in real time to retain the color gradient widget.

Yep, the blocking of auto-ranging was one of the last features added.  About the only use it has in offline mode is for debugging since there is only one static temperature range from a single frame.  Maybe that could change if logging and logging playback is added to offline mode.

The offline mode was my idea after trying to analyze thermal audit snapshots of my home.  It quickly became painfully obvious that I always wanted a different colormap, filter, ruler location, rotation, interpolated zoom level, etc. after taking the snapshot.  A still JPEG would not provide that information.

[ir-30thz]

Sorry for the slow reply

I would be happy to just have a measurement of the maximum temperature within a small area of the picture several times a second. The exact number is not too important but better than 1/second which is what TCview offers.

I am interested in ham radio using 30THz radiation  (10um wavelength, infrared) and want to monitor the surface of a remote parabolic dish which is being illuminated by a hot source which can be turned on and off so as to transmit slow Morse code.

[Quincy]

To address the color gradient linearity, I would rather try to reverse engineer what the camera is doing offline and then emulate its behavior in real time to retain the color gradient widget.

I do not want to remove the widget completely, just make it correctly labelled by removing the intermediate labels (which are wrongly indicating the color to temperature relation) and only keep start and end (which are correct) when working with the 1st sub-stream data (left side of my last image pair).
If the intermediate labels are correct because there is a linear scale (right half of the last image pair), the should stay as they are because they help getting better information of intermediate colors.

To address the color gradient linearity, I would rather try to reverse engineer what the camera is doing offline and then emulate its behavior in real time to retain the color gradient widget.

That would be nice and enable to always have intermediate labels which are correct. I just guess it needs some more work to figure out function they apply to the color scale - basically the difference between the linear and their interpretation. From the images it seems there is some compression of the scale on higher temperatures, but that may be only because of the low number/small area of hot spots.

Yep, the blocking of auto-ranging was one of the last features added.  About the only use it has in offline mode is for debugging since there is only one static temperature range from a single frame.  Maybe that could change if logging and logging playback is added to offline mode.

The offline mode was my idea after trying to analyze thermal audit snapshots of my home.  It quickly became painfully obvious that I always wanted a different colormap, filter, ruler location, rotation, interpolated zoom level, etc. after taking the snapshot.  A still JPEG would not provide that information.

The video currently getting recorded is from the displayed output which has basically the same limitations that you describe for the JPEGs. Why not record and later offline replay the original streams to use them?

Recording temperatures in some text format as @ir-30thz describes is another story IMHO. The full matrix stream (2nd sub-stream) is hard to parse if it is a video, but it seems there is the need to extract data in a textual form out of this stream. I think people there want to use the usual suspects like Python (pandas, numpy), R (tidyverse, data.table, array), Matlab and such.
For basic "home use" one could write out a table with multiple columns of temperatures at given markers together with a common timestamp column for all of them ("wide" data format). Rate of recording could be a setting (based on frame rate or some time). If markers could be also areas (currently only single pixel spot) and a function applied to that area which produces a single value (max/min/mean) this would also be a concept working for more complex cases.
Problem with such a solution: It's involving more GUI features to set up what is needed and as I'm not into OpenCV I don't know if there is much of this functionality already present in the library to not have to code that all yourself.