Products > Thermal Imaging

Infiray and their P2 Pro - discussion

<< < (45/48) > >>

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:

--- Quote from: kat on January 26, 2023, 10:45:58 pm ---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.

--- End quote ---

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:

--- Quote from: aurel on January 28, 2023, 12:29:05 am ---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: ---# First of, find the device corresponding to your IR camera
v4l2-ctl --list-devices

--- End code ---


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

--- End code ---




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

--- End code ---




--- Code: ---# 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 -

--- End code ---




--- Code: ---# 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'

--- End code ---




--- Code: ---# 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'

--- End code ---



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

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page