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

[ZigmundRat]

That looks reasonable to me. Nice that the temp plots are movable. Do they toggle on/off as well?
I really need to get one of these to play with. I'd like to check for cold spots/heat leaks in the house, not to mention all the other typical uses. I'll go stuff one in my amazon cart.

I know you transitioned from Python to C/C++. What's the build environment? Basic configure/makefile stuff or under VSCode or ... ?

[G28]

That looks reasonable to me. Nice that the temp plots are movable. Do they toggle on/off as well?
I really need to get one of these to play with. I'd like to check for cold spots/heat leaks in the house, not to mention all the other typical uses. I'll go stuff one in my amazon cart.

I know you transitioned from Python to C/C++. What's the build environment? Basic configure/makefile stuff or under VSCode or ... ?

I made some more refinements.  The horizontal ruler only has horizontal temps, the vertical ruler on has vertical temps.  Can pretty much do any configuration.  I am entertaining feature requests.  So far, I am adding what I would use.

There are 3 "onscreen" display modes (not to be confused with scaling and layout modes).

    - Menu + Graphics + Video
    - Graphics + Video
    - Video only

You can also adjust the "Threshold" setting until the Min/Max temps appear or disappear.  This was one of the base options in the Python script.

Right now the 'o' key starts and cycles through all of the ruler configurations.  The right mouse button kicks it out of ruler mode and back into user defined temp location mode.  The app currently works in those 2 mutually exclusive modes because of the shared left mouse button usage.

I hate making Makefiles and cmake is overkill.  Right now the code is contained in a single ".cpp" file.  The single g++ line has a CFLAGS and a DEFAULT_FLAGS line broken out to define default startup configuration options and specific platform flags.  All is in a single bash script.

It was built on OpenCV 4.5.1.  Latest version is 4.8.0.  Some of the OpenCV APIs require minimum versions.

It also requires the pthread library.

I experimented with CUDA optimizations, but NVIDIA CUDA is not required for the build and was removed from the build script.

Here is the build script:

Code: [Select]

#!/bin/bash

# Build Thermal Camera Redux

rm ./redux

# Change build flags based on your hardware
CFLAGS='-mavx2 -msse4.2 -msse4.1 -malign-double -march=skylake'

# Setup default startup configuration options

# ROTATION options:         0, 90, 180, 270
# USE_CELSIUS options:      0, 1
# DEFAULT_COLORMAP options: 0 - 36

# 800x480 is a max of 2X scale
#DEFAULT_FLAGS='-DDEFAULT_COLORMAP=4 -DROTATION=0 -DDISPLAY_WIDTH=800 -DDISPLAY_HEIGHT=480 -DUSE_CELSIUS=0'

DEFAULT_FLAGS='-DDEFAULT_COLORMAP=4 -DROTATION=0 -DDISPLAY_WIDTH=2560 -DDISPLAY_HEIGHT=1600 -DUSE_CELSIUS=0'

g++ -Wall -O3 ${DEFAULT_FLAGS} ${CFLAGS} -I/usr/include/opencv4 tc001.cpp -o redux -lpthread `pkg-config --cflags --libs opencv4`


Here are the usage and keybinding statement:

Code: [Select]

Thermal Camera Redux:
Ported and updated C/C++ app based on Les Wright's 21 June 2023 Python app
https://youtube.com/leslaboratory

A multi-threaded C/C++ app to read, parse, display thermal data from the Topdon TC001 Thermal camera
Rewritten with additional functionality, bug fixes, optimizations and offline post processing
Built with display 2560x1600, max:default scale 8:4, rotation 0, default Fahrenheit, 37 colormaps, Jet

Camera Usage:
./redux n (where 'n' is the number of the desired video camera)

Offline Usage:
./redux -f input.raw (where input.raw is a raw dump file from ./redux)

Key Bindings:

a z: [In|De]crease Blur
s x: Relative Min/Max temp display threshold delta from Avg temp
d c: Change interpolated window scale [camera native to fullscreen]
f v: [In|De]crease Contrast
g b: Cycle [for|back]wards through interpolation methods
j m: Cycle [for|back]wards through Color[m]aps
w  : Cycle through single/dual[horizontal/vertical] [w]indow layouts
G  : Toggle between fullscreen and current scaled window size
r  : Toggle [r]ecording (both .avi and offline .raw)
R  : Reset defaults
p  : Sna[p]shot (both .png and offline .raw)
h  : Cycle through overlayed screen data
t  : Toggle between Celsius and Fahrenheit
y  : Toggle Historgram filter (for gray scales)
8  : Rotate display 0, 90, 180, 270 degrees (Portrait and Landscape)
e  : Toggle Freeze Frame on/off
o  : Displays and cycles through 5 temp ruler modes
   : Keypad Up/Down/Left/Right/Center(5) moves rulers
   : Left mouse adds user temps or moves rulers
   : Right mouse removes user temps and disables ruler mode
