Infiray and their P2 Pro - discussion

[mikeselectricstuff]

[...]
Are they so new that this hasn't come up yet? Or they a bit older already?

Speaking of T3/T2, I suppose the biggest differences between the T and the P series is the target market? T for 'outdoorsy things' and P for professional use? Idk. I see that the T's are sold in kit form with one of those 'gun-type' holders, though on ali express that doesn't seem to be the case?[...]

T3 is marketed since 2019, so yes its a bit older (see older threads here by using the search function).
There are outdoor versions of the "T" devices but I think that depends on the used lens.

An obvious internal difference is that the P2 has an ASIC, whereas the T2 uses an FPGA

[sofakng]

P.S. just noticed that on AE they also now list an iOS version, for those that care

Are you referring to Aliexpress?

I'm hoping that TopDon TC001 receives iOS compatibility without requiring a new device...

[oliv3r]

So pardon my ignorance

So T is FPGA, and P is ASIC, which could explain why the P2 is cheaper, FPGA's cost a lot. In theory, more functionality could be added to the T (if the development gods will it) and the FPGA variant _could_ be more powerful/feature rich in general I recon?

Anyway, So the sensor is about 50% more expensive and older, but at a higher resolution. There's no P3 only the T3, so would it make sense to hope that a P3 would be released somewhere this year? Or is the P2 'really more then good enough'. Higher res sure sounds nice, if all other things are equal. Heck If it'd take to long, might still try to get a T3 still...

[blubb]

Hi everyone,

I noticed that my P2 pro starts to flicker after a couple of minutes of run time. After I plug it in, it works ok at first. But then I get a 1-2 brighter frames every few seconds. The bright frames have all pixel values increased by about ~10-20 (8-bit greyscale). This continues until I unplug and restart the camera. Same behavior on Win10/11 with VLC capture and on Android with InfirayGo. The problem is visible directly in live viewer and occurs with and without the macro lens.

Anyone else with this problem?

[mattcaves]

Has anyone had issues with the thermal image just hanging? I'm getting rather frustrated with this device - it seems extremely picky about which devices it will run on at all, it doesn't work on my Motorola smartphone, I tried a Xiaomi from a friend and it wouldn't run either (just stuck at the OTG screen). I've now got a Samsung tablet and it shows an image for a second or two, then just hangs (until restarting the app, at which point it shows a picture again for a second).

Connecting it to a Windows computer it works just fine (with the occasional stutter in the framerate, however), but that's not exactly how I imagined using this.

Yes, I have this problem too, very frustrating!

I have two Android phones, an old Nexus 5x that it works fine on, although it's really slow as the phone is so old. So I went and got a Nokia G21 on Vodafone PAYG especially for the P2 Pro, which is doing exactly this, it works for a couple of seconds and then just freezes. Sometimes it works for longer, but always freezes in the end.

I've written to the support email address for the app, we'll see if I get any response.

Cheers,
Matt

[Fraser]

I would have discussed the phone compatibility issues with Infiray but since producing my review they have not responded to my emails. I appear to have been "Ghosted" Maybe they did not like the review ? A pity as I thought they had some decent products worth discussing on this forum. Their loss and I will not pursue them further.

For information, I have had the P2 camera working fine on the Samsung S5, A6, A8, S9 and Motorola G5

Fraser

[marcosscriven]

I'm found this thread Googling "topdon tc001 tiny1-c" (third result), as I recently bought one and was disappointed with some basic limitations of the app (especially the dynamic colour->temp mapping).

I figured they would likely be generic, and saw a couple of posts suggesting they use a tiny1-c. Plugging it into a Linux box with a 5.19 kernel it shows

Code: [Select]

[Sat Jan 14 16:17:57 2023] usb 1-3: new high-speed USB device number 6 using xhci_hcd
[Sat Jan 14 16:17:57 2023] usb 1-3: New USB device found, idVendor=0bda, idProduct=5830, bcdDevice=11.01
[Sat Jan 14 16:17:57 2023] usb 1-3: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[Sat Jan 14 16:17:57 2023] usb 1-3: Product: USB Camera
[Sat Jan 14 16:17:57 2023] usb 1-3: Manufacturer: Generic
[Sat Jan 14 16:17:57 2023] usb 1-3: SerialNumber: xxxxx [redacted]
[Sat Jan 14 16:17:58 2023] mc: Linux media interface: v0.10
[Sat Jan 14 16:17:58 2023] videodev: Linux video capture interface: v2.00
[Sat Jan 14 16:17:58 2023] usb 1-3: Found UVC 1.00 device USB Camera (0bda:5830)
[Sat Jan 14 16:17:58 2023] input: USB Camera: USB Camera as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/usb1/1-3/1-3:1.0/input/input28
[Sat Jan 14 16:17:58 2023] usbcore: registered new interface driver uvcvideo
Which is a generic realtek camera.

