Flir One Android App with full Lepton sensor resolution 160x120

[Ben321]

It's 8 bytes in front of where "FocusDistance" is stored in the fff file. The precise location may differ depending on the camera (I assume newer cameras have more metadata fields for MSX calibration etc.) but in my example I located where FocusDistance was using exiftool

and then found where the framerate was stored


I'm pretty sure that the exact offset will always be in the same place in the FFF provided the images are coming from the same camera.

But how does that help with SEQ files? Wouldn't the frame rate have to be provided outside of any of the internal FFF files? If it's 8 bytes before the FocusDistance in an FFF file, that's still within the FFF file, so it couldn't define a global framerate for the SEQ file. At most, it would be able to tell a player the duration of a single frame.

[encryptededdy]

Honestly, I have no idea regarding how FLIR Tools actually reads off the framerate from the file, but I assume it just reads it out of the first file in the sequence.

Either way, it certainly does appear to work.

[tomas123]

see here for the original Flir FFF header definition ( with 0x464 "Image frequency")

I posted it in October 08, 2015
http://u88.n24.queensu.ca/exiftool/forum/index.php/topic,6763.msg33860.html#msg33860

I marked

Code: [Select]

0x464 *  unsigned short imageFreq;         //!< Image frequency, defines the nominal
                                 //!    image frequency in Hz
because I rechecked some times ago in eevblog forum, that the frame rate is 8 Byte behind FocusDistance.

[Ben321]

Anybody yet reverse engineer the SEQ format, and figure out what fields it uses in its main header?

[Redshift1340]

Georg request me for assistance for his Thermal Camera App and this the first proof of concept for Super Resolution.
Georg still has no F1 G2 camera 

For this proof of concept we wrote a small python script, optimized for low CPU performance of Android devices (or PcDuino3  ).

It's a classical multi-frame super-resolution with
- registration (find the shifts)
- average (stacking)
- sharpen

For the registration I tested several methods of motion analysis with opencv library.
http://docs.opencv.org/2.4/modules/video/doc/motion_analysis_and_object_tracking.html
estimateRigidTransform make a great job (estimate rotations, translations and scaling)

A problem for stacking of images with large shifts or rotations is the great distortion of the F1 G2 lens.
Therefore I reduced the SR processing in the video above for scenes with minor shifts
(less than 4 pixel/frame => 36 pixel/second, with 56° hor. FOV -> 36/160*56 = 12° per second movement) 
... and this works  fine

Tomas123, are you or Georg planning to write a version of that F1 G2 thermal camera app for those of us poor saps who have the FLIR One for iOS?  I'm dying for somebody to create an app like that for my version of the F1 G2

[in.Vitro]

who have the FLIR One for iOS?  I'm dying for somebody to create an app like that for my version of the F1 G2

Oh yes, PLEASE DO THAT!

[joe-c]

Hey, in which state is the App for Android?
i don't found a "Fone Ultimate" in play store.

[NathanFowler]

who have the FLIR One for iOS?  I'm dying for somebody to create an app like that for my version of the F1 G2

Oh yes, PLEASE DO THAT!

100% this!

[gansgar]

Hello community

I released today the advanced version of my Thermal Camera app . The new app is called Thermal Camera+ for Flir One.

It has some new and long awaited features like multi-frame super resolution algorithm and some new methods for picture saving.
The new method supports the real color image and the MSX and without MSX thermal images.
All pictures can then also be managed by the new in-app gallery.

It also has an adjust for the MSX offset and a manual / automatic shutter mode (long click on the shutter icon).

- George



Multi-frame super resolution example:

Without super resolution, that means the native Flir One resolution:


And with the new multi-frame super resolution algorithm:

[frenky]

Great work with the super-resolution.

[gansgar]

Thank you. It was some hard work to get it running. I had there luckly a ton of support by tomas123, who at the end made the stable sr algorithm that is currently in the app.

[Fraser]

George,