?  : Misc stdout help information
q  : Quit

main(2868): Opening cameara /dev/video0


Here are some snapshots of the horizontal ruler.  It is obvious the hottest part of the flatscreen's electronics is on the right side.

[G28]

Les's original Python script has a user adjustable threshold delta (in degrees Celsius) from the average screen temperature which determines if the Min/Max temps are shown or not.

I incorporated this user adjustable +/- threshold relative to the average temp into the ruler plots. 

The delta now also represents the current F/C unit selection.

    - If the row or column temp is within +/- threshold degrees from average, the temp plot will be white.
    - If the row/column temp is greater than threshold degrees, the plot will turn green.
    - If the row/column temp is less than threshold degrees, the line plot will turn red.

This gives another visual queue to the relative selected row or column temp plots and is adjustable from [0-N] degrees C/F.

[Amish Technician]

Working very well on pi4 4GB

My modified build script:

Code: [Select]

#!/bin/bash

# Build Thermal Camera Redux

rm ./redux

# Change build flags based on your hardware
CFLAGS='-mcpu=cortex-a72 -ftree-vectorize -O3 -pipe -fomit-frame-pointer'

# Setup default startup configuration options

# ROTATION options:         0, 90, 180, 270
# USE_CELSIUS options:      0, 1
# DEFAULT_COLORMAP options: 0 - 36

DEFAULT_FLAGS='-DDEFAULT_COLORMAP=4 -DROTATION=0 -DDISPLAY_WIDTH=1920 -DDISPLAY_HEIGHT=1080 -DUSE_CELSIUS=1'

g++ -Wall -O3 ${DEFAULT_FLAGS} ${CFLAGS} -I/usr/include/opencv4 tc001.cpp -o redux -lpthread `pkg-config --cflags --libs opencv4`

./redux


Excellent work   

[G28]

AT,

Thank you for testing on the RaspPi.  Glad to hear it works on the Pi4.

Just sent you an update with the latest changes. 

The new plotting rulers may take some more CPU cycles and there maybe some thread load balancing to be had to keep the FPS up.

[RO]

I have picked up one of those Victor 256 usb dongle imagers which works perfectly with the Topdon TC001 app, and have a Pi Zero 2W available, and could eventually free up a Pi4B, wouldn't mind testing if it will work with you app/script. The Victor imager seems equivalent, not sure if there might be a different protocol.

Am a bit busy though so might take me a while to produce adequate feedback if it requires a lot of configuration.

[G28]

I have picked up one of those Victor 256 usb dongle imagers which works perfectly with the Topdon TC001 app, and have a Pi Zero 2W available, and could eventually free up a Pi4B, wouldn't mind testing if it will work with you app/script. The Victor imager seems equivalent, not sure if there might be a different protocol.

Am a bit busy though so might take me a while to produce adequate feedback if it requires a lot of configuration.

You are more than welcome to test and provide feedback.  It appears there are a lot of clones of this device so the software may work on many of them.

Amish Technician has been generously testing and providing valuable feedback on a Pi4 and may be trying it on a Pi Zero 2 if/when he has time.   

I am not familiar with the Pi models so don't have any idea how it will do on a Pi Zero 2. 

Setup is pretty easy if you have the libraries installed, but someone will have to come up with the compile flags for the Pi Zero 2.

AT is reporting @ 50% CPU usage @ 5X scale for the double wide display (2560 x 960) with both rulers active (18 temps) for the current version on the Pi4 if that is of any hint.  Compared to the Python script, that is pretty good considering the additional functionality.  The Python script was single threaded and would peg out the thread on my i7-9700 just calculating the temps correctly.

Scaling and interpolation are CPU intensive.  Dragging is also CPU intensive, but it can run in jump-scroll mode (point and click).  Keeping that in mind, the features can be scalable (or avoided) based on the platform's processing power.

Just figured out how to add configurable transparencies at AT's request so the OSD menus now show the video underneath. 