Searching through this post I've seen some talk of using another device with the Topdon software, but not the other way around? I searched Android store for "infiniray" and tried a few without success. One came up with a dialog box in Chinese.

I also searched Github for "infiray" and found this https://github.com/jiusiz/infiray - wondering if that would be compatible, but only mention of device class seems totally unrelated https://github.com/marcosscriven/infiray/blob/main/app/src/main/java/com/jiusiz/infiray/InfiRayActivity.kt#L328

[Fraser]

Apps appear to use the USB PID to determine which cameras they will work with. The Infiray Windows SDK has drivers for several versions of Tiny1 core. Different drivers provide different functionality. The ASIC (rather than PID number) driver provided the greatest number of options for fine tuning the core. Anyone wanting the windows SDK should contact Infiray and not me please.

I have tested the TOPDON APP with my Infiray P2 and it works fine. The TOPDON and P2 both have the same 5830 PID. The UNi-T APP did not work with the P2 PRO even though their 720M/721M camera uses the Tiny1 core.

Fraser

[greynol4]

Has anyone had any luck with the video output via usb?  I can get the raw image or the raw image with the greenscale below it but obviously that's not ideal.  I have the SDK but I'm not a programmer and the documentation isn't very comprehensive.  Right now its happy to stream on motioneye installed on a pi3 but I'd like to get rid of the raw image and be able to use at least a grayscale palette.  I'm thinking that it's going to involve processing the image and then getting that into motioneye instead of motioneye directly.  I'll also mention that this isn't a p2 but a tiny1 core pulled from a sketchy camera but it does support UVC as is and shows as the generic realtek usb cam.

[kat]

yes, I have tried it as an USB Camera.
actually I am planning to create an app for it, because these chinese apps suck... and I could really use the SDK if you have it.

for now I only tested it using the browser's Media api, which is very limited.. From the camera I get a single video stream that produces an image with double the height. It appears to be split in two, second half shows a greeny version of the image. I think it contains thermal data required to render the image with diff palettes. 

[blargg]

Don't do what I did. This isn't suitable for carrying in a pocket, even in its bag, with keys. This happened about a week after I received mine.

The image doesn't seem affected. I've moved it slowly across hard-edged objects parallel to the crack and haven't seen any odd artifacts. I tested blocking the front and found that the lens behind the cover is a small portion of it. So as a repair I put a tiny piece of Scotch tape in the corner over the cracks, to keep them from worsening. It's held up for a few weeks now being used daily.

Next step is to contact the site I ordered from (Pergear) and then Infiray and see if they can send me a new cover piece (I guess it glues in? I've seen the teardown video where there's a washer-looking thing below it). Maybe it just needs a new shell. The card I purchased it with actually includes insurance for accidental damage like this though I'd need a repair estimate. I'm not keen on shipping this off to China to be maybe repaired, maybe damaged.

Just thought I'd offer some warning to be careful with theirs. I'm still LOVING this thing. It's so compact and functional.

[aurel]

It seems there is interest in using the P2 Pro as a USB camera on PC and interpreting the content of the video stream, so I will share the experiments I made after receiving mine.

Basically I played with ffmpeg to extract raw data from the video stream.

The main finding is that the USB UVC device is exporting 2 video streams
- a 256x192 yuyv422 stream that contains a grayscale 8 bits normalized video that is directly exploitable (the 8 bits luminance channel is the temperature data and both chrominance channels are fixed values to give a colorless/grayscale result)
- a 256x384 yuyv422 stream that contains an exact copy of the previous stream in the upper half of the image and a greenish picture in the bottom half. This greenish picture is actually the raw non-normalized sensor values that are actually encoded in gray16le format (just 16 bits per pixel, in one grayscale channel, little-endian).

Examples playing with those video streams on a linux box:

Code: [Select]

# First of, find the device corresponding to your IR camera
v4l2-ctl --list-devices


Code: [Select]

# Check that the normalized stream works fine
ffplay -input_format yuyv422 -video_size 256x192 -i /dev/video4


Code: [Select]

# Look a the combined streams
ffplay -input_format yuyv422 -video_size 256x384 -i /dev/video4