Really great work. My thanks to you and Tomas123. The super resolution mode will be interesting to play with.

Thank you for your hard work on this project.

Fraser

[Neverther]

I was going to ask if the saturation problem had been fixed on the app, but then tried to test it.

Lesson 101, how to get paying customers:

Propably not...

Does the same if I try launching the app with no camera connected.
Sent crash report.

[tomas123]

A unintentional crash of the free app.
Flir changed the SDK to 1.1.4 and therefore we got some new troubles.
Georg will fix it for the free app.

Edit: crash is fixed

@Neverther
Please describe your "saturation problem"

[Neverther]

My post in this thread on 01-05-2016
Tested it now and it seems to be fixed altough I do not have anything too hot to test it with at the moment.

[tomas123]

the flir one specs give us max 120°C

Scene temperature range: -4°F to 248°F (-20° to 120°C)

Lepton 3 datasheet:

Intrascene Range Minimum and maximum scene temperature 0 K to >400 K (126°C)

Georgs app is not limited to 120°C, therefore you get temperature values until 200°C.
But this values over 120°C are absolute inaccurate (not calibrated) and you get a odd clipping (NaN = not a number) at around 200°C.

[gansgar]

I assume because you have an overflow error. The values of the camera have only 2^15 (~32000) possibilities. After that comes -32000, which isn't a valid value. For example the temperature calculation uses a log to satisfy plancks law and as we all know: log(x), where x<0 is equal to Not A Number (NAN).

That is also shown in the app. The minimum temperature is NaN and if you limit the minimum, you can see that the to hot spots are actually registered as very cold.

[Neverther]

Yep, but at the time the flir msx mode could cope with it being hot and not break the whole scale (like in the attached pictures).

[ChunkyPastaSauce]

Bought the + version, thanks for the app.

Some notes

For MSX alignment, one swipes in the opposite axis of the MSX shift. I think it would be more intuitive if the swipe was in the direction of the shift (or at least axis)

The super resolution icon freeze in whatever state it was in, when switching to MSX

Also, it would be cool if one could adjust the MSX strength (or maybe a "super" MSX using the phones camera for higher res, but realize may not be simple)

[gansgar]

Those are valid points. I'll fix them.

The last point is really not worth the effort.
I use the MSX of the Flir SDK. This means that the calculations for MSX are not done by my algorithms also. But it also means that it uses the real color camera on the Flir One, which only supports VGA resolution. If I would like to introduce a "super MSX", I would be needed to do by myself a dewarp of the image, finding a formula to calculate the offset between the Thermal Image and the Real Color one. Till here it isn't even considered that the user would need to input the offset between the thermal camera and your phones camera.
All in all: It is possible, but definitely not worth the effort.

[ChunkyPastaSauce]

Sounds good, and thanks for the app

[gansgar]

Thank you. It was a fun thing to do and I learned a lot through it (mostly how to organize big projects).

[Fraser]

I promised I would pay for this program and I just paid for the + version. I will also be installing it on my other two phones so that makes three upgrades sold to me

Thanks again to you both for all the hard work

Fraser

[gansgar]

Thank you for the support.

 

 George

[tomas123]

George as 17 year-old student is pleased with the additional pocket money.
Please don't forget to vote the app in the play store


As I posted above, I wrote the SR algorithmus for Georg.
see https://www.eevblog.com/forum/thermal-imaging/flir-one-android-app-with-full-lepton-sensor-resolution/msg929260/#msg929260

The image enhancement with multiframe super resolution is most visible in taken (still) images.
Our brain make an own superresolution (stacking) if our eyes "record" a 9 frames/second live view, therefore the enhancement is not so clearly visible in the "live view".

Unfortunately the SR don't improve the thermal sensitivity, but it works great on fine structures.
There are some SR parameters inside the algorithm, which are currently fixed values to simplify the use of the app (number of detected edges, max. offset of following images, count of stacked images, exponential moving average etc.).

I would be glad about comments on the SR ...