Also made some optimizations over the last few days to speed up dragging and renders for weaker processors.

PM me if you want to figure out the Pi Zero 2 flags, or you can use the existing Pi4 flags if you free up your Pi4 or want to run it on a PC.

New Translucent OSD:

Other updates from AT's feedback:

- Added loss of camera connection recovery functionality.  If connection is lost, app goes into FreezeFrame mode displaying the last frame and an error message until connections are corrected.
- Reworked font and widget scaling so they plateau at given scaling levels.
- Added average temp indicator '-' to the color map gradient scale on right.  I use it more than the avg  temp in the OSD.
- Color coded average temp indicator '-' and crosshair temp indicator '>' on the gradient scale the same as the ruler plots using the configurable Threshold delta.

[G28]

Added optional translucent OSD keyboard and mouse usage help today.

Note: Video Blur is set in this image capture.

[G28]

Latest updates include significant performance optimizations in FreezeFrame and Offline modes.  This should enhance usability on weaker hardware.

Thanks to Amish Tech for testing on the RasbPi platforms and making valuable recommendations.

The following image shows automatic FreezeFrame mode when live camera communications are lost (e.g. cable disconnections).  Once errors are addressed, live feeds can resume by exiting FreezeFrame mode.

Note: Video Blur is set to 68 in this image capture.

When using live mode on weaker hardware, FreezeFrame mode can be manually entered which frees up significant resources for analyzing the captured frame with any of the app's more computationally intensive features.

[G28]

Another minor update:

Made some refinements to the horizontal and vertical rulers as well as more thread balancing and optimizations to run better on SBC's.

[5U4GB]

Is it Pi-specific or would it also work on alternatives like an Odroid?  I've got a TC001 that I usually use with the app via a U-adaptor for the USB-C port but it'd be nice to have an alternative way of driving it if they ever discontinue the app or the vendor goes away.

[G28]

Is it Pi-specific or would it also work on alternatives like an Odroid?  I've got a TC001 that I usually use with the app via a U-adaptor for the USB-C port but it'd be nice to have an alternative way of driving it if they ever discontinue the app or the vendor goes away.

I am running the code on Debian 11 and Amish Technician is testing in various Rasb Pi models.

The app uses C/C++, pthreads and the opencv 4.51 library. 

If your platform is Linux based, it should probably work.

[Amish Technician]

UPDATED: https://www.eevblog.com/forum/thermal-imaging/rasbpi-and-topdon-tc001-(guinea-pig)-tester-requested/25/#msg5270445

So far I have Thermal Camera Redux working on the following Pis with the 2023-12-05 release of Raspberry Pi OS desktop 64-bit (Debian 12 bookworm):

  RPi 2 Model B v1.2       BCM2837      ARMv8-A     (64/32-bit)   4× Cortex-A53 900 MHz   CFLAGS='-mcpu=cortex-a53 -pipe -fomit-frame-pointer'
  RPi 3 Model B v1.2       BCM2837B0  ARMv8-A     (64/32-bit)   4× Cortex-A53 1.4 GHz    CFLAGS='-mcpu=cortex-a53 -pipe -fomit-frame-pointer'
  RPi Zero 2 W                BCM2710A1  ARMv8-A     (64/32-bit)   4× Cortex-A53 1 GHz       CFLAGS='-mcpu=cortex-a53 -pipe -fomit-frame-pointer'
  RPi 4                             BCM2711       ARMv8-A    (64/32-bit)   4× Cortex-A72 1.8 GHz    CFLAGS='-mcpu=cortex-a72 -pipe -fomit-frame-pointer'
  RPi 5                             BCM2712      ARMv8.2-A  (64/32-bit)   4× Cortex-A76 2.4 GHz    CFLAGS='-mcpu=cortex-a76 -pipe -fomit-frame-pointer'

Performance is very good on the pi4 at x4 scale, x5 slightly reduces the frame rate. It's especially good on pi5 up to x5, and still keeps the responsiveness and frame rate usable up to x7. It's very responsive on the others as well so long as you stay at 3x scale or lower, x4 is still usable with a frame rate ~20.

I'm still working on:

RPi Zero v1.3                    BCM2835    ARMv6Z    (32-bit)       1× ARM1176JZF-S 1 GHz   VFPv2; NEON not supported
RPi 2 Model B v1.1           BCM2836    ARMv7-A   (32-bit)       4× Cortex-A7 900 MHz        VFPv4 + NEON