Code: [Select]

# Use ffmpeg to grab the combined stream, crop to keep only the bottom half
# then pipe the raw data to ffplay and reinterpret it as gray16le.
# The resulting picture will be almost uniform gray due to the low range of
# the raw values in the 16 bits dynamic range.
# The raw values in a 0°C to 100°C environment ranges around 19000 to 24000
# (in a 0 to 65535 dynamic range).
ffmpeg -input_format yuyv422 -video_size 256x384 -i /dev/video4 -vf 'crop=h=(ih/2):y=(ih/2)' -pix_fmt yuyv422 -f rawvideo - | ffplay -pixel_format gray16le -video_size 256x192 -f rawvideo -i -


Code: [Select]

# To make the resulting raw stream more useful, you can add a normalization filter
# followed by a pseudocolor filter with typical IR camera colors
ffmpeg -input_format yuyv422 -video_size 256x384 -i /dev/video4 -vf 'crop=h=(ih/2):y=(ih/2)' -pix_fmt yuyv422 -f rawvideo - | ffplay -pixel_format gray16le -video_size 256x192 -f rawvideo -i - -vf 'normalize=smoothing=10, format=pix_fmts=rgb48, pseudocolor=p=inferno'


Code: [Select]

# You can then play with pretty much infinitely long ffmpeg command lines
# For example, you can upscale the video stream, display the min and max raw
# values in the top left corner and add a time graph of the min and max values
# at the bottom
ffmpeg -input_format yuyv422 -video_size 256x384 -i /dev/video4 -vf 'crop=h=(ih/2):y=(ih/2)' -pix_fmt yuyv422 -f rawvideo - | ffplay -pixel_format gray16le -video_size 256x192 -f rawvideo -i - -vf 'signalstats, split [main][secondary]; [main] normalize=smoothing=10, format=pix_fmts=rgb48, pseudocolor=p=inferno, scale=w=2*iw:h=2*ih, drawtext=x=3:y=3:borderw=1:bordercolor=white:fontfile=FreeSerif.ttf:text=MIN\\: %{metadata\\:lavfi.signalstats.YMIN}    MAX\\: %{metadata\\:lavfi.signalstats.YMAX} [thermal]; [secondary] drawgraph=m1=lavfi.signalstats.YMIN:fg1=0xFFFF9040:m2=lavfi.signalstats.YMAX:fg2=0xFF0000FF:bg=0x303030:min=18500:max=24500:slide=scroll:size=512x64 [graph]; [thermal][graph] vstack'



So the raw data from the sensor are very easily accessible. The only missing part is the conversion from raw values to actual temperatures. I don't know if some kind of calibration needs to be applied or if the raw values can be converted directly to temperatures with a simple fixed (linear ?) equation.
In my quick tests I derived the following equation to convert raw to °C but this is only a rough guesstimate: f(x) = (x - 19295) / 51.2857

[kat]

very nice!
Not sure if ffmpeg is good option for extracting frames in real-time, because of performance reasons.

I tried using the "libuvc" library to access the camera, but apparently it does not work on MacOS > 12, because Apple now takes exclusive access of cameras, and apps need to ask for permissions, which is another hassle.
But if there is no need for the extra metadata to generate the thermal image, then it should be possible to do it with the browser media Api + canvas.
For temperature reading, we need the metadata because the colors are not directly mapped to a temperature. That equation needs at least another variable for determining the range, like max temp value

[zenbonzo]

Hello, everyone.
I am a new member but have been following you for a long time.
I have no programming experience.
As an owner of the P2 pro thermal camera I have done a bit of research and try to share here hoping to be helpful. I apologise if there is already known content.
The information is in no particular order:

1) I have installed several android compatible apps. one of them saved here: \Android\data\com.infisense.p2plus\files\Documents two interesting files:
P200163D13398059_nuc_table_high.bin and P200163D13398059_nuc_table_low.bin
see attached files. I added a final .txt just in case Bin isn't allowed.

2) it seems to me that the InfiRay Go App is the only one that not only saves the images but also saves (but I don't know where) the temperature values or the raw values of the entire matrix, because from its gallery, with the "edit" option the image without overlays appears and you can work on it exactly as in the shooting phase. This option on my smartphone does not work with any other compatible app. I find it extremely useful. I have not been able to find where this data is stored - does anyone have a chance to check?

3) Rune Hansen https://discord.gg/R95eer5k has announced its intention to support P2 Pro in the new version of its wonderful software soon!

Thanks for your attention and good work!