I think I also have a RPi 3 Model B+ but I won't be going to it for a few week. I can't imagine the result will be any different than the non + version anyhow, or for the model A variants I don't have.
I also don't have any of the original variants but I believe they use the same ARM1176JZF-S as the first pi zero so they will most likely work the same, or not, we'll see how I get on when the libopencv-dev package finishes downloading and installing on Raspberry Pi OS (Legacy, 32-bit) 2023-12-05 which is taking an eternity at the moment. 

[Amish Technician]

Working on Pi zero v1.3 !!! the lowest powered Pi I have, result!

At x1 scale with the default HUD I have a usable average of 11.7 frames per second, there is some delay but it feels completely smooth. It's like the flirs and others with the 7 or so FPS limit, only slightly better.

The CPU is only slightly warm to the touch after ~5 minutes so I'm tempted to see if some overclocking helps. I may have to do something to stabilise the power supply first though as it caused the Pi zero to reboot when I plugged the TC001 in, none of the other pi's had this issue using the same power supply.


Pi2 v1.1 testing will have to wait for another day 

[G28]

First of all, I wish to extend a big thanks to Amish Tech for his extensive testing on so many Rasb Pi platforms. 

Adding more refinements to the thermal rulers as a result of using them on my own thermal audits.

The original rulers used a proportional distribution method relative the screen's average temp as shown in the 1st image.

This works fine until there are extreme outliers that skew the plot of the non-outlier temps (e.g. a light bulb in frame when looking for cold spots).

To address this, an equal distribution mode with outlier clipping has been added.  This allows you to visually recognize the details such as the min temperature drop in the lower right hand corner that is compressed in the proportional plot. 

Modes are toggled in real time with a hot key so it is fast/easy to compare plots.

[G28]

FWIW, the app can be run "headless" from a remote machine by using X11 forwarding.

https://goteleport.com/blog/x11-forwarding/

Use "ssh -X username@ipaddress" to log into your remote machine that is running an X Server. 

It will not work with runlevel=3 that does not start the X server.

The -X ssh session automatically sets the DISPLAY environment variable in the ssh session.

Use the "xhosts" command on your local machine to allow remote X clients to display on your local machine.

You can then run a test X app (via CLI on the remote machine) to validate display on the local machine (e.g. xeyes or xterm).

Then run the redux OpenCV app.

It runs faster over the network than running the full remote desktop (less pixels to push), but not as fast as running locally without the network overhead.

As long as you have the X Server running on both ends, you should be able to remotely run the app "headless".

Hope this helps those with networked SBC's with no attached displays.

[5U4GB]

FWIW, the app can be run "headless" from a remote machine by using X11 forwarding.

For people using MobaTerm (my preferred SSH client), it's usable directly, just start MobaTerm's built-in X server, enable X forwarding in the MobaTerm settings window for that session/host, and you're done.  You may optionally need to enable X in the SSH config on the target system, but it's usually enabled by default.

Having said that, I've just tested it with an xterm so far, still getting round to setting up the TC001 stuff.

[G28]

Added 2 more ruler clipping modes.

• Proportional - no clipping
• Equal - outlier clipping
• Below average clipping - focus on above average temps
• Above average clipping - focus on below average temps

Proportional:


Equal - outlier clipping:


Below average clipping:


Above average clipping:

[G28]

Added adjustable ruler thickness in range [ 1/5, 1/4, 1/3, 1/2 ] screen height to all ruler modes.

1/5 screen height:



1/2 screen height:

[G28]

Added 1/1 ruler thickness mode.

In this mode, the plot is full screen and becomes decoupled from the cross-hair temp grid. 

The cross-hair temp grid still moves around the screen as the plot updates, but the plot's position remains fixed relative to the upper left hand corner of the screen, no longer positioned relative the moving cross-hair temp grid.

All of the other ruler modes are available in this full thickness mode.

[G28]

Minor Updates:

- Added user selectable fonts.
- Optimized ruler drag scrolling to increase performance on slower hardware.
- Made visual improvements for 1X and 2X scale, low resolution displays.

Dual full ruler display mode:

[G28]

"Thermal Camera Redux" is being posted to Github. 

All future updates will be available there free, for personal, non-commercial use.

No Microsoft or similar app stores required. 

https://github.com/92es/Thermal-Camera-Redux

[Amish Technician]

Fantastic seeing the project on Github  very cool 

I've finally tested the RPi 2 Model B v1.1 with the same version I tried on all the others, and release 16 which I haven't tried on the others yet. Here is an updated list with my suggested scaling for stock CPU clock speeds and performance notes:


Tested with the 2023-12-05 release of Raspberry Pi OS desktop 64-bit (Debian 12 bookworm):

RPi 5                             BCM2712      ARMv8.2-A  (64/32-bit)   4× Cortex-A76 2.4 GHz     CFLAGS='-mcpu=cortex-a76 -pipe -fomit-frame-pointer'    5x Excellent   7x Very usable   
RPi 4 / 400                    BCM2711       ARMv8-A    (64/32-bit)   4× Cortex-A72 1.8 GHz     CFLAGS='-mcpu=cortex-a72 -pipe -fomit-frame-pointer'    4x Very good  5x Very usable   ### RPi 400 Untested, higher stock CPU clock may yield slightly better performance
RPi Zero 2 W                BCM2710A1  ARMv8-A     (64/32-bit)   4× Cortex-A53 1 GHz        CFLAGS='-mcpu=cortex-a53 -pipe -fomit-frame-pointer'   3x Very good  4x usable
RPi 3 Model B v1.2       BCM2837B0  ARMv8-A     (64/32-bit)   4× Cortex-A53 1.4 GHz     CFLAGS='-mcpu=cortex-a53 -pipe -fomit-frame-pointer'   3x Very good  4x usable
RPi 2 Model B v1.2       BCM2837      ARMv8-A     (64/32-bit)   4× Cortex-A53 900 MHz    CFLAGS='-mcpu=cortex-a53 -pipe -fomit-frame-pointer'   3x Very good  4x usable


Tested with the 2023-12-05 release of Raspberry Pi OS desktop Legacy 32-bit (Debian 12 bookworm):

RPi 2 Model B v1.1       BCM2836      ARMv7-A     (32-bit)       4× Cortex-A7 900 MHz          CFLAGS='-mcpu=Cortex-A7 -pipe -fomit-frame-pointer'            2x Good with default HUD, 3x Usable. Struggles with extra window layout.
RPi Zero v1.3                BCM2835      ARMv6Z      (32-bit)       1× ARM1176JZF-S 1 GHz     CFLAGS='-mcpu=ARM1176JZF-S -pipe -fomit-frame-pointer'   1x with default HUD 11.7 fps average, some delay but smooth.
RPi 1                             BCM2835      ARMv6Z      (32-bit)       1× ARM1176JZF-S 700MHz  CFLAGS='-mcpu=ARM1176JZF-S -pipe -fomit-frame-pointer'   ### Untested. Variants with 512MB of RAM are likely to work but expect a very low frame rate, YMMV with the 256MB variants.

Model A, +, and compute modules have also not been tested but are likely to work the same as their model B counterparts. None Raspberry Pi SBCs that run a linux desktop may also work.


I'll go through my collection of RPIs again at some point soon as I noticed some image artefacts ('banding') which changed depending on how demanding the options where that I enabled. I only noticed this on some of the slower models, I need to check this again because I didn't note which models were affected as I initially assumed it was caused by the sensor in my camera. I'll use the latest version as my testing is a few versions behind now.

I also want to try the RPi zero v1.3 again with the last release I have before multi-threading was added, version 4 I believe, to see if it helps performance.

When time allows I'm also interested in testing "headless" using X11 forwarding, I haven't' attempted this at all yet. I'm sure a headless RPi zeroW / 2W could be a neat setup for some applications, very compact and portable.

Thank you again G28 for all the improvements and updates. 

[G28]

...
Tested with the 2023-12-05 release of Raspberry Pi OS desktop 64-bit (Debian 12 bookworm):
...
Tested with the 2023-12-05 release of Raspberry Pi OS desktop Legacy 32-bit (Debian 12 bookworm):
,,,
I also want to try the RPi zero v1.3 again with the last release I have before multi-threading was added, version 4 I believe, to see if it helps performance.
...
I'll use the latest version as my testing is a few versions behind now.
...

FWIW, the last releases (github) should be faster than the 12/5 release with the global font, halo and anti-alias changes which impact the HUD, HELP, temp text and marker displays across the board. 

Ruler drags should also be faster with the elimination of halo rendering during drag scrolls.

[cynfab]

Great job, It compiled easily on my MacBook Pro running Linux Mint, and displays a great image from my P2 Pro.

Thanks