[zenbonzo]

addition: I found this on GitHub:
https://github.com/LeoDJ/P2Pro-Viewer/blob/main/P2Pro/P2Pro_cmd.py
and this one:
https://github.com/jiusiz/infiray
Ciao!

[zenbonzo]

and finally: the very basic windows program of the TOPDON TC001 'clone' thermal imaging camera downloadable here:
https://www.topdon.com/pages/pro-down?fuzzy=TC001 works with P2 Pro (by installing provided drivers).
It saves Temp Matrices in a raw format (in the TempMatrix directory of the program dir (I attach one).
Does anyone have any suggestions on how to process it?
Thanks!

[LeoDJ]

addition: I found this on GitHub:
https://github.com/LeoDJ/P2Pro-Viewer/blob/main/P2Pro/P2Pro_cmd.py

Hi, I'm the author of this GitHub repo.

I've already found out a lot about the camera. (e.g. video format, temperature conversion and the out-of-band communication and format of the USB vendor requests, like setting the color palettes, shutter control, high temperature mode, etc)
Some of it has also already been found out by others in this thread, as I've just discovered.

I plan on publishing a write-up of everything I've found later on too, but for now I'm focussing on getting a basic Python implementation working.

Here's also a Mastodon thread about my progress, if you want to keep up-to-date in the meantime: https://chaos.social/@LeoDJ/109633033381602083

I don't know if some kind of calibration needs to be applied or if the raw values can be converted directly to temperatures with a simple fixed (linear ?) equation.
In my quick tests I derived the following equation to convert raw to °C but this is only a rough guesstimate: f(x) = (x - 19295) / 51.2857

According to my reverse engineering the lower video frame contains the temperature data directly in Kelvin. It's 14-bit, shifted into the most significant bits, multiplied by a factor of 16.
So to get from the value from the camera to a temperature in °C, the formula is:

Code: [Select]

t = ((x >> 2) / 16) - 273.15
or simpler:

Code: [Select]

t = x / 64 - 273.15

[zenbonzo]

Tank you for your reply and your great work! Any advice on how to obtain simply a matrice with temperature values at every pixel of a screenshot? E.g. pressing a key... Whith a minimum of code... ?

[bostwickenator]

So to get from the value from the camera to a temperature in °C, the formula is:

Code: [Select]

t = ((x >> 2) / 16) - 273.15
or simpler:

Code: [Select]

t = x / 64 - 273.15

Nice work on figuring out the conversion for the RAW stream! Those will be very useful for me.

sidenote: I gotta say it's a bit frustrating reading this thread seeing everyone figure out if it's a UVC camera and what it works with when I documented this in my review in 2021 on this forum. I know the search tool here isn't the best but give it a good check before doing things the hard way there is an absolute wealth of information on here.

[Spenoza]

Hi. I need the advice of experienced thermal imager users. Because of the cheap price, I bought myself a Victor 328B thermal imager. As far as I understand, its filling is similar to the P2 PRO. In the evening, I indulged them in the P2 PRO app from Infraray. At first glance, it worked fine. But the next day I noticed that it began to show the wrong temperature. Moreover, in the application from Infraray it has a room temperature of hundreds of degrees, and in the application from the manufacturer a negative temperature at a real temperature of about 20 degrees. Judging by the sound, calibration is performed every 5-10 seconds. At the same time, it seemed to me that after warming up, calibration becomes much less frequent. Do you have any advice on this situation?

[Fraser]

In such a situation I would delete both Apps (Victor and Infiray) and reinstall, just the Victor App. Test the camera again for correct operation. It is unlikely that the Infiray App will damage your camera, but it is possible for an App to corrupt another Apps driver.

A high temperature reading error was a bug in one version of the a Infiray App whilst it was set to the high temperature range. That bug was fixed in a later release though.

FFC flag events decrease in frequency once the cameras microbolometer has stabilised at its nominal operating temperature.

Fraser

[rop12770]

Well, after testing a Seek PRO and an amazingly Qianli, I decided to buy a P2 PRO wih macro Lens.
For 200€, I think this will be perfect for what I need/want!

[Spenoza]

Unfortunately, reinstalling the programs did not help. And these thermal imagers can be connected to Windows computers?

[greynol4]

yes, I have tried it as an USB Camera.
actually I am planning to create an app for it, because these chinese apps suck... and I could really use the SDK if you have it.

for now I only tested it using the browser's Media api, which is very limited.. From the camera I get a single video stream that produces an image with double the height. It appears to be split in two, second half shows a greeny version of the image. I think it contains thermal data required to render the image with diff palettes.

I have the SDK, I'll send you a pm.  It has sample code and libraries for linux and windows.  I couldn't get the linux sample to compile but I'm assuming that's my fault.  The windows sample works.  There are also ARM android libraries.  In the meantime, I'm going to play with the ffmpeg method.

[greynol4]

It seems there is interest in using the P2 Pro as a USB camera on PC and interpreting the content of the video stream, so I will share the experiments I made after receiving mine.

Basically I played with ffmpeg to extract raw data from the video stream.

The main finding is that the USB UVC device is exporting 2 video streams
- a 256x192 yuyv422 stream that contains a grayscale 8 bits normalized video that is directly exploitable (the 8 bits luminance channel is the temperature data and both chrominance channels are fixed values to give a colorless/grayscale result)
- a 256x384 yuyv422 stream that contains an exact copy of the previous stream in the upper half of the image and a greenish picture in the bottom half. This greenish picture is actually the raw non-normalized sensor values that are actually encoded in gray16le format (just 16 bits per pixel, in one grayscale channel, little-endian).

Examples playing with those video streams on a linux box:

Code: [Select]

# First of, find the device corresponding to your IR camera
v4l2-ctl --list-devices


Code: [Select]

# Check that the normalized stream works fine
ffplay -input_format yuyv422 -video_size 256x192 -i /dev/video4


Code: [Select]

# Look a the combined streams
ffplay -input_format yuyv422 -video_size 256x384 -i /dev/video4


Code: [Select]

# Use ffmpeg to grab the combined stream, crop to keep only the bottom half
# then pipe the raw data to ffplay and reinterpret it as gray16le.
# The resulting picture will be almost uniform gray due to the low range of
# the raw values in the 16 bits dynamic range.
# The raw values in a 0°C to 100°C environment ranges around 19000 to 24000
# (in a 0 to 65535 dynamic range).
ffmpeg -input_format yuyv422 -video_size 256x384 -i /dev/video4 -vf 'crop=h=(ih/2):y=(ih/2)' -pix_fmt yuyv422 -f rawvideo - | ffplay -pixel_format gray16le -video_size 256x192 -f rawvideo -i -


Code: [Select]

# To make the resulting raw stream more useful, you can add a normalization filter
# followed by a pseudocolor filter with typical IR camera colors
ffmpeg -input_format yuyv422 -video_size 256x384 -i /dev/video4 -vf 'crop=h=(ih/2):y=(ih/2)' -pix_fmt yuyv422 -f rawvideo - | ffplay -pixel_format gray16le -video_size 256x192 -f rawvideo -i - -vf 'normalize=smoothing=10, format=pix_fmts=rgb48, pseudocolor=p=inferno'


Code: [Select]

# You can then play with pretty much infinitely long ffmpeg command lines
# For example, you can upscale the video stream, display the min and max raw
# values in the top left corner and add a time graph of the min and max values
# at the bottom
ffmpeg -input_format yuyv422 -video_size 256x384 -i /dev/video4 -vf 'crop=h=(ih/2):y=(ih/2)' -pix_fmt yuyv422 -f rawvideo - | ffplay -pixel_format gray16le -video_size 256x192 -f rawvideo -i - -vf 'signalstats, split [main][secondary]; [main] normalize=smoothing=10, format=pix_fmts=rgb48, pseudocolor=p=inferno, scale=w=2*iw:h=2*ih, drawtext=x=3:y=3:borderw=1:bordercolor=white:fontfile=FreeSerif.ttf:text=MIN\\: %{metadata\\:lavfi.signalstats.YMIN}    MAX\\: %{metadata\\:lavfi.signalstats.YMAX} [thermal]; [secondary] drawgraph=m1=lavfi.signalstats.YMIN:fg1=0xFFFF9040:m2=lavfi.signalstats.YMAX:fg2=0xFF0000FF:bg=0x303030:min=18500:max=24500:slide=scroll:size=512x64 [graph]; [thermal][graph] vstack'



So the raw data from the sensor are very easily accessible. The only missing part is the conversion from raw values to actual temperatures. I don't know if some kind of calibration needs to be applied or if the raw values can be converted directly to temperatures with a simple fixed (linear ?) equation.
In my quick tests I derived the following equation to convert raw to °C but this is only a rough guesstimate: f(x) = (x - 19295) / 51.2857

There's several documents in the sdk pertaining to calibration and sensor data but the translations aren't great.  They might give you some insight though.