2014: the year of thermal imaging?Clearly - Flir is probably the only contender for this year's Christmas gadget market, but by next year it could be a bloodbath at the low end though.
Hey FLIR have been giving thermal cameras away at press conferences !Very cute - maybe start emailing a few journos to make an offer...!
Take a look here:
http://www.sourcesecurity.com/news/articles/co-9756-ga-co-5188-ga-sb.14647.html (http://www.sourcesecurity.com/news/articles/co-9756-ga-co-5188-ga-sb.14647.html)
A small Lepton based demo camera !
Clearly - Flir is probably the only contender for this year's Christmas gadget market, but by next year it could be a bloodbath at the low end though.
They've put new video on YT:resolution & framerate on that looks somewhat higher than what the product is likely to have - I bet they used a high-end Flir for that video
https://www.youtube.com/watch?v=lRjOsdtZnL4 (https://www.youtube.com/watch?v=lRjOsdtZnL4)
They've put new video on YT:resolution & framerate on that looks somewhat higher than what the product is likely to have - I bet they used a high-end Flir for that video
https://www.youtube.com/watch?v=lRjOsdtZnL4 (https://www.youtube.com/watch?v=lRjOsdtZnL4)
Really disappointing that they don't ship to Europe. |O
(I tried to order trough shipito.com but order on thermal.com didn't go trough because my credit card address was different from shipping address...)
Thank for your order! Due to the extremely high demand for our products, we are currently experiencing a 5-7 business delay in the shipment of your order. In order to minimize transit times, items may ship separately from multiple locations, and all shipped items may not be reflected on this confirmation.
however it is a pitty it works only under Android?
The other interesting aspect is at what point will the US manufacturers manage to persuade their leaders that restrictions on higher framerates are harming business more than they are protecting anyone from anything.
Applications like firefighting need a decent framerate, and once the kit becomes sufficiently small and cheap it will be impractical to control.
Almost certainly a bogus listing
Totally true. I found someone selling on ALI Express last week - "high res" 640x480 sensor assembly, 70FPS, "only" :) $900 each. 10 were available.
I am not familiar with Chinese market. Would they create bogus listing just to check the demand? Does it mean they pretty much ready to start shipping or may not even close to it? This one looks like a real deal to me for example: http://hbjir.en.alibaba.com/product/618597547-214483688/Infrared_IR_Thermal_imaging_Camera_Core_Module.html (http://hbjir.en.alibaba.com/product/618597547-214483688/Infrared_IR_Thermal_imaging_Camera_Core_Module.html) or http://hbjir.en.alibaba.com/product/637449470-214483688/zoom_camera_module.html (http://hbjir.en.alibaba.com/product/637449470-214483688/zoom_camera_module.html)Almost certainly a bogus listing
Totally true. I found someone selling on ALI Express last week - "high res" 640x480 sensor assembly, 70FPS, "only" :) $900 each. 10 were available.
The other interesting aspect is at what point will the US manufacturers manage to persuade their leaders that restrictions on higher framerates are harming business more than they are protecting anyone from anything.
Applications like firefighting need a decent framerate, and once the kit becomes sufficiently small and cheap it will be impractical to control.
Totally true. I found someone selling on ALI Express last week - "high res" 640x480 sensor assembly, 70FPS, "only" :) $900 each. 10 were available.
384×288 sensors at 50FPS are easily available - shipping worldwide. I am wondering if these can be overclocked to 60FPS. I searched last year - there were none for sell with these frame rates. I can only imagine what will be available next year! I think Chinese company that makes/sells them is called "JIR" ... .
http://www.alibaba.com/product-detail/M700-thermal-image-sensor-cheap-thermal_1899090531.html?s=p (http://www.alibaba.com/product-detail/M700-thermal-image-sensor-cheap-thermal_1899090531.html?s=p)
206x156 array, it's real, and only $199. This one could be a game changer.Probably it does not have any reliable calibration between frames like Flir, but is looks quite compact for some apps, however it is a pitty it works only under Android?
"Key features include a KMS (Kernel Mode Setting) enabled Linux kernel 3.10.x LTS, Wi-Fi support, battery status, V4l2 camera support, G-sensor, bluetooth, suspend, resume, audio though ALSA, and mouse wheel support."
however it is a pitty it works only under Android?IPhone as well, also $199.
About shipping of Seek Thermal module. This is from facebook: https://www.facebook.com/pages/Seek-Thermal/628554970550411 (https://www.facebook.com/pages/Seek-Thermal/628554970550411)
[user]when are you guys shipping?
[Seek Thermal] Hi Dat, The cameras will ship when the apps go live in their respective app stores. We estimate that that will be 1-2 weeks for Android and shortly thereafter for iOS.
so that means any shipping option other then the standard isnt worth it :) unless you really want it the next day after they start shipping.
They do have an IPhone version as well, same price $199 and it should work even with the new IPhones not stuck to the 5s like the Flir module.I'd like to use this thermal camera just like other cameras under Linux or better Linux based wiki: Robot Operating System (ROS) (http://en.wikipedia.org/wiki/Robot_Operating_System), so it is interesting if this Android version could be detected under Linux and if I coud be able to catch its output frames using OpenCV like in video below (FLIR with ROS module) it would be nice, while I do not like even Android, while it is not fully open source OS.
anyways, looks like their noise reduction isn't as advanced as the Flir (One) Lepton Mike was showing off.I think It might depend what that app does inside software and what alghorithms were used, while Flir might use diffrent ones and maybe has much better hardware with black body built in calibration between frames.
"The phone or tablet must have support for USB On The Go, however, or the camera dongle won't work"Lets see what guys from Seek Thermal support will say about running this thing under Linux or ROS control, while FLIR have such support as we could see in video above ;)
Lets see what guys from Seek Thermal support will say about running this thing under Linux or ROS control, while FLIR have such support as we could see in video above ;)I suspect that to minimise costs, Seek will rely a lot more heavily on software in the host to do processing than the Flir One does, but as it uses USB, it should at least be possible to extract the raw sensor data.
I would suggest you sign up for the Seek developer SDK, I ordered the camera and signed up for SDK access but no news on either.the software they've shown so far seems to going out of its way to avoid looking like Flir's MSX. I'm sure people will write apps to remedy that...!
I know they are waiting for the google app store to have the app before they ship and the ETA is 2 weeks. I would think the SDK will follow later.
I have a TrimSlice with a Tegra 2 that can run both Android and different flavors of Linux, including L4T (Linux for Tegra) I might have a play if I receive the SDK.
But a Jetson K1 devkit might be better (Linux only right now) because it has 192 CUDA cores that can be used for OpenCV.
But a Jetson K1 devkit might be better (Linux only right now) because it has 192 CUDA cores that can be used for OpenCV.It looks really nity and I can use this thing in one of the projects even without thermal camera, while with its CUDA accelearted OpenCV I will be able probably detect objects in the scene using cheap classic camera and make movements detections in real time :-+
iPhone 6 isn’t simply bigger — it’s better in every way. Larger, yet dramatically thinner. More powerful, but remarkably power efficient.It looks like crappy toy for childrens to play old fashion tetris ;D
That is what those Chinese sensors are good for IMHO - see through Oculus Rift kind of gadget. If sensor can handle 60FPS - there will be enough frame rate to switch between left/right eye and enabling stereo vision. I am not sure if it is possible to switch between two lenses using some kind of liquid Crystal shutter device,Nope
but I assume same technology that used in 3D glasses can be used here. I think thermal vision sensors are still too big and heavy to fit two in one headset.No, just rather expensive
As many here already pointed out if all components are sourced in China there is no need to worry about stupid export restrictions - ship anywhere you want around the globe.I'd be surprised if China didn't have similar restrictions
Well, Nvidia does it pretty well. I have them at work. http://en.wikipedia.org/wiki/Active_shutter_3D_system (http://en.wikipedia.org/wiki/Active_shutter_3D_system) so why not do it in reverse ?That is what those Chinese sensors are good for IMHO - see through Oculus Rift kind of gadget. If sensor can handle 60FPS - there will be enough frame rate to switch between left/right eye and enabling stereo vision. I am not sure if it is possible to switch between two lenses using some kind of liquid Crystal shutter device,Nope
Well, Nvidia does it pretty well. I have them at work. http://en.wikipedia.org/wiki/Active_shutter_3D_system (http://en.wikipedia.org/wiki/Active_shutter_3D_system) so why not do it in reverse ?That is what those Chinese sensors are good for IMHO - see through Oculus Rift kind of gadget. If sensor can handle 60FPS - there will be enough frame rate to switch between left/right eye and enabling stereo vision. I am not sure if it is possible to switch between two lenses using some kind of liquid Crystal shutter device,Nope
Good point, I did not think of that. So common liquid crystal shutter will be transparent to IR? I cannot seem to find good source in this. What about DMD? I mean Digital Micro Mirror Devices? (http://www.ti.com/lsds/ti/analog/dlp/overview.page (http://www.ti.com/lsds/ti/analog/dlp/overview.page) Maybe that is the solution for switching between lenses?
Good point, I did not think of that. So common liquid crystal shutter will be transparent to IR? I cannot seem to find good source in this. What about DMD? I mean Digital Micro Mirror Devices? (http://www.ti.com/lsds/ti/analog/dlp/overview.page (http://www.ti.com/lsds/ti/analog/dlp/overview.page) Maybe that is the solution for switching between lenses?
Well, Nvidia does it pretty well. I have them at work. http://en.wikipedia.org/wiki/Active_shutter_3D_system (http://en.wikipedia.org/wiki/Active_shutter_3D_system) so why not do it in reverse ?I will never ever wear active shutter 3D glasses, while only wiki: Polarized 3D system (http://en.wikipedia.org/wiki/Polarized_3D_system) makes sense in my opinion.
It makes a constant clicking noise as it runs. That’s the sound of the thermal imager automatically recalibrating itself
Ordered another just now, order # 309X.
Six days ago my last order was 79X.
The seem so be some progress...
Twitter:
we hope to have approval for the app store by EOD today and our first shipments are leaving the factory right now!
---
We will likely be taking orders in US$ from the EU by next week!
---
BIG DAY! The first Seek thermal Android cameras are on the dock and ready to ship to customers! #seetheheat #thermal
---
https://twitter.com/search?f=realtime&q=seekthermal&src=typd
Link to app:
https://play.google.com/store/apps/details?id=com.tyriansystems.SeekThermal
It doesn't support my Nvidia Shield, but it does support my wife's S4, So I guess she will have to go to work without her phone :)
I ordered one this morning and just installed the app on my HTC DNA phone. I ran it and it is asking me for my login info. Gave it the same thing I put in the web site and it is not working! Let's hope they fix this.
Link to app:
https://play.google.com/store/apps/details?id=com.tyriansystems.SeekThermal (https://play.google.com/store/apps/details?id=com.tyriansystems.SeekThermal)
It doesn't support my Nvidia Shield, but it does support my wife's S4, So I guess she will have to go to work without her phone :)
Just tried installing and it says "This app is not available in your country".
I tried using Market Helper to make it think it was in US but same thing.
I know nothing about Android - is it be possible for someone in the US to download it to a file that I could install outside of the Google Play store?
WARN: iAP: ERROR: Halting at ms
,... Link Init
Unable to parse iAP Packet - Invalid packet length (expected at least 9 bytes)
Raw Packet - Unable to parse iAP Packet - Invalid Start-Of-Packet (expected 0xFF 0x5A)
Ctrl= SYN +ACK +EAK +RST +SLP PAN= SID= (Invalid)
Unable to parse iAP Packet Data Payload - Invalid payload size
Payload Checksum= RequestAuthenticationCertificate RequestAuthenticationChallengeResponse AuthenticationResponse AuthenticationFailed AuthenticationSucceeded StartIdentification IdentificationInformation IdentificationAccepted IdentificationRejected CancelIdentification IdentificationInformationUpdate StartExternalAcessoryProtocolSession StopExternalAcessoryProtocolSession StartPowerUpdates PowerUpdate StopPowerUpdates Unexpected session parameter size - Expected at least 4 bytes
ParamID= Len= Poorly structured session packet - Unable to continue parsing.
PowerMgrState_SlowSystemInitialization - PowerMgrState_EnumeratingUSB - PowerMgrState_ResponsiveSleep - PowerMgrState_SleepMode - PowerMgrState_RunMode - Performing system reset
WDT Warning
WDT Tiimeout
Setting up delayed event
ÿU îBad packet header
com.thermal.SeekThermal Target Platform: Received iAP Link Init echo from host. Platform determined to be iOS.
Invalid packet
ÿUÿÿÿÿÿÿÿÿÿÿÿÿëTarget Platform: iAP IC not responding. Guessing Windows.
Cmd= (Unknown request)
Request handler returned with error
Request has no handler
USBD Suspend Event
USBD Resume Event
USBD Configure Event
USBD Reset Event
Implementation Error - Not enough memory for USB stack
Reseting EP1 IN
Implementation Error - Invalid queue count
Sending queued IN request
iAP To Dev
IN request has timed out - Resetting EP1 IN
Implementation Error - USBD failure
Waiting for packet ACK
iAP To Acc
Previous ExIAP packet was ACK'd
Some other packet was ACK'd!
iAP Acc - INVALID! Ignoring
USB OUT data received - More expected
Pending USB OUT request
BytesQueued= Ran out of buffer queue items
Buffering IN request PSN= Invalid request size - Sending error response - Unknown request Implementation Error - SUBI_LastError not set by VendorClass_HandleInRequest
Implementation Error - IN Request handler failed but there's no way to inform the host. Stalling EP (may cause app lock-up).
Implementation Error - SUBI_LastError not set by VendorClass_HandleOutRequest
Implementation Error - No IN or OUT request handler for request
` ÿ 8œ *** iAP Packet To Accessory (Pending) ***
USB OUT data received (Pending) - More expected
S1€Ý ·JùäÅ”¾ÔInvalid image processing mode
Cannot toggle shutter when in RUN and CHOP1/CHOP2/CSATIME
Invalid parameter
Invalid parameter 0
Invalid parameter 1
Invalid parameter 2
GetFirmwareInfo index= Invalid firmware information index
Invalid data size
Invalid attempt to dynamically switch target platform
Invalid data page
Canceling queued IN requests. Previous image was likely interrupted. IMPLEMENTATION ERROR!
Invalid memory region
Invalid backdoor key
Erasing flash at Flash erase failed
Programming flash at Flash write failed
Flash program validation failure
Updating RDAC in RAM
Updating VDAC in RAM
Updating CMD in RAM
Updating factory settings
Done
Invalid shutter polarity
Erasing flash sector at Programming flash sector at Flash write failure
Done Invalid checksum
Writing memory region - New Image= Invalid image
Received image is a valid firmware image
Flash erase failure
Programming firmware image
Image programming verified
Erasing image select flash sector at Writing new image select flash sector
Image select flash write verified
Programming image select flash sector
Invalid image size
Canceling queued IN requests. IMPLEMENTATION ERROR!
Request does not have a defined IN EP action handler
Request sent during FW init
), Time= Request not served in SLEEP mode
Request not served in RUN mode
Dir=IN, Req= ( does not have a defined OUT EP action handler
Dir=OUT, Req= Ignoring request to non-zero interface
Target Platform: Received vendor class request. Guessing Windows.
GetErrorCode GetChipID ToggleShutter SetShutterPolarity GetShutterPolarity SetBITDataFeatures GetBITData SetOperationMode GetOperationMode SetIPMode GetIPMode SetDataPage GetDataPage SetCurrentCmdFeatures SetCurrentCmd GetCurrentCmd SetDefaultCmdFeatures SetFeaturedFlashData GetDefaultCmd SetVDACFeatures GetVDAC SetRDACFeatures SetRDAC GetRDAC GetFirmwareInfo GetFeaturedFirmwareData SetFeaturedFirmwareData CompleteMemoryUpgrade BeginFirmwareUpgrade ImageData TargetPlatform SetFirmwareInfoFeatures SetFactorySettingsFeatures GetFeaturedData ResetDevice SetRamDataFeatures ---| HardFault |---
Time: [Stack Frame]
R0= R1= R2= R3= R12= LR= PC= PSR= [FSR/FAR]
CFSR= HFSR= DFSR= AFSR= [Misc]
MMFAR= BFAR= LR/EXC_RETURN= Implementation Error
StartStreaming
ResetState
StopStreaming
Processing is not keeping up with data TX. Buffer overrun is imminent.
Invalid frame header: Sync Lost: Restarting sensor interface
Unexpected frame index number. Expected but got Inconsistent Chip ID
6nStarting sensor comm check
Sensor comm check complete
Initializing USB system
Waiting for USB enumeration on Port 0...
BETA UNIT Canceling all queued USB requests
Reseting all OUT and IN endpoints
Entering SLEEP
Entering RUN mode
Sensor is not responding
USB connected
USB connection removed
Seek Thermal PIR206 Firmware (RELEASE-IMAGE)
------------------------------------
Target Platform: Guessing IOS
$ @ @ ` ¦ À Ã à à @@ BB bb ‚‚ ¢¢ ÂÂ ââ ""
## i%ÿÿÐè Thermal Camera LW-AAA Seek Thermal, Inc. ABC123456789 1.0.0.0
99.28
® ®ê ® d ( iAP2 -
com.thermal.pir206.1 ( com.thermal.SeekThermal en
en S e e k T h e r m a l ,P I R 2 0 6 T h e r m a l C a m e r a i A P I n t e r f a c e *c o m . t h e r m a l . p i r 2 0 6 . 1
To be honest I did send mike a pm with the link one hour earlier than your post but chickened out making it public.
Seems like the tryansystems folders are the most interesting ones :)
Possible data format samples?
Link to app:I'm not Nvidia Shield user yet, but found something like this and it looks like in the case of ethernet adapter connection order matters?
https://play.google.com/store/apps/details?id=com.tyriansystems.SeekThermal (https://play.google.com/store/apps/details?id=com.tyriansystems.SeekThermal)
It doesn't support my Nvidia Shield, but it does support my wife's S4, So I guess she will have to go to work without her phone :)
"Plug in the Charging Cable first (the controller brick and cable that came with your SHIELD are recommended).Maybe something similar with this "Shit Thermal" :palm:
Then plug in the USB to Ethernet Adapter"
Just tried installing and it says "This app is not available in your country".I do not know how this Google Play works but maybe they detect someones IP WHEN you download app and modify somehow this apk on the fly? So they let you download this, but then during instalation they display this stupid country message?
I know nothing about Android - is it be possible for someone in the US to download it to a file that I could install outside of the Google Play store?For example this VPN http://www.strongvpn.com/ (http://www.strongvpn.com/) can teleport you to US with speed of light easy :-DD
I fired up VisiQuest (signal processing software) and imported the raw data as unsigned short
156 width and 206 height, then equalized the image and scale it by 3 to make it 3 times bigger
This is 000098.data 3 times bigger than it is.
The thing is that 156 x 206 x 2 bytes is 64272 bytes, and the file is 64,896 bytes So there are an extra 624 bytes there, so an extra 3 rows of data (159x206?) but it seems there are some markers within the data.
To be honest I did send mike a pm with the link one hour earlier than your post but chickened out making it public.Thanks - installed OK after second attempt!
Seems like the tryansystems folders are the most interesting ones :)
So the image format is 208 by 156 unsigned short (2 bytes per pixel)CRC perhaps.
There are 2 extra pixels that are not part of the sensor, here is image
This is the negative of the one above
(http://www.miguelvp.com/ForMike/Animation2.gif)
Thanks. Figured it out after posting that message :). Should have realized they were using a third-party ecommerce system.I ordered one this morning and just installed the app on my HTC DNA phone. I ran it and it is asking me for my login info. Gave it the same thing I put in the web site and it is not working! Let's hope they fix this.
Your account associated with your purchase is not the one associated with the application. You have to register.
I'm not sure this is a thermal image, I should invert it, can the water reflect heat?Why not to use oryginal app and grab those thermal images than compare with raw data?
BTW: This movie is from images catched at night or with day light present?Probably daylight due to reflection from water, though could be reflection from clouds
OK, but are you talking about those simulation raw data from this folder (Linux unzip extracts easy everything of course >:D)BTW: This movie is from images catched at night or with day light present?Probably daylight due to reflection from water, though could be reflection from clouds
$ ./seek_thermal_v1.0.0.apk/com/tyriansystems/Seekware/simulation/rawor you captured I mean used this thermal camera and working on data obtained from real world?
libSeekware.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not strippedThere are two versions of libSeekware.so in folders: ./seek_thermal_v1.0.0.apk/lib/armeabi and ./seek_thermal_v1.0.0.apk/lib/armeabi-v7a .
$ cat libSeekware.so |bin2hex >armeabi_libSeekware.so.txtLUT calls are defined there to native calls from Java
.plt:00007088 ; File Name : C:\Users\Boris\Desktop\seek_thermal\lib\armeabi-v7a\libSeekware.so
.plt:00007088 ; Format : ELF for ARM (Shared object)
.plt:00007088 ; Needed Library 'libstdc++.so'
.plt:00007088 ; Needed Library 'libm.so'
.plt:00007088 ; Needed Library 'libc.so'
.plt:00007088 ; Needed Library 'libdl.so'
.plt:00007088 ; Shared Name 'libSeekware.so'
.plt:00007088 ;
.plt:00007088 ; EABI version: 5
.plt:00007088 ;
.plt:00007088 ; Source File : 'crtbegin_so.c'
.plt:00007088 ; Source File : 'SeekwareNativeLib.c'
.plt:00007088 ; Source File : 'luts.c'
.plt:00007088 ; Source File : 'colorize.cpp'
.plt:00007088 ; Source File : 'palettes.cpp'
.plt:00007088 ; Source File : 'temperature.cpp'
.plt:00007088 ; Source File : 'badpix_corr.cpp'
.plt:00007088 ; Source File : 'badpix_detect.cpp'
.plt:00007088 ; Source File : 'gain_coef.cpp'
.plt:00007088 ; Source File : 'gain_corr.cpp'
.plt:00007088 ; Source File : 'median_5.cpp'
.plt:00007088 ; Source File : 'median_avg.cpp'
.plt:00007088 ; Source File : 'offset.cpp'
.plt:00007088 ; Source File : 'temp_coef.cpp'
.plt:00007088 ; Source File : 'temp_corr.cpp'
.plt:00007088 ; Source File : 'thermography.cpp'
.plt:00007088 ; Source File : 'alpf.cpp'
.plt:00007088 ; Source File : 'peaklimit.cpp'
.plt:00007088 ; Source File : 'asbnuc.cpp'
.plt:00007088 ; Source File : 'bilateral.cpp'
.plt:00007088 ; Source File : 'kalman.cpp'
.plt:00007088 ; Source File : 'median.cpp'
.plt:00007088 ; Source File : 'median_gain.cpp'
.plt:00007088 ; Source File : 'median_stack.cpp'
.plt:00007088 ; Source File : 'rc-offset.cpp'
.plt:00007088 ; Source File : 'bclahe.cpp'
.plt:00007088 ; Source File : 'imageprocess.cpp'
.plt:00007088 ; Source File : 'del_opv.cc'
.plt:00007088 ; Source File : 'new_opv.cc'
.plt:00007088 ; Source File : 'bad_alloc.cc'
.plt:00007088 ; Source File : 'del_op.cc'
.plt:00007088 ; Source File : 'eh_arm.cc'
.plt:00007088 ; Source File : 'eh_aux_runtime.cc'
.plt:00007088 ; Source File : 'eh_call.cc'
.plt:00007088 ; Source File : 'eh_catch.cc'
.plt:00007088 ; Source File : 'eh_exception.cc'
.plt:00007088 ; Source File : 'eh_globals.cc'
.plt:00007088 ; Source File : 'eh_personality.cc'
.plt:00007088 ; Source File : 'eh_terminate.cc'
.plt:00007088 ; Source File : 'eh_throw.cc'
.plt:00007088 ; Source File : 'eh_unex_handler.cc'
.plt:00007088 ; Source File : 'fundamental_type_info.cc'
.plt:00007088 ; Source File : 'new_op.cc'
.plt:00007088 ; Source File : 'pointer_type_info.cc'
.plt:00007088 ; Source File : 'pure.cc'
.plt:00007088 ; Source File : 'si_class_type_info.cc'
.plt:00007088 ; Source File : 'tinfo.cc'
.plt:00007088 ; Source File : 'atexit_arm.cc'
.plt:00007088 ; Source File : 'bad_cast.cc'
.plt:00007088 ; Source File : 'bad_typeid.cc'
.plt:00007088 ; Source File : 'class_type_info.cc'
.plt:00007088 ; Source File : 'eh_alloc.cc'
using System;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.IO;
namespace WindowsFormsApplication1
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
StreamReader sr = new StreamReader(@"C:\temp\000010.data", ASCIIEncoding.Default);
byte[] bytes = sr.CurrentEncoding.GetBytes(sr.ReadToEnd());
UInt16[] vals = new UInt16[32448];
int[] ivals = new int[32448];
for (int i = 0; i < 32448; i++)//64896
{
vals[i] = BitConverter.ToUInt16(bytes, i * 2);
if (vals[i] > 9000 || vals[i] < 7000) vals[i] = 8223;//outside this range is checksum?; max: 8632, min:7814
ivals[i] = (vals[i] - 7814);
ivals[i] = (int)Math.Round(Convert.ToDouble(ivals[i]) / 3.17);
}
var target = new Bitmap(208, 156);
int ix = 0;
for (int x = 0; x < 156; ++x)
{
for (int y = 0; y < 208; ++y)
{
target.SetPixel(y, x, Color.FromArgb(ivals[ix], ivals[ix], ivals[ix]));
ix++;
}
}
pictureBox1.Image = target;
target.Save(Application.StartupPath + "\\img.png");
}
}
}
Seems they are doing a lot of filtering which is why all the public released shots are so blurry. The actual sensor data is quite good. This thing has potentialHow do you know that data is from one of their sensors? Could easily have been from something else, generated for testing before hardware was available.
Seems they are doing a lot of filtering which is why all the public released shots are so blurry. The actual sensor data is quite good. This thing has potentialHow do you know that data is from one of their sensors? Could easily have been from something else, generated for testing before hardware was available.
The Ebay listing is almost certainly a pre-order as there is no pic of the real thing, and shipping is estimated at 17-27 Oct
I now have Java source of the library. I can see the device startup sequence (series of USB SetFeature requests) and it may be possible to get this running on PC with this information. Contact me if you want it.
If it's of any relevance, the Flir palettes are defined as YUV - I have an excel doc somewhere that converts them to RGB
There is a man on the boat... :D
(https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/?action=dlattach;attach=111501;image)
USB device (or at least beta) has VID 0x289D and PID 0x000F. Class/subclass 255 (Vendor specific):palm: Why didn't they use something like UVC? Do they really want vendor lock-in that much?
I really hope this is the actual sensor data, because the details are great.It will be interesting to see if I we make visual light photo in sunny day, convert to gray image, scale to this resolution and add some of those LUTs :-DD
Because they need to do a lot of processing to produce a visible image, so no particular reason to use a standard USB class.USB device (or at least beta) has VID 0x289D and PID 0x000F. Class/subclass 255 (Vendor specific):palm: Why didn't they use something like UVC? Do they really want vendor lock-in that much?
The fact that the boats ID is so clear would be very unusual unless it was directly heated !..or different emissivity - warm day, dark boat?
I have seen a lot of thermal imagery of vessels on water and sadly the image that you guys are manipulating does not look like a thermal image to my eyes. I am happy to be wrong but that boat is not displaying the thermal signiture that I would expect. The fact that the boats ID is so clear would be very unusual unless it was directly heated ! I have considered whether the boat is exposed to high levels of sunlight but it still looks wrong to me.
I have seen a lot of thermal imagery of vessels on water and sadly the image that you guys are manipulating does not look like a thermal image to my eyes. I am happy to be wrong but that boat is not displaying the thermal signiture that I would expect. The fact that the boats ID is so clear would be very unusual unless it was directly heated ! I have considered whether the boat is exposed to high levels of sunlight but it still looks wrong to me.
I was thinking that the images include a lot of near infrared in them lowering the far infrared contrast and making them look more like a visible light image.
This is more likely a dummy imagery converted from visible.Maybe they (Seek thermal) wanted to show something which will give you feeling of incredible accuracy and resolution of this thing to have more backers, while reality might be cold shower with blured imaginery which without aka Flir MSX additional visual image and good calibration will be difficult to understand what you see if environment ambient temperature and weather condition changes :-DD
Is it possible to add a Peltier cooler to an uncooled TIC for better imagery?
Is it possible to add a Peltier cooler to an uncooled TIC for better imagery?
I assume you would also have to make provisions to prevent condensation.
Good news! I just got mine from FedEx today (I had overnight shipping). Works well, minus a few bugs. Is anyone interested in me doing anything with it? Also, my order number was 39X, so they had at least 500 units shipped from my guess, more than like 1,000.
Good news! I just got mine from FedEx today (I had overnight shipping). Works well, minus a few bugs. Is anyone interested in me doing anything with it? Also, my order number was 39X, so they had at least 500 units shipped from my guess, more than like 1,000.
Did you get a shipping email, or did it just show up?
Good news! I just got mine from FedEx today (I had overnight shipping). Works well, minus a few bugs. Is anyone interested in me doing anything with it? Also, my order number was 39X, so they had at least 500 units shipped from my guess, more than like 1,000.
Did you get a shipping email, or did it just show up?
No shipping email and the website still says processing, so I was rather surprised to see it on my doorstep when I got home!
I could see them processing over night orders first, regardless of order number. Then following with standard by order number.
So the story goes that this ebay seller bought the unit for an incompatible phone and now he wants to gouge people for $750 on a $200 device.... ar*e ho*e. >:( He is free to sell it for whatever he can get though. Its a pity that people are so keen to turn a fast buck....kinda makes them look really greedy. That's life though and it is a free world. I will be interested to see what it sells for, if at all.A couple of Flir Ones Sold for around $500 each a couple of days ago, so I don't doubt it will sell, especially as he's offering international shipping.
Is it just me, or are the pictures a little blurry for the specs? The camera is supposed to have a 206 x 156 resolution, yet many sample images from 160 x 120 cameras of other brands seem much sharper.
Bummer... Since there still is no SEEK THERMAL iOS app in the Apple App Store, Seek obviously does not have any iOS cameras to ship yet. :-- It looks like I'm still out of luck for delivery any time soon, even with a low order number. :(I just hope they don't hold orders for both types til the Apple one is available - I ordered both in case they became available at different times but maybe this was a bad move...
I'm guessing they will probably tweet out dock arrival of the iOS devices like they did for the Android cameras on October 3rd.
Apple, you have failed me again... :palm:
Bummer... Since there still is no SEEK THERMAL iOS app in the Apple App Store, Seek obviously does not have any iOS cameras to ship yet. :-- It looks like I'm still out of luck for delivery any time soon, even with a low order number. :(I just hope they don't hold orders for both types til the Apple one is available - I ordered both in case they became available at different times but maybe this was a bad move...
I'm guessing they will probably tweet out dock arrival of the iOS devices like they did for the Android cameras on October 3rd.
Apple, you have failed me again... :palm:
It would be much better if they would map whole palette to current temp range in photo.Wouldnt you start getting some weird glowing effects across the whole image, as something heats up or cools down?
I just noticed something... If you look at dog image with iron palette.
They are only using small part of pallete.
It seems that software is mapping palette colors to predefined temperatures.
So on all images specific color represents the same temperature.
(http://i.gyazo.com/dd3ee3ff2b3e81956790de4bd6882e23.png)
It would be much better if they would map whole palette to current temp range in photo.
Then all photos would look more like this:
(http://gyazo.com/f5cb3faa30080590d5c933b5ba0fdb9d.png)
... I ordered both in case they became available at different times but maybe this was a bad move...
Mike, how did you order it to be shipped to the UK?Someone in the US is ordering & reshipping to me.
Brother at end of hallway (approx. 50 ft away from camera)This image when saved has .png extension and resolution 456x611, so it looks like gyazo.com where you downloaded oryginal image changed oryginal one :palm:
gyazo.com bac57cd16ac0bfd6ad58309e0f2d69f2.png
The camera is supposed to have a 206 x 156 resolution, yet many sample images from 160 x 120 cameras of other brands seem much sharper.This oryginal image had 206x156 resolution and RGB (3 bytes per pixel) ?
(%i2) float(611/456);
(%o2) 1.339912280701754
(%i3) float(206/156);
(%o3) 1.32051282051282
This oryginal image had 206x156 resolution and RGB (3 bytes per pixel) ?
...piece of history about Flir and the co-founder of Seek Thermal Bill Parrish describing a lawsuit from 2009...So it looks like that FLIR lost a lawsuit since they were:
http://caselaw.findlaw.com/ca-court-of-appeal/1229385.html (http://caselaw.findlaw.com/ca-court-of-appeal/1229385.html)
FLIR SYSTEMS, INC., et al., Plaintiffs and Appellants
William PARRISH et al., Defendants and Respondents
The judgment and order awarding respondents $1,641.216.78 attorney fees and costs are affirmed. (§?3426.4.) Respondents are awarded costs and attorney fees on appeal, in an amount to be determined by the trial court on noticed motion.
"Subjective bad faith may be inferred by evidence that appellants intended to cause unnecessary delay, filed the action to harass respondents, or harbored an improper motive."
"After quitting Indigo, Parrish learned that appellants were submitting patent applications on a packaging and manufacturing process that he had worked on. Parrish told Woolaway, FLIR's Chief Intellectual Property Officer, that the patent applications were not valid."
"Woolaway, who authored the patent applications, stated that the United States Patent & Trademark Office could go either way on the validity of the applications. Woolaway was concerned about Parrish's remarks but did not believe Parish would steal or misuse appellants' intellectual property."
Lewis's testimony is remarkable and clearly shows that the action was brought for an anti-competitive purpose. Lewis did not “think it would be good, healthy for them [respondents] to go and directly compete with us.”
Lewis stated that FLIR “couldn't tolerate a direct competitive threat by [respondents] because it would fly in the face of everything that we spent 200 million dollars to buy.”
Lewis's statements were corroborated by FLIR Senior Vice President Tony Trunzo who testified that respondents' “vision for the industry will take place someday” but FLIR “wanted that competition to take place as far out in the future as possible.”
This Flir's MSX made not inside Lepton module, but using external ARMs is bullshit as now it is clear they simply wanted stop others do such trivial things.It would be ridiculous to put it in the Lepton module. There are many applications that wouldn't need it, so it would waste silicon, and you'd lose flexibility of camera interfaces.
Who gave them patent for such obvious thing used for years in image processing applications?Is there another thermal imager prior to the Flir patent that uses edges extracted from a visible image to enhance a low-res thermal image?
Some history here, I have first hand knowledge of this situation in background as an analyst; In 2004, FLIR purchased Indigo for approximately $185 million, acquiring Indigo's (prior company to Seek) patents, technology, and intellectual property. Bill Parish and Fitzgibbons (Seek founders) were shareholders and officers of Indigo before the company was sold. After the sale, Parish and Fitzgibbons continued working at Indigo. Both informed FLIR that they intended to create a new class of product for consumer markets and company called Thermicon and asked FLIR's board if they wanted in. Ratheon lined up as a licensing customer. FLIR backed out and so did Ratheon when they found out FLIR had backed out. Then FLIR sued for a perminent injunction against Parish and Fitzgibbons for (1) making use of appellants' trade secrets in the design, manufacture, and high-volume production of uncooled Vanadium Oxide microbolometers; ?(2) selling uncooled Vanadium Oxide microbolometers in commercial markets less than 12 months after respondents entered into a license with Raytheon Company or any other third party to purchase intellectual property; ?or (3) using, disclosing or misappropriating the contents of an Indigo commodity code database that Parrish attempted to download while an employee at Indigo. The trial court found no misappropriation or threatened misappropriation of trade secrets and FLIR was forced to pay >$1.6M in court costs and attorney's fees. It is my belief that Parrish has successfully proven that he has access to the IP and patents through an agreement, only after a given amount of time, or Parrish owns the IP and is licensing it back to FLIR, which would account for the dispairity in cost of the two products. -R. T.
All this is off topic I know but it is worth considering who and what 'FLIR' really are as they have much influence in the world of thermography and they are a potential competitor to SEEK Thermal.Nice to know some history, but who knows who is patent owner if any of this fusion adding visual light based edges/countours to thermal image, named by Flir MSX?
It could, however, affect what third parties (meaning: you) can legally do with regard to distributing their own apps that use the ideas in these patents.Rather, those patents can be illegal and only a way to limit competition in wrong way.
Patent 8,520,970: Infrared resolution and contrast enhancement with fusion - https://www.google.com/patents/US8520970 (https://www.google.com/patents/US8520970)One of the claims:
combining, by a processor, luminance information of the extracted pixel data with luminance information of corresponding pixels in the IR image to augment the IR image with the contours and/or edges from the visual image, wherein the augmented IR image comprises temperature information that is unaltered by the combining.This doesn't have any sense, while if we add/modify even edges we have to destroy/change small parts of IR image where edges are else we can't see any difference on IR image if we do not change it :wtf:
Seek Support (Seek Thermal)
Oct 10 12:42
Thank you for contacting Seek Support.
We understand that you are interested in getting a status update on your order. Initial shipments were held pending the release of our companion Android and iOS apps. The Android app posted to Google Play on Friday, and Android cameras began shipping right away. We anticipate that it will take 1-2 weeks to work through the backlog of Android orders.
For iOS, we submitted to Apple and the app is in review. Once approved we will begin shipping iOS units as well.
All orders are being processed in the order in which they were received, and we are working to get them out to everyone as quickly as possible. When your order ships you will receive an update email with tracking details.
If you have other questions regarding your order, or need to have details from your order modified, please send an email to retailsupport@thermal.com with your order number, and the desired updates.
The judgment and order awarding respondents $1,641.216.78 attorney fees and costs are affirmed. (§?3426.4.) Respondents are awarded costs and attorney fees on appeal, in an amount to be determined by the trial court on noticed motion.
QuoteThe judgment and order awarding respondents $1,641.216.78 attorney fees and costs are affirmed. (§?3426.4.) Respondents are awarded costs and attorney fees on appeal, in an amount to be determined by the trial court on noticed motion.
$1.6M just in attorney fees :o
LEV - the Legal Engineering Videoblog...Ditto....
Or is it?
Also anyone received their seek yet? I can't wait for Mike to get his :D
According to a reply on the comments, no postprocessing was doneThis part of one of those comments:
"It could be that noise is less noticeable on video then on still image... ?"
Damned if you do, damned if you dont. If they have stock they can fulfill orders.
Can always update software later.
According to a reply on the comments, no postprocessing was doneThis part of one of those comments:Quote"It could be that noise is less noticeable on video then on still image... ?"
In spare time I will load one of them frame by frame using OpenCV and try to enhance it a little bit and look into differences between frames too >:D
But there is a problem on YT there is no oryginal thermal video I guess, while only we can watch and download processed by YT itself ???
How do you think, which of those YT videos is in the best quality in your opinion?
As for imau, what makes you think it's a SCAM, we all know is an IRCAM ;)
patience is a virtue.
Edit: after all we didn't know anything about this camera 2 months back, they just announced it at the end of September so it's been really just 2 weeks.
We'll see if they actually end up shipping anything. In the last week, as far as I can tell, there have only been two Youtube videos showing the camera - one unboxing (and not powering it up) and one showing 3D printing.
Seek's remarkable lack of communication since launch is extremely worrisome. I placed my order on 9/26, and my confirmation email stated, "we are currently experiencing a 5-7 business delay in the shipment of your order." Well, something like a week went by and then Seek announced that they were waiting for the Android app to go live before they shipping. Judging by the community reaction, this was a big surprise and was pretty upsetting to a lot of people.
Well, here we are, now 18 days since my order, 11 days since the app was released in the Play Store. No matter how you slice it, Seek is very late in shipping their product, and is not communicating with its customers. This whole thing is looking more and more like a scam everyday, or at least a horribly mismanaged company. Either way, if I don't hear *something* from them today to address all of this, I'll be calling my bank to ensure I don't lose $214.93.
I'm in the 600s and getting impatient. :rant:How do you know you are 600's-maybe they simply assigned random unique numbers in the unknown range >:D
Product is currently on back order.Product is being shipped as quickly as possiblefor Android
Product is currently on back order. It should begin shipping within the next several weeks.For iPhone.
And Mike: <1000 installs are curiosity and 10 reviews are employees.I was trying to install the software, it just says my device isn't supported. :-// And I don't think I'm going to order one of these before I see real people using it and all the kinks and bugs have been fixed. Maybe the next generation or cheap thermal imagers has come out and hopefully they would be even cheaper since it would be a toy.
My device wasn't supported so I side loaded it, but since it supports my wife's phone then I installed it again in there. So I guess that counts for 2 installs for one device. But then I did share it so I don't know how much the install base reflects the actual purchases.
Update: due to an unexpected shortage of a key component, production is delayed right now. Android shipping will ramp back up in a few days.
My device wasn't supported so I side loaded it, but since it supports my wife's phone then I installed it again in there. So I guess that counts for 2 installs for one device. But then I did share it so I don't know how much the install base reflects the actual purchases.
I don't know if side-loading would show up in Play store stats.
The lack of communication is inexcusable. Even if they have to manually do an export of their customers to use a service. Sending emails to a mass of people is easy and common.
Two new posts showed up on their blog: http://seekthermal.tumblr.com/ (http://seekthermal.tumblr.com/)yeah but before that they were saying 2015...
and another video on facebook:
https://www.facebook.com/video.php?v=753765308029376 (https://www.facebook.com/video.php?v=753765308029376)
IMHO a good way to calm down people who started to doubt that they will ever receive the module.
Sadly there are some bad news for us outside the USA:
when will you be shipping to the UK ?
in the next couple of weeks. pls fill out form here to be notified
Before they were saying that international shipping will be available by the end of this week...
Two new posts showed up on their blog: http://seekthermal.tumblr.com/ (http://seekthermal.tumblr.com/)Not sure I like all the talk of glue on that page.... >:(
Two new posts showed up on their blog: http://seekthermal.tumblr.com/ (http://seekthermal.tumblr.com/)Not sure I like all the talk of glue on that page.... >:(
Two new posts showed up on their blog: http://seekthermal.tumblr.com/ (http://seekthermal.tumblr.com/)Not sure I like all the talk of glue on that page.... >:(
I don't mind it on the structural side, but I really, really like to take things apart. When they are expensive things, it is nice if they go back together. :o
There is nothing a well placed set of screws and O-rings couldn't do.....at a price.
Could that be the shutter actuating and NUCing or FFCing the image?Could be the effect of keyframes on Youtube video compression of a noisy image
Wire just published review: http://www.wired.com/2014/10/seek-thermal-infrared-camera-iphone-android/ (http://www.wired.com/2014/10/seek-thermal-infrared-camera-iphone-android/)
The interesting part is comparison with Flir One.
There is so much difference between Flir One and Seek shots. Obviously, MSX is great add-on.
Every few seconds image gets "nicer".Nicer does not mean more accurate, but it can be simply blured as well ;)
This are two frames at 00:02 and the difference is huge:
Wire just published review: http://www.wired.com/2014/10/seek-thermal-infrared-camera-iphone-android/ (http://www.wired.com/2014/10/seek-thermal-infrared-camera-iphone-android/)For me interesting is this Thermal+ mode >:D
"But wait! There is one other mode – Thermal+. In this mode, the app uses both the IR camera and the iPhone’s built in camera. This way you can switch back and forth between visible and IR images."
Mike, would you happen to know your order number?69x - it has arrived in the US, the acknowledgement email arrived afterwards!
Every few seconds image gets "nicer".
This are two frames at 00:02 and the difference is huge:
Without an NUC event the Industrial cameras take some time to suffer the mottling effect that is a sign of temperature drift in the Pixels. I have had a stable image for more than 5 minutes BUT these cameras have TEC temperature stabilized microbolometers. The E4 drift rate is much rater due to the lack of any TEC but the software does try to compensate based on the chassis and microbolometer die temperature sensor readings.So would modifying it with a TEC (Peltier) possibly make it better? Just to cool it down enough so it doesn't start condensation but still keep it at optimum temperature. I've seen some cool modifications for astro imaging cameras using peltiers, just a small cold finger will do wonders.
Small pixel size and subsequent lower mass may also add to temperature uniformity issues across the array.
THE APP IS NOW IN THE APP STORE!!!APP with closed source code is not needed, but real hardware to hack >:D
I don't know too much about the physics of the sensors, but I'm sure that if cooling would help, manufacturers would be doing it, as the cost of a peltier is small compared to the sensor.Without an NUC event the Industrial cameras take some time to suffer the mottling effect that is a sign of temperature drift in the Pixels. I have had a stable image for more than 5 minutes BUT these cameras have TEC temperature stabilized microbolometers. The E4 drift rate is much rater due to the lack of any TEC but the software does try to compensate based on the chassis and microbolometer die temperature sensor readings.So would modifying it with a TEC (Peltier) possibly make it better? Just to cool it down enough so it doesn't start condensation but still keep it at optimum temperature. I've seen some cool modifications for astro imaging cameras using peltiers, just a small cold finger will do wonders.
Small pixel size and subsequent lower mass may also add to temperature uniformity issues across the array.
THE APP IS NOW IN THE APP STORE!!!APP with closed source code is not needed, but real hardware to hack :blah:
Just got hold of mine. Having issues possibly due to old phone -in the meantime can someone download the latest app for me (not available outside US) - looks like it was updated Oct 14th
Just got hold of mine. Having issues possibly due to old phone -in the meantime can someone download the latest app for me (not available outside US) - looks like it was updated Oct 14thCan't wait for the teardown & reverse engineering video... :-/O
Thanks!Just got hold of mine. Having issues possibly due to old phone -in the meantime can someone download the latest app for me (not available outside US) - looks like it was updated Oct 14th
Check your PMs...
Case is aluminumMagnesium
4 very nice test points under the sensor.. separated ground fill... money's on SPI-likeYes, probably. Also the MCU is flashless -all the code lives in the external SPI flash >:D
Device Descriptor:
bcdUSB: 0x0200
bDeviceClass: 0x00
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x40 (64)
idVendor: 0x289D
idProduct: 0x0010
bcdDevice: 0x0100
iManufacturer: 0x01
0x0409: "Seek Thermal"
iProduct: 0x02
0x0409: "PIR206 Thermal Camera"
iSerialNumber: 0x05
bNumConfigurations: 0x01
ConnectionStatus: DeviceConnected
Current Config Value: 0x01
Device Bus Speed: High
Device Address: 0x02
Open Pipes: 2
Endpoint Descriptor:
bEndpointAddress: 0x01 OUT
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x00
Endpoint Descriptor:
bEndpointAddress: 0x81 IN
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x00
Configuration Descriptor:
wTotalLength: 0x0040
bNumInterfaces: 0x02
bConfigurationValue: 0x01
iConfiguration: 0x00
bmAttributes: 0x80 (Bus Powered )
MaxPower: 0x32 (100 Ma)
Interface Descriptor:
bInterfaceNumber: 0x00
bAlternateSetting: 0x00
bNumEndpoints: 0x02
bInterfaceClass: 0xFF
bInterfaceSubClass: 0xF0
bInterfaceProtocol: 0x00
iInterface: 0x03
0x0409: "iAP Interface"
Endpoint Descriptor:
bEndpointAddress: 0x01 OUT
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x00
Endpoint Descriptor:
bEndpointAddress: 0x81 IN
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x00
Interface Descriptor:
bInterfaceNumber: 0x01
bAlternateSetting: 0x00
bNumEndpoints: 0x00
bInterfaceClass: 0xFF
bInterfaceSubClass: 0xF0
bInterfaceProtocol: 0x01
iInterface: 0x04
0x0409: "com.thermal.pir206.1"
0x0409: "com.thermal.pir206.1"
Interface Descriptor:
bInterfaceNumber: 0x01
bAlternateSetting: 0x01
bNumEndpoints: 0x02
bInterfaceClass: 0xFF
bInterfaceSubClass: 0xF0
bInterfaceProtocol: 0x01
iInterface: 0x04
0x0409: "com.thermal.pir206.1"
0x0409: "com.thermal.pir206.1"
Endpoint Descriptor:
bEndpointAddress: 0x02 OUT
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x00
Endpoint Descriptor:
bEndpointAddress: 0x82 IN
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x00
There have been reports of flakiness on other platforms, in particular Samsung S3, and a message on their facebook page indicates that they have found some issues and will be issuing an update soon.
convert -depth 16 -endian lsb -size 208x156 gray:epdump.bin -auto-level seek.pngIf epdump.bin contains many images (dump an entire stream) this will dump all of them to separate files named seek-0.png, seek-1.png, etc.convert marshallh-wave.png ..\palette.png -clut marshallh-wave-colorized.pngPlugging it into a linux desktop lsusb produced: Bus 002 Device 006: ID 289d:0010Did you checked what dmesg shows on its output?
D/ConnectivityService( 489): Done.
D/ConnectivityService( 489): Setting timer for 720seconds
I/ServiceDumpSys( 887): dumping service [account]
D/dalvikvm( 887): GC_FOR_ALLOC freed 246K, 7% free 9225K/9904K, paused 31ms, total 31ms
D/libgps ( 489): proxy_gps_inject_location()
I/GCoreUlr( 983): Successfully inserted location
I/GCoreUlr( 983): Not calling LocationReportingService, hasMoved: false, elapsed millis: 3015626, request: Tablet
W/UsbSettingsManager( 489): no meta-data for ResolveInfo{426a8bf8 com.estrongs.android.pop/.view.FileExplorerActivity m=0x108000}
W/ContextImpl( 489): Calling a method in the system process without a qualified user: android.app.ContextImpl.sendBroadcast:1131 com.android.server.usb.UsbSettingsManager.deviceAttached:621 com.android.server.usb.UsbHostManager.usbDeviceAdded:156 com.android.server.usb.UsbHostManager.monitorUsbHostBus:-2 com.android.server.usb.UsbHostManager.access$000:38
I/ActivityManager( 489): START u0 {flg=0x10000000 cmp=com.android.systemui/.usb.UsbPermissionActivity (has extras)} from pid 489
I/ActivityManager( 489): START u0 {flg=0x10000000 cmp=com.android.systemui/.usb.UsbConfirmActivity (has extras)} from pid 489
I/ActivityManager( 489): Displayed com.android.systemui/.usb.UsbConfirmActivity: +121ms
I/ActivityManager( 489): Displayed com.android.systemui/.usb.UsbPermissionActivity: +122ms
V/GmsNetworkLocationProvi( 983): onSetRequest: ProviderRequestUnbundled, reportLocation is true and interval is 120000
V/GmsNetworkLocationProvi( 983): SET-REQUEST
V/GmsNetworkLocationProvi( 983): in Handler: ProviderRequestUnbundled, reportLocation is true and interval is 120000
W/InputMethodManagerService( 489): Window already focused, ignoring focus gain of: com.android.internal.view.IInputMethodClient$Stub$Proxy@42650200 attribute=null, token = android.os.BinderProxy@426e4510
W/GA-SERVICE( 887): Thread[Thread-546,5,main]: Using destination https://ssl.google-analytics.com
D/Grafika (11376): EGLContext created, client version 2
D/dalvikvm(11376): GC_CONCURRENT freed 12062K, 35% free 32240K/49316K, paused 2ms+5ms, total 54ms
D/dalvikvm(11376): WAIT_FOR_CONCURRENT_GC blocked 22ms
W/GA-SERVICE( 887): Thread[Thread-546,5,main]: Using destination https://ssl.google-analytics.com
D/dalvikvm(11376): GC_CONCURRENT freed 4139K, 27% free 36233K/49316K, paused 2ms+4ms, total 39ms
D/dalvikvm(11376): WAIT_FOR_CONCURRENT_GC blocked 33ms
V/GmsNetworkLocationProvi( 983): onSetRequest: ProviderRequestUnbundled, reportLocation is true and interval is 120000
V/GmsNetworkLocationProvi( 983): SET-REQUEST
V/GmsNetworkLocationProvi( 983): in Handler: ProviderRequestUnbundled, reportLocation is true and interval is 120000
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/dalvikvm( 983): GC_CONCURRENT freed 597K, 12% free 9484K/10724K, paused 3ms+4ms, total 29ms
D/dalvikvm( 983): WAIT_FOR_CONCURRENT_GC blocked 20ms
D/libgps ( 489): proxy_gps_inject_location()
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/Seekware(11376): Begin ThermographyCalc
D/Seekware(11376): Finished ThermographyCalc
D/Seekware(11376): Begin ImageProcess
D/Seekware(11376): Finished ImageProcess
D/Seekware(11376): Begin Colorize
D/Seekware(11376): Finish Colorize
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/Seekware(11376): Begin ThermographyCalc
D/Seekware(11376): Finished ThermographyCalc
D/Seekware(11376): Begin ImageProcess
D/Seekware(11376): Finished ImageProcess
D/Seekware(11376): Begin Colorize
D/Seekware(11376): Finish Colorize
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/Seekware(11376): Begin ThermographyCalc
D/Seekware(11376): Finished ThermographyCalc
D/Seekware(11376): Begin ImageProcess
D/Seekware(11376): Finished ImageProcess
D/Seekware(11376): Begin Colorize
D/Seekware(11376): Finish Colorize
This goes on and on forever...
(http://i.imgur.com/PDDU1hP.jpg)
Empty space where Lightning<>USB bridge interface sits.
Tell me the lens holder isn't styrofoam, please...Silicone dust shield, white plastic lens holder. It's quite solid
Where are you suggesting the Lighting bridge would go in that? I don't see any obvious empty spots.If you mean the Lightning IC for iOS devices, it could be like the FLIR ONE which has the Lightning IC in the Lightning connector assembly itself. From what I could tell on the FLIR ONE it's just USB pass-through with some basic comms to tell the iDevice that a peripheral is attached.
Low values probably dead pixels - if they want to keep costs low, they wouldn't want to scrap sensors with bad pixels.There are definitely some dead pixels, but there are also low value pixels which occur regularly, every 28 pixels, forming broken diagonal lines across the image. I guess it's still possible those are dead pixels but that pattern would be quite a coincidence :o
If you mean the Lightning IC for iOS devices, it could be like the FLIR ONE which has the Lightning IC in the Lightning connector assembly itself. From what I could tell on the FLIR ONE it's just USB pass-through with some basic comms to tell the iDevice that a peripheral is attached.There is an unpopulated 8 pin chip on the opposite side to the flex
There are definitely some dead pixels, but there are also low value pixels which occur regularly, every 28 pixels, forming broken diagonal lines across the image. I guess it's still possible those are dead pixels but that pattern would be quite a coincidence :oEmbedded reference dark pixels?
D'oh! I missed that.QuoteIf you mean the Lightning IC for iOS devices, it could be like the FLIR ONE which has the Lightning IC in the Lightning connector assembly itself. From what I could tell on the FLIR ONE it's just USB pass-through with some basic comms to tell the iDevice that a peripheral is attached.There is an unpopulated 8 pin chip on the opposite side to the flex
Since not all are exactly 0, that would be my guess as well.QuoteThere are definitely some dead pixels, but there are also low value pixels which occur regularly, every 28 pixels, forming broken diagonal lines across the image. I guess it's still possible those are dead pixels but that pattern would be quite a coincidence :oEmbedded reference dark pixels?
I wonder who makes the sensor.
Since these data are presumably unprocessed raw data, why does the image change significantly?It may be wrong assumption while there is quite powerfull IC MCU ARM ROMLESS 100TFBGA digikey: NXP LPC4320FET100 (http://www.digikey.com/product-detail/en/LPC4320FET100,551/568-9456-ND/2677579) ;)
Code is stored in an external SPI flash, so should be pretty accessible, probably via the test pads. ISTR someone said there was a firmware image file in the .APK package.Since these data are presumably unprocessed raw data, why does the image change significantly?It may be wrong assumption while there is quite powerfull IC MCU ARM ROMLESS 100TFBGA digikey: NXP LPC4320FET100 (http://www.digikey.com/product-detail/en/LPC4320FET100,551/568-9456-ND/2677579) ;)
Latest datasheet linked from Digikey: LPC18X0,LPC43X0 IRC Update 22/Aug/2014 (http://media.digikey.com/pdf/PCNs/NXP/201408013F01.pdf)
Update: Above some production notice of IRC details changed.
Its NXP page there:
http://www.nxp.com/products/microcontrollers/cortex_m4/lpc4300/LPC4320FET100.html (http://www.nxp.com/products/microcontrollers/cortex_m4/lpc4300/LPC4320FET100.html)
Its datasheet: http://www.nxp.com/documents/data_sheet/LPC4350_30_20_10.pdf (http://www.nxp.com/documents/data_sheet/LPC4350_30_20_10.pdf)
It would be very interesting to.... disassemble its ARM program code, but where it is -on external flash IC? >:D
BTW: It costs on Digikey <$10 and arount $4 for bigger volume. Quite nice MCU-maybe it is time to do some ARM development ::)
on the one image of the internals, it looks like the pins for that coil are not soldered to the board. am I the only one to notice that?I noticed that too, it makes sense: This board is build for lowest price. The coil seems to be pressed into the board. This can be done with a machine, soldering coil contacts is often done by hand.
on the one image of the internals, it looks like the pins for that coil are not soldered to the board. am I the only one to notice that?I noticed that too, it makes sense: This board is build for lowest price. The coil seems to be pressed into the board. This can be done with a machine, soldering coil contacts is often done by hand.
If done properly, pressfit contacts aremore robust than soldering. This technique is widely used in automtive electronics because it is much more tolerant to vibrations than solder connections.
Watermarking the images like that is a very obnoxious move from Seek Thermal.
No, it's definitely pressfit (I've had it out) - the pin is split in the middle to provide tensionon the one image of the internals, it looks like the pins for that coil are not soldered to the board. am I the only one to notice that?I noticed that too, it makes sense: This board is build for lowest price. The coil seems to be pressed into the board. This can be done with a machine, soldering coil contacts is often done by hand.
If done properly, pressfit contacts aremore robust than soldering. This technique is widely used in automtive electronics because it is much more tolerant to vibrations than solder connections.
It could also be pin in hole reflow (on top only).
Picture of one of my dogs.Why this image has bigger resolution than Seek Thermal sensor capability?
...
img_thermal1915628406.jpg (35.53 kB, 624x832 - viewed 193 times.)
process/batch variation? or die revs?Did you tried to make more thermal image shots at different ambient temperatures just to see if these hexagonal sensor pixels patterns maybe changes somehow and it is temperature dependent or is consistent and unique to given Seek Thermal sensor-something like its footprint?
If it was only 156x208 it would be too tiny to display....Operating system software could simply resize 208x156 it to fit into display, but we still could be able to save oryginal one.
After thinking again, the press fit mounting has probably another reason:on the one image of the internals, it looks like the pins for that coil are not soldered to the board. am I the only one to notice that?I noticed that too, it makes sense: This board is build for lowest price. The coil seems to be pressed into the board. This can be done with a machine, soldering coil contacts is often done by hand.
If done properly, pressfit contacts aremore robust than soldering. This technique is widely used in automtive electronics because it is much more tolerant to vibrations than solder connections.
For Mike and those with a SEEK that has been taken apart.... it would be interesting to see a thermal image of the SEEK PCB (front and rear) when running to see if the PCB is suffering significant thermal creep towards the microbolometer.
...just received a Moto G which works :D
"Radio FM radio":-DD
5 MP, 2592 ? 1944 pixels, autofocus, LED flash
720 x 1280 pixels, 4.5 inches (~326 ppi pixel density)
microUSB v2.0, USB HostAccording to http://en.wikipedia.org/wiki/USB_On-The-Go (http://en.wikipedia.org/wiki/USB_On-The-Go)
USB OTG is a part of a supplement[1] to the Universal Serial Bus (USB) 2.0 specification originally agreed upon in late 2001 and later revisedThis microUSB v.20 is the key that that this thermal camera can work, or this is also Android version issue?
GPS Yes, with A-GPS, GLONASSIt has builtin one or this is some kind of external device?
My Motorola MOTO G comes with a decent auto focus camera (confirmed in tests) and a GPS that tells the OS where the camera is and interacts with apps.From link above to gsmarena.com
Sensors Accelerometer, proximity, compassit has also accelerometer and compass, so with GPS live data, probably it is possible to make those Google street view images and send directly via internet to their website ;)
What I don't really understand is why Seek want you to register - at least you can do 'later..' - hope this doesn't get naggy!
What I don't really understand is why Seek want you to register - at least you can do 'later..' - hope this doesn't get naggy!
That unfortunately is quite simple. When you buy consumer "smart-device", you're not simply buying a piece of equipment. You are buying the manufacturer's way of getting closer to your personal info, be it your email address, your physical location, your personal comms, browsing history or your brand preferences. This data is then sold in bulk.
This is the very same thing - you buy a cheap TIC and they get to place their closed-source code into something you carry 24/7 with you.
I'm not saying it's not possible for tyrian to be an exception (though that would be unlikely), all I'm saying is that this is a common industry practice.
Mike,No idea - I don't see any reason to register it so can't see it being a problem. My guess is they'll start EU shipping once they clear the US backlog.
You made mention of registering your SEEK app and from what you said this seemed to be an issue. Do you think SEEK will refuse to register the app for UK users as they have not released it here yet ? It would be very petty for SEEK to refuse registration of a personal import unit. It would lower my view of a company that claims that it wishes to bring affordable thermal cameras to the masses.
Aurora
$ file libseekthermal.so.1.0.1For the moment automated software marked those black sensor data pixels with RGB green and now will try to output my own version of thermal imaginery using simple image processing tools to fill those black pixels with some usefull values and detect bad pixels and mark them red
libseekthermal.so.1.0.1: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, not stripped
Mike, neat stuff. I take that just powering up the device doesn't spew the raw data until it's initialized, right?Correct. But it's possible there might be a test mode...
Seek Thermal sensor 206 x 156 black pixels: count: 2169 good: 2138 bad: 31However, when we count those 5 pink pixels and let them be good ones, than we have in 206x156 image:
The almost-black dots are not all 00., they are definitely intentional.On PNG image provided by you (RGBA) 8 bits per channel those black pixels marked by my tools green, red and pink had 0x00 zero the same values in RGB channels and 255 in Alpha channel and most of them fits into this hexagon pattern.
Is there a convenient connector to plug this camera into a standard laptop USB port (type A)?
Is there a convenient connector to plug this camera into a standard laptop USB port (type A)?
A quick search found this:
http://usb.brando.com/usb-2-0-male-to-micro-b-female-adapter_p02840c0042d015.html (http://usb.brando.com/usb-2-0-male-to-micro-b-female-adapter_p02840c0042d015.html)
There has to be others as well.
My search was "usb a male to micro b female adapter" and click on images to make sure the micro b is female.
A quick search found this:
http://usb.brando.com/usb-2-0-male-to-micro-b-female-adapter_p02840c0042d015.html (http://usb.brando.com/usb-2-0-male-to-micro-b-female-adapter_p02840c0042d015.html)
There has to be others as well.
My search was "usb a male to micro b female adapter" and click on images to make sure the micro b is female.
Or: http://www.amazon.com/gp/product/B009AWA3VK/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1 (http://www.amazon.com/gp/product/B009AWA3VK/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1)Thanks for the link, actually that pushed me to get one for my seek to start probing the protocol, but it seems like it will come from the slow boat (delivery estimate Nov 20th to Dec 9th) but i'm in no hurry since I got this to winterize my home and I won't be messing with it until I'm done.
Probably made in the same factory. I got one of these and it took about 2 weeks to arrive. I figured for ~$1.50 why not...
It works fine with my Seek TC.
...ken....
This gradient issue is pretty bad. Does anyone else experience this? Seems almost unusable for most practical situations, although I can now use this $200 camera to verify that my teapot is hot vs. using my finger before.
Here's a door with a leak around the bottom and it has a dual-flap pet door that's a little cool too. Comparing E4+ with seek (no comparison of course - to be expected), but look at what happens when I turn the Seek upside-down. Now where is the door leaking?
It seems to me this has potential to be corrected by improved calibration routines in the app/firmware, but I haven't contacted them yet to see if that's in the works. Has anyone already had that conversation with them?
As has been stated, an FPA with a thermal gradient across it that cannot be compensated adequately is pretty useless for anything more than toy applications.I think this really was intended as a "toy" product, built down to a price. (And as the comparison with Flir One shows, "resolution isn't everything" either...)
... but look at what happens when I turn the Seek upside-down. Now where is the door leaking?Maybe there is more trivial explanation to this- some kind of weird software bug, so while such use case scenario (turning Seek up-down) is not implemented well and missed something during testing. ;)
Actually, the fact that the shutter closed images look good point exactly to the shutter itself as the source of the gradient if the calibration is working correctly. The calibration is neutralizing the shutter gradient, and thus we get negative shutter gradient overlay on the real image.
A quick look at the PCB design and shutter position leads me to the following comments:the switching reg is at the opposite end, and is unlikely to get hot, if you assume it handles all the input current ( which it doesn't but I don't have a figure for the seperate regs), and it's 75% effifcient, dissipation will be about 60mW
1. The likely greatest sources of heat in the SEEK are the switching regulator transistor and the microprocessor. If we treat them as warm air generators within the SEEK's sealed case and consider convection air movement we may find our problem
Friendly email sent to SEEK and this thread referenced for their information. It will be interesting to hear their thoughts on this matter.
Aurora
Friendly email sent to SEEK and this thread referenced for their information. It will be interesting to hear their thoughts on this matter.
Aurora
Thanks, I was just gonna do that :)
Quick observations :
Mine shows a gradient at power-up, so it isn't thermal.
Removing the shutter and pointing at a flat surface, there is no gradient, but noise increases pretty rapidly between cal times - presumably this is a warm-up thing.
The surface of the shutter, though nominally flat, has machining marks from the mould. Although in a photo these make it look like the surface is curved, this is not the case.
Hello everyone, I've been a lurker for awhile but I just had to register because this is a fascinating thread.
As mike pointed out, it could be a timing issue.
Perhaps the gradient is due to a rolling shutter effect...
Is it possible that the speed of the shutter action is a variable that depends on mfg batch, phone battery voltage, or something else?With decent scope maybe it will be possible make own DIY using only this part cut from whole PCB - sensor itself and put there MPU we like :-DD
With decent scope maybe it will be possible make own DIY using only this part cut from whole PCB - sensor itself and put there MPU we like :-DDI think the only viable way will be to write new code for the MCU - there are 18 bond-wires onto the die and some disappear onto vias inside the lens housing
I've now established that it is definitely nothing to do with the shutter.
It is either the lens itelf, or the alignment of the lens.
I haven't seen it mentioned yet, but there is a solenoid that operates the shutter. I recall that the solenoid is continuously active and holding the shutter open while the camera is operating, rather than the expected reverse situation where the solenoid activates momentarily to close the shutter when commanded. If the solenoid is continuously activated, could this not be a source of heat close to the optical assembly? Could it even be warming up the shutter in an uneven way?No - heat is negligible. I have repeated the gradient using a substitute shutter comprising a strip of plastic manually removed from in front of the sensor.
I don't know why Mike ruled out the shutter.- yes it's seeing a static scene, so when it thinks it's done a cal, it's subtracting the image form itself, giving ablank field.
After being on for a while, if I force the shutter open and point it down, the blob disappears.
After forcing it close for a while if I release it and let it operate normally and point it down, it's as bad as it gets.the issue is that the "blank field" of the shutter-closed image is different from that of a blank field through the lens.
Shutter is visible here, it's the hook shape that's green in front of the lens housing. Obviously much warmer than the lens housingBear in mind shutter is black plastic, lens housing is metal with white paint on it, so at least some of the difference could be down to emissivity.
That microbolometer still looks hotter than I would have expected but interestingly there is no evidence of a hot spot on the rear of the PCB under the microbolometer.Don't hold your breath. They've not exactly been very communicative to date
It will be very interesting to hear SEEKs thoughts on this matter, hopefully tomorrow.
Aurora
That microbolometer still looks hotter than I would have expected but interestingly there is no evidence of a hot spot on the rear of the PCB under the microbolometer.
It will be very interesting to hear SEEKs thoughts on this matter, hopefully tomorrow.
Aurora
After being on for a while and the shutter forced open if I force it close, the image is less even but not terrible:Which LUT are you using? Is it possible in Seek Thermal app disable any LUTs and get grey output?
The shutter arm may also conduct away heat from that part of the flag.Talking about DIY shutter I was thinking about one... without any physical connection with PCB >:D
New app version was released on the 24th:
https://play.google.com/store/apps/details?id=com.tyriansystems.SeekThermal (https://play.google.com/store/apps/details?id=com.tyriansystems.SeekThermal)
What's new:
* Corrected crashing issues on various devices.
* Image quality improvements.
* Other misc. Improvements.
Can someone confirm if it has a firmware upgrade?
Image has new firmware built Oct 21.
#if AVERAGE
int[] deadpixelarray = { 10, 6, 2, 13, 9, 5, 1, 12, 8, 4, 0, 11, 7, 3, 14 };
int deadpixel;
ulong average;
ulong numpoints;
int v;
for (y = 0; y < 156; y++)
{
deadpixel = deadpixelarray[y % 15];
for (int x = 0; x < 208; x++)
{
if (x == deadpixel)
{
average = 0UL;
numpoints = 0;
if (x > 0)
{
average += data.PixelData[c - 1];
numpoints++;
}
if (x < 208)
{
average += data.PixelData[c + 1];
numpoints++;
}
if (y > 0)
{
average += data.PixelData[c - 208];
numpoints++;
}
if (y < 155)
{
average += data.PixelData[c + 208];
numpoints++;
}
if (numpoints > 0)
average = average / numpoints;
else
average = data.MinValue;
v = (int)average;
deadpixel += 15;
}
else
{
v = data.PixelData[c];
}
v = (v - data.MinValue) * 255 / (data.MaxValue - data.MinValue);
if (v < 0) v = 0;
if (v > 255) v = 255;
bmp.SetPixel(x, y, Color.FromArgb(v, v, v));
c++;
}
}
#else
for (y = 0; y < 156; y++)
{
for (int x = 0; x < 208; x++)
{
int v = data.PixelData[c++];
v = (v - data.MinValue) * 255 / (data.MaxValue - data.MinValue);
if (v < 0) v = 0;
if (v > 255) v = 255;
bmp.SetPixel(x, y, Color.FromArgb(v, v, v));
}
}
#endif
Edit: got rid off an unused variable and defaulted the dead pixel to min value instead of max value if it couldn't average (but that should never happen anyways)https://github.com/sgstair/winusbdotnetSo, those 3 images on screen shoots provided by @marshallh are NOT exactly raw sensor data but you modify its values, for example those non hexagon pixels somehow and change from 14bit to 8bit to be able to render it in RGBA mode?
I still have some plans to improve it, at the moment it's just doing very dumb calibration on the raw data and rendering it.
New app version was released on the 24th:..and upload an .apk...?
https://play.google.com/store/apps/details?id=com.tyriansystems.SeekThermal
What's new:
* Corrected crashing issues on various devices.
* Image quality improvements.
* Other misc. Improvements.
Can someone confirm if it has a firmware upgrade?
if (bmpQueue.Count > 3) bmpQueue.Dequeue();
it was > 5 //get image
Bitmap sourceImg = new Bitmap(@"C:\temp\thermo\seek.png");
Color leftPixel, centerPixel, rightPixel, topPixel, bottomPixel;
int avgVal;
//loop trough horiz pixels
for (int x = 0; x < sourceImg.Width-2; x++)
{
for (int y = 0; y < sourceImg.Height-2; y++)
{
leftPixel = sourceImg.GetPixel(x, y + 1);
rightPixel = sourceImg.GetPixel(x + 2, y + 1);
topPixel = sourceImg.GetPixel(x + 1, y);
bottomPixel = sourceImg.GetPixel(x + 1, y + 2);
centerPixel = sourceImg.GetPixel(x + 1, y + 1);
avgVal = (leftPixel.R + rightPixel.R + topPixel.R + bottomPixel.R) / 4;
if (Math.Abs(leftPixel.R - centerPixel.R) > 20) //if pixel is too different use average color from near pixels
{
sourceImg.SetPixel(x + 1, y + 1, Color.FromArgb(avgVal, avgVal, avgVal));
}
}
}
sourceImg.Save(Application.StartupPath + "\\clear.png");I was able to remove most of the dead pixels with this simple (C#) code:
//must include: using System.Linq;
//set level of the noise reduction:
int noiseReduction = 25; //smaller number means less noise but also less details, 25 seems to be a good value
//get image
Bitmap sourceImg = new Bitmap(@"C:\temp\thermo\seek.png");
Color centerPixel;
int avgVal;
int[] arrColor = new int[4];
//loop trough pixels
for (int x = 0; x < sourceImg.Width-2; x++)
{
for (int y = 0; y < sourceImg.Height-2; y++)
{
arrColor[0] = sourceImg.GetPixel(x, y + 1).R;
arrColor[1] = sourceImg.GetPixel(x + 2, y + 1).R;
arrColor[2] = sourceImg.GetPixel(x + 1, y).R;
arrColor[3] = sourceImg.GetPixel(x + 1, y + 2).R;
//get average value, but exclude neighbour dead pixels from average:
avgVal = (arrColor.Sum() - (arrColor.Min() + arrColor.Max())) / 2;
centerPixel = sourceImg.GetPixel(x + 1, y + 1);
if (Math.Abs(avgVal - centerPixel.R) > noiseReduction) //if pixel is too different use average color from near pixels
{
sourceImg.SetPixel(x + 1, y + 1, Color.FromArgb(avgVal, avgVal, avgVal));
}
}
}
sourceImg.Save(Application.StartupPath + "\\clear.png");
(https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/?action=dlattach;attach=115052;image)
It works on a standard USB 2.0 port but you have to install the winusb driver with ZadigNice :-+
On another note, brute force approach to add the Iron palette directly to the code, I know I could have just make it so it will read a file with the palette but meh. Notepad++ helped meI used libPNG to generate automatic code to include into C source file, so make it available using JNI in Android application, or generate output for OpenCV, and of course optimize it for speed ;)
#ifndef _SEEK_THERMAL_LUT_IRON256_C_
#define _SEEK_THERMAL_LUT_IRON256_C_
void seek_thermal_lut_iron256_get(unsigned int idx, unsigned char *pr, unsigned char *pg, unsigned char *pb ) {
static unsigned char *lutr= NULL;
static unsigned char *lutg= NULL;
static unsigned char *lutb= NULL;
if(lutr==NULL || lutg==NULL || lutb==NULL ) {
lutr=(unsigned char*)malloc(sizeof(unsigned char)*256);
lutg=(unsigned char*)malloc(sizeof(unsigned char)*256);
lutb=(unsigned char*)malloc(sizeof(unsigned char)*256);
lutr[0]= 0; lutg[0]= 0; lutb[0]= 0;
lutr[1]= 0; lutg[1]= 0; lutb[1]= 7;
lutr[2]= 0; lutg[2]= 0; lutb[2]= 24;
lutr[3]= 0; lutg[3]= 0; lutb[3]= 38;
lutr[4]= 0; lutg[4]= 0; lutb[4]= 46;
lutr[5]= 0; lutg[5]= 0; lutb[5]= 52;
lutr[6]= 0; lutg[6]= 0; lutb[6]= 59;
lutr[7]= 0; lutg[7]= 0; lutb[7]= 66;
lutr[8]= 0; lutg[8]= 0; lutb[8]= 73;
lutr[9]= 0; lutg[9]= 0; lutb[9]= 80;
lutr[10]= 1; lutg[10]= 0; lutb[10]= 85;
lutr[11]= 2; lutg[11]= 0; lutb[11]= 89;
lutr[12]= 3; lutg[12]= 0; lutb[12]= 93;
lutr[13]= 4; lutg[13]= 0; lutb[13]= 97;
lutr[14]= 5; lutg[14]= 0; lutb[14]= 101;
lutr[15]= 6; lutg[15]= 0; lutb[15]= 104;
lutr[16]= 8; lutg[16]= 0; lutb[16]= 108;
lutr[17]= 10; lutg[17]= 0; lutb[17]= 112;
lutr[18]= 11; lutg[18]= 0; lutb[18]= 116;
lutr[19]= 13; lutg[19]= 0; lutb[19]= 118;
lutr[20]= 15; lutg[20]= 0; lutb[20]= 119;
lutr[21]= 17; lutg[21]= 0; lutb[21]= 121;
lutr[22]= 20; lutg[22]= 0; lutb[22]= 123;
lutr[23]= 24; lutg[23]= 0; lutb[23]= 126;
lutr[24]= 27; lutg[24]= 0; lutb[24]= 128;
lutr[25]= 30; lutg[25]= 0; lutb[25]= 130;
lutr[26]= 33; lutg[26]= 0; lutb[26]= 133;
lutr[27]= 36; lutg[27]= 0; lutb[27]= 135;
lutr[28]= 40; lutg[28]= 0; lutb[28]= 136;
lutr[29]= 43; lutg[29]= 0; lutb[29]= 138;
lutr[30]= 47; lutg[30]= 0; lutb[30]= 139;
lutr[31]= 50; lutg[31]= 0; lutb[31]= 141;
lutr[32]= 53; lutg[32]= 0; lutb[32]= 142;
lutr[33]= 56; lutg[33]= 0; lutb[33]= 144;
lutr[34]= 59; lutg[34]= 0; lutb[34]= 145;
lutr[35]= 62; lutg[35]= 0; lutb[35]= 146;
lutr[36]= 64; lutg[36]= 0; lutb[36]= 148;
lutr[37]= 66; lutg[37]= 0; lutb[37]= 149;
lutr[38]= 69; lutg[38]= 0; lutb[38]= 150;
lutr[39]= 72; lutg[39]= 0; lutb[39]= 150;
lutr[40]= 75; lutg[40]= 0; lutb[40]= 150;
lutr[41]= 78; lutg[41]= 0; lutb[41]= 151;
lutr[42]= 81; lutg[42]= 0; lutb[42]= 151;
lutr[43]= 83; lutg[43]= 0; lutb[43]= 152;
lutr[44]= 87; lutg[44]= 0; lutb[44]= 152;
lutr[45]= 90; lutg[45]= 0; lutb[45]= 153;
lutr[46]= 93; lutg[46]= 0; lutb[46]= 154;
lutr[47]= 96; lutg[47]= 0; lutb[47]= 155;
lutr[48]= 99; lutg[48]= 0; lutb[48]= 155;
lutr[49]= 102; lutg[49]= 0; lutb[49]= 155;
lutr[50]= 105; lutg[50]= 0; lutb[50]= 155;
lutr[51]= 108; lutg[51]= 0; lutb[51]= 156;
lutr[52]= 111; lutg[52]= 0; lutb[52]= 156;
lutr[53]= 113; lutg[53]= 0; lutb[53]= 157;
lutr[54]= 115; lutg[54]= 0; lutb[54]= 157;
lutr[55]= 119; lutg[55]= 0; lutb[55]= 157;
lutr[56]= 122; lutg[56]= 0; lutb[56]= 157;
lutr[57]= 125; lutg[57]= 0; lutb[57]= 157;
lutr[58]= 128; lutg[58]= 0; lutb[58]= 157;
lutr[59]= 130; lutg[59]= 0; lutb[59]= 157;
lutr[60]= 133; lutg[60]= 0; lutb[60]= 157;
lutr[61]= 136; lutg[61]= 0; lutb[61]= 157;
lutr[62]= 138; lutg[62]= 0; lutb[62]= 157;
lutr[63]= 141; lutg[63]= 0; lutb[63]= 157;
lutr[64]= 144; lutg[64]= 0; lutb[64]= 156;
lutr[65]= 147; lutg[65]= 0; lutb[65]= 156;
lutr[66]= 150; lutg[66]= 0; lutb[66]= 155;
lutr[67]= 153; lutg[67]= 0; lutb[67]= 155;
lutr[68]= 155; lutg[68]= 0; lutb[68]= 155;
lutr[69]= 157; lutg[69]= 0; lutb[69]= 155;
lutr[70]= 160; lutg[70]= 0; lutb[70]= 155;
lutr[71]= 162; lutg[71]= 0; lutb[71]= 155;
lutr[72]= 164; lutg[72]= 0; lutb[72]= 155;
lutr[73]= 167; lutg[73]= 0; lutb[73]= 154;
lutr[74]= 169; lutg[74]= 0; lutb[74]= 154;
lutr[75]= 171; lutg[75]= 0; lutb[75]= 153;
lutr[76]= 172; lutg[76]= 0; lutb[76]= 153;
lutr[77]= 174; lutg[77]= 1; lutb[77]= 152;
lutr[78]= 176; lutg[78]= 1; lutb[78]= 152;
lutr[79]= 177; lutg[79]= 1; lutb[79]= 151;
lutr[80]= 179; lutg[80]= 1; lutb[80]= 151;
lutr[81]= 181; lutg[81]= 2; lutb[81]= 150;
lutr[82]= 183; lutg[82]= 2; lutb[82]= 149;
lutr[83]= 184; lutg[83]= 3; lutb[83]= 149;
lutr[84]= 185; lutg[84]= 4; lutb[84]= 149;
lutr[85]= 187; lutg[85]= 5; lutb[85]= 148;
lutr[86]= 188; lutg[86]= 5; lutb[86]= 147;
lutr[87]= 190; lutg[87]= 5; lutb[87]= 146;
lutr[88]= 191; lutg[88]= 6; lutb[88]= 146;
lutr[89]= 192; lutg[89]= 7; lutb[89]= 145;
lutr[90]= 193; lutg[90]= 8; lutb[90]= 144;
lutr[91]= 194; lutg[91]= 9; lutb[91]= 143;
lutr[92]= 195; lutg[92]= 11; lutb[92]= 142;
lutr[93]= 196; lutg[93]= 12; lutb[93]= 141;
lutr[94]= 197; lutg[94]= 13; lutb[94]= 140;
lutr[95]= 199; lutg[95]= 14; lutb[95]= 138;
lutr[96]= 200; lutg[96]= 16; lutb[96]= 136;
lutr[97]= 201; lutg[97]= 18; lutb[97]= 134;
lutr[98]= 202; lutg[98]= 19; lutb[98]= 133;
lutr[99]= 203; lutg[99]= 20; lutb[99]= 131;
lutr[100]= 205; lutg[100]= 22; lutb[100]= 129;
lutr[101]= 206; lutg[101]= 23; lutb[101]= 127;
lutr[102]= 207; lutg[102]= 25; lutb[102]= 124;
lutr[103]= 208; lutg[103]= 26; lutb[103]= 121;
lutr[104]= 209; lutg[104]= 27; lutb[104]= 119;
lutr[105]= 210; lutg[105]= 29; lutb[105]= 116;
lutr[106]= 211; lutg[106]= 31; lutb[106]= 114;
lutr[107]= 212; lutg[107]= 33; lutb[107]= 112;
lutr[108]= 213; lutg[108]= 34; lutb[108]= 108;
lutr[109]= 214; lutg[109]= 36; lutb[109]= 104;
lutr[110]= 215; lutg[110]= 38; lutb[110]= 101;
lutr[111]= 216; lutg[111]= 40; lutb[111]= 98;
lutr[112]= 217; lutg[112]= 42; lutb[112]= 95;
lutr[113]= 218; lutg[113]= 45; lutb[113]= 92;
lutr[114]= 219; lutg[114]= 47; lutb[114]= 87;
lutr[115]= 220; lutg[115]= 48; lutb[115]= 82;
lutr[116]= 221; lutg[116]= 49; lutb[116]= 77;
lutr[117]= 222; lutg[117]= 51; lutb[117]= 71;
lutr[118]= 223; lutg[118]= 53; lutb[118]= 65;
lutr[119]= 224; lutg[119]= 55; lutb[119]= 60;
lutr[120]= 224; lutg[120]= 56; lutb[120]= 54;
lutr[121]= 225; lutg[121]= 58; lutb[121]= 49;
lutr[122]= 226; lutg[122]= 60; lutb[122]= 43;
lutr[123]= 227; lutg[123]= 62; lutb[123]= 37;
lutr[124]= 228; lutg[124]= 63; lutb[124]= 32;
lutr[125]= 228; lutg[125]= 65; lutb[125]= 28;
lutr[126]= 229; lutg[126]= 67; lutb[126]= 26;
lutr[127]= 230; lutg[127]= 69; lutb[127]= 24;
lutr[128]= 230; lutg[128]= 71; lutb[128]= 21;
lutr[129]= 231; lutg[129]= 73; lutb[129]= 19;
lutr[130]= 232; lutg[130]= 75; lutb[130]= 17;
lutr[131]= 232; lutg[131]= 76; lutb[131]= 15;
lutr[132]= 233; lutg[132]= 77; lutb[132]= 13;
lutr[133]= 234; lutg[133]= 78; lutb[133]= 12;
lutr[134]= 235; lutg[134]= 80; lutb[134]= 11;
lutr[135]= 235; lutg[135]= 82; lutb[135]= 10;
lutr[136]= 235; lutg[136]= 84; lutb[136]= 9;
lutr[137]= 236; lutg[137]= 86; lutb[137]= 8;
lutr[138]= 236; lutg[138]= 88; lutb[138]= 8;
lutr[139]= 237; lutg[139]= 90; lutb[139]= 7;
lutr[140]= 237; lutg[140]= 91; lutb[140]= 6;
lutr[141]= 238; lutg[141]= 92; lutb[141]= 5;
lutr[142]= 238; lutg[142]= 94; lutb[142]= 5;
lutr[143]= 239; lutg[143]= 95; lutb[143]= 4;
lutr[144]= 239; lutg[144]= 97; lutb[144]= 4;
lutr[145]= 240; lutg[145]= 99; lutb[145]= 3;
lutr[146]= 240; lutg[146]= 101; lutb[146]= 3;
lutr[147]= 241; lutg[147]= 102; lutb[147]= 3;
lutr[148]= 241; lutg[148]= 103; lutb[148]= 3;
lutr[149]= 241; lutg[149]= 105; lutb[149]= 2;
lutr[150]= 241; lutg[150]= 106; lutb[150]= 2;
lutr[151]= 241; lutg[151]= 108; lutb[151]= 1;
lutr[152]= 242; lutg[152]= 109; lutb[152]= 1;
lutr[153]= 242; lutg[153]= 111; lutb[153]= 1;
lutr[154]= 243; lutg[154]= 113; lutb[154]= 1;
lutr[155]= 243; lutg[155]= 114; lutb[155]= 1;
lutr[156]= 244; lutg[156]= 116; lutb[156]= 0;
lutr[157]= 244; lutg[157]= 117; lutb[157]= 0;
lutr[158]= 244; lutg[158]= 119; lutb[158]= 0;
lutr[159]= 244; lutg[159]= 121; lutb[159]= 0;
lutr[160]= 245; lutg[160]= 124; lutb[160]= 0;
lutr[161]= 245; lutg[161]= 126; lutb[161]= 0;
lutr[162]= 246; lutg[162]= 128; lutb[162]= 0;
lutr[163]= 246; lutg[163]= 130; lutb[163]= 0;
lutr[164]= 247; lutg[164]= 131; lutb[164]= 0;
lutr[165]= 247; lutg[165]= 133; lutb[165]= 0;
lutr[166]= 248; lutg[166]= 135; lutb[166]= 0;
lutr[167]= 248; lutg[167]= 136; lutb[167]= 0;
lutr[168]= 248; lutg[168]= 137; lutb[168]= 0;
lutr[169]= 248; lutg[169]= 139; lutb[169]= 0;
lutr[170]= 248; lutg[170]= 140; lutb[170]= 0;
lutr[171]= 249; lutg[171]= 142; lutb[171]= 0;
lutr[172]= 249; lutg[172]= 143; lutb[172]= 0;
lutr[173]= 249; lutg[173]= 144; lutb[173]= 0;
lutr[174]= 249; lutg[174]= 146; lutb[174]= 0;
lutr[175]= 250; lutg[175]= 148; lutb[175]= 0;
lutr[176]= 250; lutg[176]= 150; lutb[176]= 0;
lutr[177]= 251; lutg[177]= 152; lutb[177]= 0;
lutr[178]= 251; lutg[178]= 155; lutb[178]= 0;
lutr[179]= 252; lutg[179]= 157; lutb[179]= 0;
lutr[180]= 252; lutg[180]= 159; lutb[180]= 0;
lutr[181]= 253; lutg[181]= 161; lutb[181]= 0;
lutr[182]= 253; lutg[182]= 163; lutb[182]= 0;
lutr[183]= 253; lutg[183]= 166; lutb[183]= 0;
lutr[184]= 253; lutg[184]= 168; lutb[184]= 0;
lutr[185]= 253; lutg[185]= 170; lutb[185]= 0;
lutr[186]= 253; lutg[186]= 172; lutb[186]= 0;
lutr[187]= 253; lutg[187]= 174; lutb[187]= 0;
lutr[188]= 254; lutg[188]= 175; lutb[188]= 0;
lutr[189]= 254; lutg[189]= 177; lutb[189]= 0;
lutr[190]= 254; lutg[190]= 178; lutb[190]= 0;
lutr[191]= 254; lutg[191]= 180; lutb[191]= 0;
lutr[192]= 254; lutg[192]= 183; lutb[192]= 0;
lutr[193]= 254; lutg[193]= 185; lutb[193]= 0;
lutr[194]= 254; lutg[194]= 186; lutb[194]= 0;
lutr[195]= 254; lutg[195]= 188; lutb[195]= 0;
lutr[196]= 254; lutg[196]= 189; lutb[196]= 0;
lutr[197]= 254; lutg[197]= 191; lutb[197]= 0;
lutr[198]= 254; lutg[198]= 193; lutb[198]= 0;
lutr[199]= 254; lutg[199]= 195; lutb[199]= 0;
lutr[200]= 254; lutg[200]= 197; lutb[200]= 0;
lutr[201]= 254; lutg[201]= 199; lutb[201]= 0;
lutr[202]= 254; lutg[202]= 200; lutb[202]= 0;
lutr[203]= 254; lutg[203]= 202; lutb[203]= 1;
lutr[204]= 254; lutg[204]= 203; lutb[204]= 1;
lutr[205]= 254; lutg[205]= 204; lutb[205]= 2;
lutr[206]= 254; lutg[206]= 206; lutb[206]= 3;
lutr[207]= 254; lutg[207]= 207; lutb[207]= 4;
lutr[208]= 254; lutg[208]= 209; lutb[208]= 6;
lutr[209]= 254; lutg[209]= 211; lutb[209]= 8;
lutr[210]= 254; lutg[210]= 213; lutb[210]= 10;
lutr[211]= 254; lutg[211]= 215; lutb[211]= 11;
lutr[212]= 254; lutg[212]= 216; lutb[212]= 12;
lutr[213]= 255; lutg[213]= 218; lutb[213]= 14;
lutr[214]= 255; lutg[214]= 219; lutb[214]= 16;
lutr[215]= 255; lutg[215]= 220; lutb[215]= 19;
lutr[216]= 255; lutg[216]= 221; lutb[216]= 23;
lutr[217]= 255; lutg[217]= 222; lutb[217]= 27;
lutr[218]= 255; lutg[218]= 224; lutb[218]= 31;
lutr[219]= 255; lutg[219]= 225; lutb[219]= 35;
lutr[220]= 255; lutg[220]= 227; lutb[220]= 38;
lutr[221]= 255; lutg[221]= 228; lutb[221]= 42;
lutr[222]= 255; lutg[222]= 229; lutb[222]= 48;
lutr[223]= 255; lutg[223]= 230; lutb[223]= 53;
lutr[224]= 255; lutg[224]= 231; lutb[224]= 60;
lutr[225]= 255; lutg[225]= 233; lutb[225]= 65;
lutr[226]= 255; lutg[226]= 234; lutb[226]= 71;
lutr[227]= 255; lutg[227]= 235; lutb[227]= 77;
lutr[228]= 255; lutg[228]= 237; lutb[228]= 83;
lutr[229]= 255; lutg[229]= 238; lutb[229]= 89;
lutr[230]= 255; lutg[230]= 239; lutb[230]= 96;
lutr[231]= 255; lutg[231]= 239; lutb[231]= 102;
lutr[232]= 255; lutg[232]= 240; lutb[232]= 109;
lutr[233]= 255; lutg[233]= 241; lutb[233]= 115;
lutr[234]= 255; lutg[234]= 241; lutb[234]= 124;
lutr[235]= 255; lutg[235]= 242; lutb[235]= 132;
lutr[236]= 255; lutg[236]= 243; lutb[236]= 139;
lutr[237]= 255; lutg[237]= 244; lutb[237]= 146;
lutr[238]= 255; lutg[238]= 244; lutb[238]= 153;
lutr[239]= 255; lutg[239]= 245; lutb[239]= 160;
lutr[240]= 255; lutg[240]= 245; lutb[240]= 168;
lutr[241]= 255; lutg[241]= 246; lutb[241]= 175;
lutr[242]= 255; lutg[242]= 247; lutb[242]= 181;
lutr[243]= 255; lutg[243]= 248; lutb[243]= 187;
lutr[244]= 255; lutg[244]= 248; lutb[244]= 193;
lutr[245]= 255; lutg[245]= 249; lutb[245]= 198;
lutr[246]= 255; lutg[246]= 249; lutb[246]= 204;
lutr[247]= 255; lutg[247]= 250; lutb[247]= 210;
lutr[248]= 255; lutg[248]= 251; lutb[248]= 216;
lutr[249]= 255; lutg[249]= 252; lutb[249]= 222;
lutr[250]= 255; lutg[250]= 253; lutb[250]= 227;
lutr[251]= 255; lutg[251]= 253; lutb[251]= 232;
lutr[252]= 255; lutg[252]= 254; lutb[252]= 237;
lutr[253]= 255; lutg[253]= 254; lutb[253]= 243;
lutr[254]= 255; lutg[254]= 255; lutb[254]= 247;
lutr[255]= 255; lutg[255]= 255; lutb[255]= 249;
}
(*pr)= lutr[idx];
(*pg)= lutg[idx];
(*pb)= lutb[idx];
}
unsigned int seek_thermal_lut_iron256_size() {
return 256;
}
#endif //_SEEK_THERMAL_LUT_IRON256_C_
If you got the order in fairly early, and it arrives soon-ish chances are you can flip it on ebay for a profit. Looking at their FB page seems the order numbers are well over 10K
The 2nd unit I simply don't want at all and there doesn't seem to be a way to canc the order.I would be very happy to buy it from you if it's android version and you would be willing to ship it to Europe?
I definitely wouldn't expect unprocessed data. They have to maintain the 9hz to make their camera ITAR safe.Why not? They can simply make toy version hardware eg. with voltage regulators operating temperature 0*C-70*C or use ICs in non MIL versions as well as simplify design and make this thing not usable on battle fields.
Sure thing, but I have more to come, double the resolution and frenky's noise reduction.Still, you have guys black pixels column on the right >:D
https://www.youtube.com/watch?v=hzsTsFvHss8 (https://www.youtube.com/watch?v=hzsTsFvHss8#ws)
ZnSe CO2 laser focus lens. these are either Biconvex or Plano Convex. Both will work OK. Plano Convex is likely the best performingThx for those hints ;)
...
ZnSe lense are common in certain thermal camera optics as a high transmission efficiency and relatively cheap element.
I'm looking forward to seeing what people come up with on the firmware, perhaps the real value is there.My guess is that next @Mike's teardown Seek Thermal video might be... applying logic analyser to a few of these 18 wires close to the sensor and hacking its communication protocol, while it survived milling and complete lens disassembling and still outputs some decent thermal imaginery :-DD
@miguelvp, I'd add a button control to the form in the UI editor and double click on it to create a new event handler. If you really want the keyboard, in the UI editor properties window, the events tab will let you hook a KeyPress event (or in Form1(), this.KeyPress += <event function>; MSDN has all the details.)
I'm ultimately going to seriously refactor a lot of this stuff, I have some things I'd like to add also.
My opinion for best way to dead pixel removal and noise control.
Dead pixel problem:
Take an image from thermally equal surface, convert it into black and white. Mark position of all dead pixels and replace it like this:
Get values from top, bottom, left and right neighbor pixel. Check which pair (horizontal or vertical) has smallest difference in color.
Calculated pixel should have the average value of this pair. This will work great on small vertical or horizontal changes in temperature.
(My code already implements this)
If you use multiple frames from a moving image then this should be possible in background without any need for a manual calibration:
- Detect dead pixels as you described
- Filter the dead pixel map over several frames, but update only when the image is changing (to avoid false masking of good pixels in static scenes)
- Use the generated dead pixel mask to clean the image
It should be even possible to compensate hot pixels (pixels that are not completely dead but have a significant difference in gain, so they can not be compensated with the shutter).
Maybe it could be even possible to predict the drift between shutter calibrations and remove the remaining nonuniformity.
I would not convert the data to 8bit before applying the palette: The hot metal palette allows to display about 1024 different colours. Especially after scaling the image to double size, this gives a much more smooth display and shows more details than rounding to 8bit.Yep, I used this Iron palette at size 256 so far, ONLY for the reason that any sensor available raw data provided there I was able to obtain was from those images included in this thread and they are degraded to RGBA 8bit per channel, but in my libseekthermal.so.1.01 I use DOUBLE matrix in image processing operations, so with acceess to oryginal 14bit sensor data it is easy to convert them to double, make image processing enhancements and then take for example 10bit palette so about 1024 palette size not 256.
void seek_thermal_lut_iron256_get(unsigned int idx, unsigned char *pr, unsigned char *pg, unsigned char *pb );
unsigned int seek_thermal_lut_iron256_size();
Mike,If that was the case, the effect would be the same with the shutter open or closed.
Regarding the temperature gradient issue.
I thought he same as you when I saw teh small aperture at the rear of the lens 'tube'. I am slo considering the eefect that may be caused when teh lens 'tube' touches teh microbolometer on one side as appeared to be the case in your video.
If the lens tube is warmer than the microbolometer, contact between teh two could potentially cause a localised heat transfer into the microbolometer. The area in contact and adjacent would be warmed but the opposite side of the microbolometer is adjacent to the shutter access hole and may stay cooler as a result due to air cooling. As the camera warms up, teh lens tube may continue to rise in temperature and cause greater temperature differential impact on teh microbolometer. Just a thought.
Aurora
I only skimmed though the video, but from my experience with superresolution (both as final product embedded in a digital camera and playing with some algorithms) it works in theory but is not really good for practical usage except with a lot of manual tweaking for each scene.The man having the lecture was obviously involved in developing this feature in TESTO thermal cameras:
I've been playing with it too and results are encouraging. (See attachement)Wow, that looks great! The resolution fits, but they look too good to be images from the seek camera.
No they aren't because I don't have the module yet.That is exactly what most people do: Taking an image, resizing it and using superresolution to recreate the original file. This works well, but with real images it gets hard.
What I have done:
- resize all 4 images to 50%
There seem t be happy customers there and pictures look pretty reasonable for $199 !Did you saw this comment by "Louis Rigo Jr" :-DD
How about you stop trying to sell and give iPhone users an update!?!
Update: Raster of 8x8 pixels cleary visible and it does not look better than simply linear resize I used from 208x156 to higher 832x624 >:DThe 8x8 blocks are probably due to jpeg compression, they are also on the visible image.
I decided to give SEEK a small 'prod in the ribs' and publicly ask them to comment on the thermal gradient, noise, dead pixel count and their lack of response to email on the topic. It may be a bit mean of me to out the issues on Facebook but SEEK need to improve their attitude and communications if they are to be a competitor in the thermal camera marketplace. I would have expected Ex Indigo employees to know that already. Sometimes you have to be cruel to be kind.
Fraser
Its obvious they have done heavy post processing to make the image look good enough to sell to consumers.Thx for this link.
The 8x8 blocks are probably due to jpeg compressionLater realized that too and missed it's not PNG when investigated this ;)
Seek Thermal has been following this thread with great interest. We would like to be as transparent as possible, ...
Thank you again for your interest in our product, we look forward to continuing our dialogue with the community.
Best,
The Seek Thermal Team
Dark Pixels. No great mystery here. Every 15th pixel is intentionally blanked to avoid a potential patent infringement.I'm really curious to know what patent claim this works around - Flir (I presume it's them!) have a lot of patents to comb through though....
Dark Pixels.There is close to 7% such useless black pixels, so it might affect image quality depending on application :-DMM
...
With the effective blur length of a 12 micron pixel resolving 8-13 micron Radiation, loss of single isolated pixels does not (in itself) degrade image quality.
Seconded; if anything I'd think that specific pattern of black pixels was a patented technique for something like calibration as suggested earlier, and a sensor with all functional pixels would be too obvious to patent. But then again, I'm not so surprised, given the absurdity of some of the patents out there.Dark Pixels. No great mystery here. Every 15th pixel is intentionally blanked to avoid a potential patent infringement.I'm really curious to know what patent claim this works around - Flir (I presume it's them!) have a lot of patents to comb through though....
Could be something really silly like "a contiguous array of 15 or more pixels"...Seconded; if anything I'd think that specific pattern of black pixels was a patented technique for something like calibration as suggested earlier, and a sensor with all functional pixels would be too obvious to patent. But then again, I'm not so surprised, given the absurdity of some of the patents out there.Dark Pixels. No great mystery here. Every 15th pixel is intentionally blanked to avoid a potential patent infringement.I'm really curious to know what patent claim this works around - Flir (I presume it's them!) have a lot of patents to comb through though....
Hello, we are not alone in this thread ;)Dark Pixels.There is close to 7% such useless black pixels, so it might affect image quality depending on application :-DMM
...
With the effective blur length of a 12 micron pixel resolving 8-13 micron Radiation, loss of single isolated pixels does not (in itself) degrade image quality.
BTW: Maybe, It could be nice to send each EEVblog member in this thread who made some effort and wrote more than 3 posts there, brand new Seek Thermal for teardown with latest software on CD/DVD ? >:D
OK-software not so important, one can write his own, but Seek experimental hardware dongle from Santa Claus to European EEVblog fans banned so far from official relase could be a very nice surprise and clear evidence that really Seek Thermal Team is there on EEVblog ::)
I could for example test my Linux version of Seek Thermal app on real hardware, not only on USB sniffied 8bit channel RGBA PNG's :D
It is probably more difficult to compensate. From mike's video it seems to be dependend on the temperature: If the measured temperature is at the same temperature as the lens assembly, there is almost no gradient, but looking at a much warmer or colder object, the gradient gets more pronounced.
@Hyperion
Considering the temperature span of about 100°C the gradient looks much worse than 2-3°C in your image, more like 10-20°C.
The reason why it is important to me is because my main purpose for this device is to simply scan my immedieate area for life (humans and/or animals) while I go on night hikes using NOD. I hike in an area with wildlife and it freaks me out when I hear something rattling the leaves.
The reason why it is important to me is because my main purpose for this device is to simply scan my immedieate area for life (humans and/or animals) while I go on night hikes using NOD. I hike in an area with wildlife and it freaks me out when I hear something rattling the leaves.
The gradient issue is really only a problem for people using the camera for commercial applications like heat leak or moisture inspections, electronics thermal characteristics, or anything that needs a very flat field. Scanning for signs of life (hunters, security, front lines combat) isn't so much affected by a gradient. Which this sensor, even if somewhat handicapped, does effortlessly. If all you are after is detection of a somewhat warmer object from its surroundings, the minimal gradient shouldn't cause any problems. Its really more of annoyance that debilitating. I think this whole design is full of win, and it seems more than adequate...but I think there's plenty of juice left in the lemons.
The inherent issue with this forum is that it brings together a lot of experts and "tech tweakers" who will not be happy until they have a FLIR E8 equivalent device for $200 or a camera that outputs something like this (NSFW?)I'm happy with this MLX90614 Digital, plug & play, infrared thermometer in a TO-can (http://www.melexis.com/Infrared-Thermometer-Sensors/Infrared-Thermometer-Sensors/MLX90614-615.aspx)
"Factory calibrated in wide temperature range: -40 to 125 °C for sensor temperature and -70 to 380 °C for object temperature."while it costs <$10 and by adding a few low cost components I can detect easy and quickly and what is the most important without any temperature gradients energy losses in house as well as find hot places on ground and do many other things which are not possible to do with device like Seek Thermal, when it has such huge hardware issue like this weird gradient, which makes this thermal camera simply NOT RELIABLE :o
Scanning for signs of life (hunters, security, front lines combat) isn't so much affected by a gradient.Not reliable thermal camera is more dangerous than no such thing at all-for example now some drivers with this toy can feel king of the roads and drive very fast in the dark, because of they... have night vision, but... due to many reasons this what they are able to see in different conditions will not be the same so can easy to miss... for example humans on the bike... etc....
A few other notes on the gradient issue:Tanks for measuring. That is interesting.
Item Seek L Seek H delta
Hot Water 120 127 7
notepad 72 79 7
deck 52 63 11
Milk 39 49 10
overcast sky 30 43 13
IceCream 19 32 13
BTW, the low temperature tended to be the most accurate.
3/A user selectable 'span' or equivalent to manual exposure/gain would be great. As a thermal imager for amateur search and rescue or animal 'life' detection'outdoors, the inclusion of a any part of a clear sky at night (with its v low temperature) causes the span to change dramatically. Without any sky in the image the Seek works well for this, but image say a tree, with gaps with sky showing between branches, and the span automatically changes so dramatically it becomes near useless to detect anything a few degrees above ambient.
It seems like heat is internally injected into the sensor.Answer is simply type in Google search "Seek Thermal gradient issue" and what we get?
...
I wonder how they plan to compensate that in software.
"Google is preparing a new tweak to its search engine to ensure that some of the most ‘notorious’ piracy sites are less likely to appear when people search for music, films and other copyrighted content."
Dear Seek Customers:
We apologize again for the delay in shipping cameras. We have had several unanticipated issues that prevented our production from ramping up as quickly as originally planned. We’ve been working closely with our manufacturing partner to address these issues in order to fulfill our backorders as soon as possible.
This is the first time that thermal cameras have been produced on a mass production line, and assembling, aligning, and calibrating the high tech lenses and sensors requires multiple unique steps that have taken longer than we anticipated to ramp up to full capacity. Our company and our manufacturer are both dedicated to continue to increase production as quickly as possible, and we will also be adding a third shift next week. With these measures, and given our current production trends, we hope to catch up with all of the backorders within the next few weeks.
There is an additional issue that is currently preventing us from shipping any further iOS cameras from our existing inventory. Prior to accepting any orders, our cameras received hardware approval from Apple. However, we have recently received unanticipated additional requests from Apple, which we are actively working on with them. We hope to resolve these issues quickly so we can resume shipping the iOS cameras we are now manufacturing and building inventory on.
Our number one priority is getting cameras out to our customers as quickly as possible over the next few weeks.
Statement on their FB pageMaybe I woke up in some kind of another weird parallel universe today somewhere in the future, where nobody can attach to device he payed piece of hardware made by someone else who knows how to do it than device manufacturer business partners?Quote...
Prior to accepting any orders, our cameras received hardware approval from Apple. However, we have recently received unanticipated additional requests from Apple, which we are actively working on with them.
...
Why Seek Thermal can not simply sell this dongle to iOS users as well as other target platforms with software on... yes old good times CD and provide this software for download on HIS OWN web pages? :wtf:
It looks like we a're back in the past at the origins of internet now, but even that time on news groups one could get what he wants even had to wait some time to download it, but probably much less than for any approvals :palm:
Isn't customers who payed for these crappy phones should decide if they want to buy this toy or return it back if it is not this what they want since they bought it via internet so had no chance to play with it in normal shop...
Apple currently refuses connections to Bluetooth devices that lack their authentication chip.
I believe keyboards are about the only generic, non Apple-taxed thing they will pair with.Apple currently refuses connections to Bluetooth devices that lack their authentication chip.
What does this mean? I have been able to pair a generic Bluetooth keyboard with my iDevices and it works fine.
Apple currently refuses connections to Bluetooth devices that lack their authentication chip.
Flir have a patent on that. there is also the issue of different positions and fields of view of cams on different phones. maybe someone will write an app for it though
3 - Poor display definition - with a built in visible light camera it would be easy to boost the apparent definition. For example perform edge detection on the visible light
and apply as an alpha channel to the IR display.
4 - Poor display contrast - this is seriously easy stuff to bump the contrast so details can be distinguished.I suspect this is a deliberate tactic to hide noise.
Apple is probably the most proprietary-centric consumer product manufacturer out there.Anyway, may be better if Seek Thermal will leave them alone with their greatness if they do not want to be involved in similar lawsuits and release PC version with drivers for Linux, Window$, etc for price <$100 :-DD
"GTAT is prohibited from modifying any equipment, specifications, manufacturing process or materials without Apple’s prior consent. Apple can modify any of these terms at any time and GTAT must immediately implement Apple’s modifications."Apple? No thanks :rant:
I found this vid comparing Seek with Therm-app. sorry if this is a not so smart question to ask as I don't have much thermal background (or anything else :palm:) With future software revisions, does anybody think its posbile for seek to look similar to therm app?Ther therm-app lens alone probably costs more than the Seek
http://youtu.be/5FvVJE-qLhw (http://youtu.be/5FvVJE-qLhw)
An update, I've just discovered that if I use the direct url for the Thermal App I can install it from New Zealand, even though a search on Google Play won't show it.
Direct url :https://play.google.com/store/apps/details?id=com.tyriansystems.SeekThermal&hl=en&rdid=com.tyriansystems.SeekThermal (https://play.google.com/store/apps/details?id=com.tyriansystems.SeekThermal&hl=en&rdid=com.tyriansystems.SeekThermal)
Didn't work for me - after the "please login to download" prompt I get "Page not found"Does APK Downloader help in those situations?
@Mike, URL works OK from my Moto G but no camera found for download. Not sure if you need the Seek plugged in to install ? My Seek has just arrived at its USA destinatiom so hopefully not long until I can test it.
Flir have a patent on that.
@Mike, URL works OK from my Moto G but no camera found for download. Not sure if you need the Seek plugged in to install ? My Seek has just arrived at its USA destinatiom so hopefully not long until I can test it.No - the app can be installed, and run in demo mode without the camera, at least when installing from a .apk file
Here's a thermie of my cat. Really shows the detail the camera can achieve.That doesn't look quite right unless it's an inverted palette... the eyes should be much hotter:
Here's a thermie of my cat. Really shows the detail the camera can achieve.That doesn't look quite right unless it's an inverted palette... the eyes should be much hotter:
http://traveldave.com/wp-content/uploads/2010/02/thermalcat2_sm.jpg (http://traveldave.com/wp-content/uploads/2010/02/thermalcat2_sm.jpg)
https://athermallife.files.wordpress.com/2012/02/cat.jpg (https://athermallife.files.wordpress.com/2012/02/cat.jpg)
http://cnet1.cbsistatic.com/hub/i/2014/01/07/7d42182c-8533-11e3-bc97-14feb5ca9861/208f1d19dc978f193aaa148996f169d7/flirone.jpg (http://cnet1.cbsistatic.com/hub/i/2014/01/07/7d42182c-8533-11e3-bc97-14feb5ca9861/208f1d19dc978f193aaa148996f169d7/flirone.jpg)
I found this vid comparing Seek with Therm-app. sorry if this is a not so smart question to ask as I don't have much thermal background (or anything else :palm:) With future software revisions, does anybody think its posbile for seek to look similar to therm app?
http://youtu.be/5FvVJE-qLhw (http://youtu.be/5FvVJE-qLhw)
I agree with Amyk. I do not expect the nose and the eyes to be the same value in a thermal image!Here's a thermie of my cat. Really shows the detail the camera can achieve.That doesn't look quite right unless it's an inverted palette... the eyes should be much hotter:
That is the "Black" pallet. Which is the inverse of "White".
In "black" hottest objects are darkest, so the cat looks as expected. I still think "Tyrian" is my favorite.
The cat does look a bit visible-spectrumy...
Also anyone owns both a TIC and a guinea pig? I'd like to see that...
The cat does look a bit visible-spectrumy...Cat simply could sleep, than many people reported even without thermal cameras that his nose will be warmer than usual and it doesn't have to mean that it is sick ;)
The cat does look a bit visible-spectrumy...
Also anyone owns both a TIC and a guinea pig? I'd like to see that...
The cat does look a bit visible-spectrumy...
Also anyone owns both a TIC and a guinea pig? I'd like to see that...
I assure you it was a real shot through the camera. And it wasn't post processed outside the seek app.
Close up lenses are used to provide detailed images of PCB's etc.
Close up lenses are used to provide detailed images of PCB's etc.
I've put up a simple holder for the 20mm ZnSe lenses over at Thingiverse. It's just a friction fit which depends on the asymmetry of the camera face to hold it in place, but it seems to do the trick. Should do well enough to keep handy in the toolbag. http://www.thingiverse.com/thing:525605 (http://www.thingiverse.com/thing:525605)
I think the security/surveillance people use the blackhot palette. The whitehot feels just so much more natural to me...
Close up lenses are used to provide detailed images of PCB's etc.
I've put up a simple holder for the 20mm ZnSe lenses over at Thingiverse. It's just a friction fit which depends on the asymmetry of the camera face to hold it in place, but it seems to do the trick. Should do well enough to keep handy in the toolbag. http://www.thingiverse.com/thing:525605 (http://www.thingiverse.com/thing:525605)
Weird thing about flatfield calibration...if i do the magnet trick, obviously it takes whatever it sees and uses that to sub out each frame. But on the very next flat field where i let the shutter work, a ghost image of the last flat field (like hot objects) is still present, but less. l think Seeks software is averaging flat fields. A bug?
Not sure I can agree about the focus statement.Could you in spare time try to make thermal images with Flir which has this MSX available of hot gorund like those from http://wildfiretoday.com/2014/10/27/a-thermal-infrared-camera-attachment-for-smart-phone/ (http://wildfiretoday.com/2014/10/27/a-thermal-infrared-camera-attachment-for-smart-phone/) shown by me in prev posts and its grayed visual there?
To be clear on MSX.I saw this Flir's patent claim and while they make this transparency they have to modify thermal image in a way I do not like at all to show transpareny on their output images,
...
The idea of fusion was enhanced by allowing the transparency of the visible light image to be adjusted in order to have lower impact on the thermal image data that was being displayed.
Does anybode know how to convert the 16bit image data to absolute temperature values?
have any pictures you've taken with this setup?Close up lenses are used to provide detailed images of PCB's etc.
I've put up a simple holder for the 20mm ZnSe lenses over at Thingiverse. It's just a friction fit which depends on the asymmetry of the camera face to hold it in place, but it seems to do the trick. Should do well enough to keep handy in the toolbag. http://www.thingiverse.com/thing:525605 (http://www.thingiverse.com/thing:525605)
I made a look into that code since I'm interested in own Linux USB driver if they resolve those gradient issues.Does anybode know how to convert the 16bit image data to absolute temperature values?Those are pre getting the real images but the range is about the same.
208x156 16 bits unsigned only 14 bits used.
Pretty much you want to capture the max and min value (ignoring dead pixels and reference ones, under 0x800) and then stretch them ramp them from min to max to fit on a 256 look up table. So (max-min)/256 should get you started.
So I've managed to reduce the noise using a convoluted method.You mean http://en.wikipedia.org/wiki/Moving_average (http://en.wikipedia.org/wiki/Moving_average) ? How many frames used and what is output frame rate from this sensor hardware catched by USB?
Yep, there are a couple at Thingiverse. I'll stick 'em over here as well, one each with a 100mm and 50mm aux lens.One question-is it possible from Seek Thermal application save output images like those you provided not in JPEG format, but in other losless like RGB PNG for example?
They are noisy and the resolution isn't world-changing but it's better than the "Ow! $#!% my finger!" test to answer the question "What's pulling all the current on this damned board?"
So I've managed to reduce the noise using a convoluted method.You mean http://en.wikipedia.org/wiki/Moving_average (http://en.wikipedia.org/wiki/Moving_average) ? How many frames used and what is output frame rate from this sensor hardware catched by USB?
For us, we need the ability to get the full framerate off the sensor, because right now it's only allowing around 9fps. Its averaging 5 frames together for each visible frame. By my math its about a 45fps sensor. Its a shame ITAR limits the fps on such a low resolution sensor.9 fps not so bad -if moving average of 8 were used than even on MPU it can be fast while divide by 8 in assembler can be performed by shifting bits and will be fast -no integer divide needed, and output 1 Hz frequency could be fine in many applications if we were able improve image quality 8)
I did manage to compile the seeker windows program on a dell venue tablet and run it with the camera plugged directly into the usb port.Nice, so if you could add a few lines of code where raw sensor data is read and output it simply as unsigned int or uint16_t to text file (than compress) without any comparisions and changing to 0 those pixels with 0x800 condition in this code-raw data as it comes from the sensor in format below (and include also thermal image of catched object as well as its visual image to see what light conditions it was: dark, normal working light) they maybe someone from the forum could be able to figure out what is in those last 2 columns in those raw sensor images.
/**
* (C) 2014 Eneuro
*/
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <string.h>
#include <time.h>
void random_init() {
srand(time(0) );
}
double random_double() {
return ((double)rand())/RAND_MAX;
}
unsigned int random_14bit() {
// 2^14= 16384
unsigned int pixel= random_double()*16384;
if(pixel>=16384) {
pixel= 16384-1;
}
return pixel;
}
int main(int argc, char *argv ) {
unsigned int i, j, k, l, m, n;
unsigned int y,x, w= 208, h= 156, wh= w*h;
unsigned int img0, *img;
unsigned int f, frames= 8;
random_init();
img= (unsigned int*)malloc(sizeof(unsigned int)*wh );
// frames
for(f=0; f<frames; f++ ) {
// frame
// Create random image with 14bit data or read from sensor
for(i=0; i<wh; i++ ) {
img[i]= random_14bit();
} // Create random image with 14bit data or read from sensor
// Output frame
// rows
for(y=0; y<h; y++ ) {
// column
for(x=0; x<w; x++ ) {
img0= (unsigned int)img[y*w +x];
printf("%05u ", img0 );
} // column
printf("\n");
} // rows
printf("\n\n");
// Output frame
// frame
} // frames
return 0;
}
so, each frame in this text file could look like this below separated by 2 empty lines (it is LF 10 dec codes on Linux and CRLF 13 dec 10 dec on Window$ as text new line character(s) ).I made a look into that code since I'm interested in own Linux USB driver if they resolve those gradient issues.Does anybode know how to convert the 16bit image data to absolute temperature values?Those are pre getting the real images but the range is about the same.
208x156 16 bits unsigned only 14 bits used.
Pretty much you want to capture the max and min value (ignoring dead pixels and reference ones, under 0x800) and then stretch them ramp them from min to max to fit on a 256 look up table. So (max-min)/256 should get you started.
This hardcoded 0x800 looks bad in this code, as well as fitting to 256 LUT- while we have 14bit using 1024 LUT could give much better results.
Also averaging/convolution methods used in this code are computational not efficient- it can be done much faster using a little bit memory which is not concern on modern devices while we'are processing 208x156 raw sensor data.
Also it does not use any moving average between frames, so no chance to make this image less noisy by mounting this thermal dongle on tripod to avoid any movements while it does not have any stabilization.
I suggest reading image processing publications to make this code more efficient, however USB communication part might be usefull if someone have no chance to make USB sniffing :-+
I did manage to compile the seeker windows program on a dell venue tablet and run it with the camera plugged directly into the usb port. I notice a lot of white specs along with dead pixels and the null pixels. We'll just call those patent pixels.That was my intent for usage as well, I bought my wife a Venue tablet last year and she doesn't use it for fear to damage the screen.
Since 16 bit grayscale doesn't seem to be supported, I had to do 48 bit color (with R=G=B).Gray Alpha channels in PNG could be used-easy to write using libPNG ;)
"Flexible Image Transport System (FITS) is an open standard[3] defining a digital file format useful for storage, transmission and processing of scientific and other images."
Since 16 bit grayscale doesn't seem to be supported, I had to do 48 bit color (with R=G=B).Gray Alpha channels in PNG could be used-easy to write using libPNG ;)
http://www.libpng.org/pub/png/book/chapter08.html#png.ch08.div.5.4 (http://www.libpng.org/pub/png/book/chapter08.html#png.ch08.div.5.4)
However, this FITS image format (http://en.wikipedia.org/wiki/FITS (http://en.wikipedia.org/wiki/FITS)) can be very usefull there :-+Quote"Flexible Image Transport System (FITS) is an open standard[3] defining a digital file format useful for storage, transmission and processing of scientific and other images."
There is a few links to FITS docs, libs, sample files on NASA web pages:
The FITS Support Office at NASA/GSFC http://fits.gsfc.nasa.gov/ (http://fits.gsfc.nasa.gov/)
http://fits.gsfc.nasa.gov/fits_documentation.html (http://fits.gsfc.nasa.gov/fits_documentation.html)
http://fits.gsfc.nasa.gov/fits_libraries.html (http://fits.gsfc.nasa.gov/fits_libraries.html)
I've downloaded for research this simple:
The Interactive FITS File Editor fv: http://heasarc.gsfc.nasa.gov/docs/software/ftools/fv (http://heasarc.gsfc.nasa.gov/docs/software/ftools/fv)
http://heasarc.gsfc.nasa.gov/docs/software/ftools/fv/fv_download.html (http://heasarc.gsfc.nasa.gov/docs/software/ftools/fv/fv_download.html)
ftp://heasarc.gsfc.nasa.gov/software/lheasoft/fv/fv53.exe (http://ftp://heasarc.gsfc.nasa.gov/software/lheasoft/fv/fv53.exe)
ftp://heasarc.gsfc.nasa.gov/software/lheasoft/fv/fv53_pc_linux64.tar.gz (http://ftp://heasarc.gsfc.nasa.gov/software/lheasoft/fv/fv53_pc_linux64.tar.gz)
With funtools library it should be easy add support for FITS images to application
https://www.cfa.harvard.edu/~john/funtools/ (https://www.cfa.harvard.edu/~john/funtools/)
https://www.cfa.harvard.edu/~john/funtools/funtools.pdf (https://www.cfa.harvard.edu/~john/funtools/funtools.pdf)
There is Definition of the Flexible Image Transport System (FITS) (http://fits.gsfc.nasa.gov/standard30/fits_standard30aa.pdf)
Using mentioned above fv it is easy view and modify eg. sample Hubble telescope image I've downloaded from NASA website for testing (it is just 16bit):
(http://s5.postimg.org/a9wf65fmr/fv_fits_viewer_editor.jpg) (http://postimg.org/image/a9wf65fmr/)
Which is more interesting contours can be added to those FITS image files as well as other data incuding tables, etc, so Flir's MSX no longer needed to add edges while we can output thermal image in this FITS format with contours :-+
(https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/?action=dlattach;attach=116130)
No problem to load such FITS image even using GIMP, but probably this data is scalled to 8bit I guess,
so using software like fv is adwantage.
I've suggested simple text format for investigation purposes while no problem with bits order in different machines and it is easy to add only few lines of code to output this raw data while we have fixed size Seek Thermal sensor image data, so easier than include FITS library, but while NASA is using FITS and it is designed with backward compatibility for archives purposes, so it is well defined image format :-/O
the gradient is indeed still easily seen on the 16 bit raw output from the camera.How many dead pixels has your sensor? >:D
BTW, the gradient is indeed still easily seen on the 16 bit raw output from the camera. Just set the white and blackpoints to give high contrast and it shows up just like in the app.
One interesting artifact I notices is a oval light patter in the upper left corner just like sgstairs shown in post 312.
https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/312/ (https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/312/)
Too coincidental to be a random manufacturing glue or dirt I would think...but marshallh's image next to it didn't seem to show it, so it may be a batch thing.
But it's invisible in the app, so it must get compensated for in the calibration.
My raw images don't have any circles in the field but plenty of bad pixels. These things claim to pass QC before they are shipped. I think they are "allowing" a greater amount of bad sensors through because the demand is so high.
You can ignore all of the calibration frames if you want. If you look at sgstair's code byte 20 of the raw data (pixel 10) is used to determine if it's a cal frame or a good frame.
They already are on a separate buffer :)
I'm going to save off the cal frames separately so I can analyze them and possibly use them for image processing.It looks like libPNG outputs very nice 16bit gray images with a few lines of C code:
$ file seek_thermal_sensor_gray_16bit_test_by_eneuro.png(https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/?action=dlattach;attach=116195)
seek_thermal_sensor_gray_16bit_test_by_eneuro.png: PNG image, 208 x 156, 16-bit grayscale, non-interlaced
The raw sensor image you are showing looks pretty good compared to all the sensors raw outputs I've seen.Yep, this is of course simulation, while tested which PC software can read those 16bit gray images ;)
Reference pixels or dead pixels, the ones in the pattern are purposely turned off and they are every 15 pixels from this series modulus height: 10, 6, 2, 13, 9, 5, 1, 12, 8, 4, 0, 11, 7, 3, 14
So on the first row is: 10, 25, 40 ...
on the second row is: 6, 21, 36 ...
on the sixteenth row is the same as the first row: 10, 25, 40 ...
Not sure why it never starts on pixel 15 but it just doesn't.
I added code back on page 32, to interpolate those pixels, the same loop can be done to generate them.
Just declare a uint16 array of 208*156, and fill it with 0x8000, then use that loop and instead of averaging set those values to 0.
https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/msg538322/#msg538322 (https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/msg538322/#msg538322)
I'd be interested to understand how seek gets rid of most of the horizontal lines. They appear to be pretty fixed, so maybe some Flat Field is stored off.Maybe data from last 2 columns is used to modify somehow rows ;)
using nom.tam.fits;
using System;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Fits f = new Fits(@"C:\temp\thermo\router_image2i.fit");
ImageHDU h= (ImageHDU) f.ReadHDU();
System.Array img = (System.Array[])h.Kernel;
int x = 0, y = 0;//for pixel position tracking
foreach (short[] collection in img)
{
Console.WriteLine("LineNo: "+ y);
foreach (UInt16 pixVal in collection)
{
Console.Write(pixVal + ",");
x++;
}
y++;
Console.WriteLine("");
}
Console.Read();
}
}
}
@ricksastroThe output fits and png's are unmodified, unscaled, unbiased, unstretched...they are how they come from the camera.
Nice 14bit sensor data :-+
Did you modified its pixels eg, those output FITS files and 16bit channel RGB (48bit) converted to 16bit gray PNGs or only this JPEG with screen shot from your software has calibrated pixel data in a way you descibed in your post ? ::)
BTW: It looks like those FITS files are flipped vertical so first row on PNG image is last on FITS etc ;)When I view either file (PNG or FITS), they look and act identical, unflipped. Must just be the way they store the FITS file or the way your library is handling them differently. I just did a"save-as" of the png file to the FITS from MaximDL, so no process that would do any flipping.
Once you perform the subtraction calibration, then you need to add some sort of bias, otherwise you'll get negative values.I research test software I use libPNG to load 16bit gray PNG 208x156 images, and then convert it to double so no problem with negative values ;)
index= round(val_double*LUT_size);
Once you perform the subtraction calibration, then you need to add some sort of bias, otherwise you'll get negative values.I research test software I use libPNG to load 16bit gray PNG 208x156 images, and then convert it to double so no problem with negative values ;)
When you mathematically subtract the calibration frame from the thermal frame, those areas in the thermal frame that are of a lower temperature than the calibration frame will mathematically be negative no matter the format unless you add in a bias to compensate.I forgot about those calibration frames for the moment at all, while just processing visual web cam outputs in OpenCV ;)
Seek Thermal has been following this thread with great interest. We would like to be as transparent as possible, realizing that competition may use this as ammunition, but we believe that in the end we will be helped far more than hurt by an open and honest exchange.
Seek Thermal Inc. has been built from the ground up bring affordable IR sensors to the commercial market.
We greatly appreciate the professional attitude and creative troubleshooting your collaborators have demonstrated. We are actively reviewing our product to confirm your findings. Identifying these issues early in our production cycle gives us a good opportunity to implement improvements when appropriate. With the low cost of our camera some compromises need to be made between performance and cost. We will be looking for cost effective improvements to address some of the issues you have identified.
Epoxy invasion. The good news is that our lens attachment process is fully automated. Thus the process ‘should’ be well controlled and any corrective action should be effective with low variability.
We image test every detector visually before shipment, so the worst units will be screened out. Our experience is that anything under the shutter will be almost perfectly removed by a Flat Field Calibration.
Thermal Gradient over time, We are actively investigating possible improvements to this issue. No resolution or definite direction yet. Note that for ‘relative’ thermography where the spot is fixed in the center of the display, we expect thermography to retain its ‘relative’ accuracy.
Dark Pixels. No great mystery here. Every 15th pixel is intentionally blanked to avoid a potential patent infringement. Seek has an updated design for future product that eliminate the need for this measure. With the effective blur length of a 12 micron pixel resolving 8-13 micron Radiation, loss of single isolated pixels does not (in itself) degrade image quality.
Thank you again for your interest in our product, we look forward to continuing our dialogue with the community.
Best,
The Seek Thermal Team
----------- NOV 3 --------------------
I hope some of the seek engineers are still following this thread, because I have a pretty good question for them...
Why is there a ghost image that slowly reappears strongest right before a flat field event? It doesn't have to be an intentional image (like holding the shutter open during a flat field to see it), I notice it creeps back in after a calibration, no matter what it is. Sometimes the flatfield image shows up as blocky hotspots, and it gets hotter right before a fresh flat. Whatever the sensor looked like during the calibration, that image slowly appears right before a new flat field. Even fixed pattern noise shows up. What...is going on?!
I just want to know the math involved in how you subtract the flat from each frame. I don't think its a trade secret or anything, but its clearly some kind of bug. I know sometimes I get 5 frames on a flatfield, sometimes it's only one frame. I tested this while waving the camera with the shutter forced open.
-------------- END POST. -----------
Please confirm that this only occurs when you interfere with the shutter?
If you interfere with the shutter you can confuse the temporal drift algorithm.
Thanks,
Seek Technical Team
Thus, while some have suggested a user triggered 'Secondary’ calibration, that is an extra step that could require a significant amount of user education for nonprofessionals, and lead to frustration when the gradient returns.
It's not uncommon for software to have an "advanced" mode for additional functions that might confuse stupid peopleThus, while some have suggested a user triggered 'Secondary’ calibration, that is an extra step that could require a significant amount of user education for nonprofessionals, and lead to frustration when the gradient returns.
With all due respect this is what makes today's computer tech unusable. With UI being replaced by UX and settings which would "get in the way of either designing a minimalistic interface or maybe could confuse some slower users" simply get removed, nothing can be really customized, all configuration is left to the engineers or worse the marketing people and users have to stick it out...
Why not make two flavours of the program (or APP, as is popular to say today) or maybe include a submenu (with a warning) for the "pros"?Censorship is not allowing a man to have a steak because a baby can't chew it.--Mark Twain
(I run Linux on my computers and have long thought this wouldn't get to me, and then Gnome 3 came out and with each and every major update more settings went missing...)
It's not uncommon for software to have an "advanced" mode for additional functions that might confuse stupid peopleThus, while some have suggested a user triggered 'Secondary’ calibration, that is an extra step that could require a significant amount of user education for nonprofessionals, and lead to frustration when the gradient returns.
With all due respect this is what makes today's computer tech unusable. With UI being replaced by UX and settings which would "get in the way of either designing a minimalistic interface or maybe could confuse some slower users" simply get removed, nothing can be really customized, all configuration is left to the engineers or worse the marketing people and users have to stick it out...
Why not make two flavours of the program (or APP, as is popular to say today) or maybe include a submenu (with a warning) for the "pros"?Censorship is not allowing a man to have a steak because a baby can't chew it.--Mark Twain
(I run Linux on my computers and have long thought this wouldn't get to me, and then Gnome 3 came out and with each and every major update more settings went missing...)
It's not uncommon for software to have an "advanced" mode for additional functions that might confuse stupid people
It's not uncommon for software to have an "advanced" mode for additional functions that might confuse stupid people
no, its INDUSTRY STANDARD to have separate advanced/manual menu, every frickin point and shoot digital camera on the market has some kind of manual menu. It sits unused on 99.9% of cameras because like you said average potato people are too stupid to use it, but its there nonetheless.
software (OSes mainly? maybe apple software in general lately) seems to be the exception, constantly dumping down UI, catering to the lowest common denominator and making it less usable in the process.
# You will need to have python 2.7 (3+ may work)
# and PyUSB 1.0
# and PIL 1.1.6 or better
# and numpy
# and scipy
# and ImageMagick
# Many thanks to the folks at eevblog, especially (in no particular order)
# miguelvp, marshallh, mikeselectricstuff, sgstair and many others
# for the inspiration to figure this out
# This is not a finished product and you can use it if you like. Don't be
# surprised if there are bugs as I am NOT a programmer..... ;>))
import usb.core
import usb.util
import sys
import Image
import numpy
from scipy.misc import toimage
# find our Seek Thermal device 289d:0010
dev = usb.core.find(idVendor=0x289d, idProduct=0x0010)
# was it found?
if dev is None:
raise ValueError('Device not found')
# set the active configuration. With no arguments, the first
# configuration will be the active one
dev.set_configuration()
# get an endpoint instance
cfg = dev.get_active_configuration()
intf = cfg[(0,0)]
ep = usb.util.find_descriptor(
intf,
# match the first OUT endpoint
custom_match = \
lambda e: \
usb.util.endpoint_direction(e.bEndpointAddress) == \
usb.util.ENDPOINT_OUT)
assert ep is not None
# Deinit the device
msg= '\x00\x00'
assert dev.ctrl_transfer(0x41, 0x3C, 0, 0, msg) == len(msg)
assert dev.ctrl_transfer(0x41, 0x3C, 0, 0, msg) == len(msg)
assert dev.ctrl_transfer(0x41, 0x3C, 0, 0, msg) == len(msg)
# Setup device
#msg = x01
assert dev.ctrl_transfer(0x41, 0x54, 0, 0, 0x01)
# Some day we will figure out what all this init stuff is and
# what the returned values mean.
msg = '\x00\x00'
assert dev.ctrl_transfer(0x41, 0x3C, 0, 0, msg) == len(msg)
ret1 = dev.ctrl_transfer(0xC1, 0x4E, 0, 0, 4)
ret2 = dev.ctrl_transfer(0xC1, 0x36, 0, 0, 12)
#print ret1
#print ret2
#
msg = '\x20\x00\x30\x00\x00\x00'
assert dev.ctrl_transfer(0x41, 0x56, 0, 0, msg) == len(msg)
ret3 = dev.ctrl_transfer(0xC1, 0x58, 0, 0, 0x40)
#print ret3
#
msg = '\x20\x00\x50\x00\x00\x00'
assert dev.ctrl_transfer(0x41, 0x56, 0, 0, msg) == len(msg)
ret4 = dev.ctrl_transfer(0xC1, 0x58, 0, 0, 0x40)
#print ret4
#
msg = '\x0C\x00\x70\x00\x00\x00'
assert dev.ctrl_transfer(0x41, 0x56, 0, 0, msg) == len(msg)
ret5 = dev.ctrl_transfer(0xC1, 0x58, 0, 0, 0x18)
#print ret5
#
msg = '\x06\x00\x08\x00\x00\x00'
assert dev.ctrl_transfer(0x41, 0x56, 0, 0, msg) == len(msg)
ret6 = dev.ctrl_transfer(0xC1, 0x58, 0, 0, 0x0C)
#print ret6
#
msg = '\x08\x00'
assert dev.ctrl_transfer(0x41, 0x3E, 0, 0, msg) == len(msg)
ret7 = dev.ctrl_transfer(0xC1, 0x3D, 0, 0, 2)
#print ret7
#
msg = '\x08\x00'
assert dev.ctrl_transfer(0x41, 0x3E, 0, 0, msg) == len(msg)
msg = '\x01\x00'
assert dev.ctrl_transfer(0x41, 0x3C, 0, 0, msg) == len(msg)
ret8 = dev.ctrl_transfer(0xC1, 0x3D, 0, 0, 2)
#print ret8
#
x=0
while x < 5:
# Send read frame request
msg = '\xC0\x7E\x00\x00'
assert dev.ctrl_transfer(0x41, 0x53, 0, 0, msg) == len(msg)
ret9 = dev.read(0x81, 0x3F60, 1000)
ret9 += dev.read(0x81, 0x3F60, 1000)
ret9 += dev.read(0x81, 0x3F60, 1000)
ret9 += dev.read(0x81, 0x3F60, 1000)
# Let's see what type of frame it is
# 1 is a Normal frame, 3 is a Calibration frame
# 6 may be a pre-calibration frame
# 5, 10 other... who knows.
status = ret9[20]
if status == 1:
# Convert the raw calibration data to a string array
calimg = Image.fromstring("I", (208,156), ret9, "raw", "I;16")
# Convert the string array to an unsigned numpy int16 array
im2arr = numpy.asarray(calimg)
im2arrF = im2arr.astype('uint16')
if status == 3:
# Convert the raw calibration data to a string array
img = Image.fromstring("I", (208,156), ret9, "raw", "I;16")
# Convert the string array to an unsigned numpy int16 array
im1arr = numpy.asarray(img)
im1arrF = im1arr.astype('uint16')
# Subtract the calibration array from the image array and add an offset
additionF = (im1arrF-im2arrF)+ 800
# convert to an image and display with imagemagick
toimage(additionF).show()
x = x + 1
What it's interesting is that if I point the camera to a different heat source than the reference one I only get the reference pattern pixels to be the same, all the other pixels are different.How much those dead looking sensor pixels close to black does change?
In the router_image1c.fit and router_image2i.fit files the last value (208th) is always 32768 (1000 0000 0000 0000).I think at some point during conversion of the data 32768 has been added. In the images recorded by marshallh (https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/msg533801/#msg533801 (https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/msg533801/#msg533801)) the 208th value is 0 and the 207th is around 5200. There is a clear tendency over all frames from 5250 in the first to 5211 in the last. There is no difference between the reference or any other frame. Maybe it is the sensor temperature.
The 207th values are just a little apart in this two files:
4607, 5364
4612, 5365
4609, 5366
4612, 5362
4607, 5362
4604, 5358
4605, 5357
4607, 5359
4606, 5358
4605, 5359
4602, 5356
4605, 5359
4601, 5354
4602, 5354
4606, 5351
4602, 5353
4600, 5352
4601, 5350
4600, 5352
4598, 5350
4599, 5350
4598, 5351
4598, 5350
4599, 5345
Maybe they have added a black pixel at the end of each line.
In our first post we thanked the collaborators in this forum for their professional and helpful comments and suggestions. Your response since has been even more impressive. We are grateful.
Thermal Gradient: We have been able to reproduce the thermal gradient effect that several people have reported. We are now working on a software solution and will incorporate it into an app update within the next month.
One goal for the Seek camera has been ease of operation since we are positioning it as the first general consumer thermal camera. Thus, while some have suggested a user triggered 'Secondary’ calibration, that is an extra step that could require a significant amount of user education for nonprofessionals, and lead to frustration when the gradient returns. In that spirit we are focused on a fully automatic compensation solution in the upcoming application update.
Thanks again,
Seek Technical Team
We could try to subtract 207th value from each line pixel and see if the image gets better/worse...It gets much better!
I know this might be a shot in then dark, but perhaps the patent pixels are working thermistors...which means maybe they are reading the temperature of the sensor. Maybe each line is an average of the readings from those pixels? Declining values would point me to think that the resistance is falling (heating) and thus the values are mapped.
I know this might be a shot in then dark, but perhaps the patent pixels are working thermistors...which means maybe they are reading the temperature of the sensor. Maybe each line is an average of the readings from those pixels? Declining values would point me to think that the resistance is falling (heating) and thus the values are mapped.
patent pixels are always 0 they don't vary. (other than the first one that tells you if it's a cal frame or not)
@miguelvp,
Double check your count, I count 10 per line.
In the darker lines the 207th value is higher (~5300 instead of ~4900). Therefore they have to be added to remove the dark lines. This is a bit strange, because this means the 207th value uses a different sensor, or it is an already processed value. Maybe it is even the absolute temperature: 5200/256=20.3°C
It is not possible to remove the horizontal noise completely from both hot and cold areas with the same scaling factor. To remove the dark lines completely there are probably more calculations to be done:
I do not know, but I think the data is the non linearized data from the adc. To get the absolute temperature, you have to know some constants (I think it works the same way for all bolometers):
http://u88.n24.queensu.ca/exiftool/forum/index.php?topic=4898.msg23972#msg23972 (http://u88.n24.queensu.ca/exiftool/forum/index.php?topic=4898.msg23972#msg23972)
Therefore subtracting or adding raw values only works for a small temperature range before it gets nonlinear.
Does anybody know if other thermal cameras simply scale/offset the sensor data the same way we do, or do they linearize the data to temperature scale before applying the palette?
We could try to subtract 207th value from each line pixel and see if the image gets better/worse...It gets much better!
I have added 207th value/10 to each pixel of the line after subtracting the reference frame.
I think it is some sort of reference pixel for each line.
Technically you should be dividing by the number of thermistors counted on each line, which seems to vary.
As it gets warmer, the resistance decreases but not linear to the temperature. One degree change at low temperature could make a change of 100 on the ADC, while at high temperature it could be only 30 or less. That's why its hard to get accurate readings at high temperature, as the resolution drops.It is probably the reverse: I did some rough estimates with some old thermal images from a different camera using the min/max values on the thermal images and the min/max values of the raw data. The temperature to raw data conversion is more like exponential, higher temperatures have therefore a higher resolution. This matches the formula using ln() to calculate the temperature from the other forum I have posted.
I was hoping that subtracting the flat paper image from the router image would remove the lines and even out some of the pixel noise.Probably cats and human face are beter thermal objects than those router images ;)
As it gets warmer, the resistance decreases but not linear to the temperature. One degree change at low temperature could make a change of 100 on the ADC, while at high temperature it could be only 30 or less. That's why its hard to get accurate readings at high temperature, as the resolution drops.It is probably the reverse: I did some rough estimates with some old thermal images from a different camera using the min/max values on the thermal images and the min/max values of the raw data. The temperature to raw data conversion is more like exponential, higher temperatures have therefore a higher resolution. This matches the formula using ln() to calculate the temperature from the other forum I have posted.
I made a small animated gif out of several frames. The noise seems to be mostly static. It should be quite easy to remove it with a bit of additional processing. Furthermore there are a few pixels (always 2 adjacent) that seem to change constantly without any reference to the normal image. Maybe they contain other information?
We could try to subtract 207th value from each line pixel and see if the image gets better/worse...It gets much better!
I have added 207th value/10 to each pixel of the line after subtracting the reference frame.
I think it is some sort of reference pixel for each line.
As it gets warmer, the resistance decreases but not linear to the temperature. One degree change at low temperature could make a change of 100 on the ADC, while at high temperature it could be only 30 or less. That's why its hard to get accurate readings at high temperature, as the resolution drops.It is probably the reverse: I did some rough estimates with some old thermal images from a different camera using the min/max values on the thermal images and the min/max values of the raw data. The temperature to raw data conversion is more like exponential, higher temperatures have therefore a higher resolution. This matches the formula using ln() to calculate the temperature from the other forum I have posted.
I made a small animated gif out of several frames. The noise seems to be mostly static. It should be quite easy to remove it with a bit of additional processing. Furthermore there are a few pixels (always 2 adjacent) that seem to change constantly without any reference to the normal image. Maybe they contain other information?
Not sure if those are bright pixels or subtracted darker pixels from the calibration frame. Regardless, you should be able to do a bad pixel map of the patent pixels and those and median them out.
Also if you are taking images of static objects, you could take many frames and move the camera slightly between frames (dithering) and then stack the images using a sigma reject type of combination (after alignment of the subject) do all but eliminate the noise. This can also give you a "superresolution" if you align and combine higher res resampled iamges. The lower noise will allow more sharpening as well.
Not practical for many objects, but an interesting exercise nonetheless.
Adding them after being divided by 10 would give you the same relative image as just adding it without dividing by 10 (other than when you get over 2^16 but that can be fixed by reducing our introduced 0x8000=32768 d offset, say to 24K instead of 32K leaving 8K (8192d) on the table).If I do not divide by 10, the black line get white and white lines gets black. I need to scale the values down to reduce theie effect just so to compensation the lines in the original image.
The division just takes away some precision.
... build a loop that scans each pixels and compares it to its 4 neighbors. So find the average of x+1,x-1,y+1,y-1, divide that in to a variable. Subtract value of current pixel from the variable hosting the average, flip the sign so its positive, and replace the pixels value with the average if it is over or under the average by 10 (or however agressive you choose it to be.)
... build a loop that scans each pixels and compares it to its 4 neighbors. So find the average of x+1,x-1,y+1,y-1, divide that in to a variable. Subtract value of current pixel from the variable hosting the average, flip the sign so its positive, and replace the pixels value with the average if it is over or under the average by 10 (or however agressive you choose it to be.)
Already done that:
https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/msg538423/?topicseen#msg538423 (https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/msg538423/?topicseen#msg538423)
I went a step futher by checking which pair (horizontal or vertical) has smallest difference in color.
(This is to keep details on vertical and horizontal edges)
The average value of this pair is the new pixel value.
Bktemp, try what I said. You can't average out noise if it doesn't change on each frame. This works traditionally on astrophotography because the noise changes on each frame, so the real data can get averaged in. In our case, we have to do a neighbor comparison to find the bad pixels give them the average of their neighbors.
Bktemp, try what frenky did. Just cut and paste his code in, that should put the nail on this. Removing the banding first, then run the code frenky put up. Post an image and let us see how much better this sensor looksI do not try to avarage it out. I am trying to generate a black level reference image and subtract it from all images. This works well, as long as there are no big thermal differences. The image is almost noise free, without replacing any pixels. The nonlinearity is the main problem. I can tweak the gain to compensate either hot or cold areas, but not both.
You can't average out noise if it doesn't change on each frame. This works traditionally on astrophotography because the noise changes on each frame, so the real data can get averaged in. In our case, we have to do a neighbor comparison to find the bad pixels give them the average of their neighbors.
Not sure if those are bright pixels or subtracted darker pixels from the calibration frame. Regardless, you should be able to do a bad pixel map of the patent pixels and those and median them out.Why do you suggest to use median for those 2143 hexagon sensor pattern pixels?
Mat img = imread(fin, CV_LOAD_IMAGE_GRAYSCALE| CV_LOAD_IMAGE_ANYDEPTH );
The processing steps:Just thinking of FFT on reference frame and some kind of averaging aproximation before using this calibration data.
...
- reference frame subtracted
- black pixels removed
...
@bktempIt was this filter:
That image looks good up to right before that heavy filter you applied.
I'm curious, are these images already averages of 5 frames or are they individual frames? If so the noise could be filtered with frame stacking, but so far it looks really good!I have used the recorded USB data from marshallh:
Funny you should ask, I've been poking at this for a couple of days. I've written a Python program which uses PyUSB to capture calibration and Image Frames from the Seek Imager.
I used the term generically in reference to the neighbor pixel method presented here.Not sure if those are bright pixels or subtracted darker pixels from the calibration frame. Regardless, you should be able to do a bad pixel map of the patent pixels and those and median them out.Why do you suggest to use median for those 2143 hexagon sensor pattern pixels?
seek_thermal_test: Seek Thermal sensor hexagon pattern (black) pixel count in row: 14 14 14 13 14 14 14 13 14 14 14 13 14 14 13 14 14 14 13 14 14 14 13 14 14 14 13 14 14 13 14 14 14 13 14 14 14 13 14 14 14 13 14 14 13 14 14 14 13 14 14 14 13 14 14 14 13 14 14 13 14 14 14 13 14 14 14 13 14 14 14 13 14 14 13 14 14 14 13 14 14 14 13 14 14 14 13 14 14 13 14 14 14 13 14 14 14 13 14 14 14 13 14 14 13 14 14 14 13 14 14 14 13 14 14 14 13 14 14 13 14 14 14 13 14 14 14 13 14 14 14 13 14 14 13 14 14 14 13 14 14 14 13 14 14 14 13 14 14 13 14 14 14 13 14 14Probably it could be better apply this line tunning even before updating those hexagon pattern black pixels, while processing its neighbor with not corrected pixels in rows up and down will introduce incorrect values to processed row pattern pixels inside.
Probably it could be better apply this line tunning even before updating those hexagon pattern black pixels, while processing its neighbor with not corrected pixels in rows up and down will introduce incorrect values to processed row pattern pixels inside.It makes sense. I have already done that in my example unintentionally, by doing all subtractions at one place.
x = 10; // first black pixel is at x=10
for (y=0; y<156; y++)
{ for (; x<206; x+=15)
{ ...
}
x-=208+8;
if (x<0)
x+=15;
}
By the way, the easiest way to go through all hexagon pattern pixels:Yep, but anyway we need sensor hexagon pattern pixels matrix, for example when dealing with rows stats, so wrote it once and now it was easy too in OpenCV to generate some row stats from router calibration and image frames using this ;)
Mat hex= seek_thermal_black_dots_matrix();
...
for(i=0; i<h; i+=k ) { // i
val0= cor.at<ushort>(i, n); // 207th column
sum= 0;
m= 0;
for(j=0; j<n; j++ ) {
val= cor.at<ushort>(i,j);
if( hex.at<uchar>(i,j)>0 ) {
// Skip hexagon pattern pixel
} else {
sum+= val;
m++;
}
}
// Non zero pixels average
if(m>0 ) {
avg= sum/m;
} else {
avg= 0;
}
// Stats
fprintf(f,"%03u %0.3f %0.3f %03u %03u \n",
(i+1), avg, val0, m, n );
} // i
With above code I've got such nice stats of each row:row avg 207th count width
001 7947.229 5533.000 192 206
002 8029.047 5188.000 192 206
....
154 8198.523 5180.000 193 206
155 7953.286 4873.000 192 206
156 7892.047 5184.000 192 206
When we plot such pixels row averages vs this additional 207th column we get something like this for router raw data (router_image1c.png and router_image2i.png) provided earlier by @ricksastro:I was testing today this line tuning with 207th values.If you increase the gain applied to the 207th value it works for hot areas, but then it leaves stripes on dark areas.
I works great on low temp background, but on higher temp areas it adds light stripes.
So it probably should only be applied to the low temp areas...
Therefore I would convert the data to linear temperature scale before any further processing, but I have no idea how to do it.I have some idea how to tweak those temperatures, but no physical device for the moment :-/O
I wan't to see how accurate the central spot for the Seek is both at boot time and after being on for a while.It could be interesting another teardown of Seek Thermal for @mikeselectricstuff where he could test how accurate are those temperature spots shown in Android app in comparision to real temperature measurement made on heated object-for example using classic multimeter thermometer and maybe additionally IR thermometer with lase pointer.
October 30, 2014
Size
7.6M
Installs
1,000 - 5,000
Current Version
1.4.0.2
Requires Android
4.3 and up
Maybe will try download it later under Android and see if maybe inside is Seek Thermal users manual? :-//Technical Specs:
mUSB Thermal Camera for Android devices
Works on most Android devices running 4.3 or higher that support USB on the go. See Device List for Compatibility
True Thermal Sensor
206 x 156 Array
32,136 Thermal Pixels
12um Pixel Pitch
Vanadium Oxide Microbolometer
Chalcogenide Lens
36° Field of View
Magnesium Housing
Long Wave Infrared 7.2 - 13 Microns
-40C to 330C Detection
< 9Hz
Includes Protective Carrying Case
Model: UW-AAA
Very interesting is this < 9 Hz output frequency - does it mean it could be 1 Hz after some app updates? :-DDThere are 2 different scenes. One is taken against flat notebook paper (flatpaper) at ambient 73F. One is an image of my router (router).What about ambient temperature when you made those router images?
(%i56) max: 2^14;
(%o56) 16384
(%i54) tf: 5078.125/max*256;
(%o54) 79.345703125
(%i55) cel(79.345703125);
(%o55) 26.30316840277778
This means +3*C ~ +6*F difference between room ambient temperature and maybe those sensor zone thermistors formed in hexagon pattern "black pixels" ? :phew:@bktemp, the min/max value should be constant. The frame max and min values shouldn't be considered as they can change the calculated gain on individual pixels per frame. We need to find the lowest and highest reported values the sensor can display. I hope that clarifies my math.Ok, now I've got it. But that should not change much. Using the maximum and minimum values that can appear in the data you basically get the same as I have already used: pixel=pixel + (pixel+offset)/gain * 207th value
Has anyone received the iPhone version of the camera yet? The app is out so that is no longer an issue.There claim that they are still having issues with Apple hardware approval
Has anyone received the iPhone version of the camera yet? The app is out so that is no longer an issue.There claim that they are still having issues with Apple hardware approval
Has anyone received the iPhone version of the camera yet? The app is out so that is no longer an issue.There claim that they are still having issues with Apple hardware approval
Flir bribe bigger.
The intensity of the remaining horizontal stripes change after each calibration frame.How much does it change -more than 10% per minute? Did you tried to estimate this?
When you say shutter frame, do you mean that you have the option to actually ignore flat field events? When I tried sgstairs source the shutter still clicked away, so I assumed it was impossible to stop this even from happening. Like its handled by the firmware. Hmmm I wonder if anyone has messed with that chip yet...mike?Since I do not own a Seek camera, my only source of Seek raw data is the captured USB traffic from marshallh. It contains 75 image frames, 7 shutter frames and 6 preshutter frames.
Sine the only Seek raw data I have to work with contain only 87 frames, I can't give an absolute number. I did noticed some changes after the shutter frames. Not big, but noticeable. Maybe I am wrong and it is only the changing noise pattern that adds a different pattern to the stripes.The intensity of the remaining horizontal stripes change after each calibration frame.How much does it change -more than 10% per minute? Did you tried to estimate this?
@bktemp,
Bummer well it was worth a go. It seems reverse engineering this puppy is not so simple.
When you say shutter frame, do you mean that you have the option to actually ignore flat field events? When I tried sgstairs source the shutter still clicked away, so I assumed it was impossible to stop this even from happening. Like its handled by the firmware. Hmmm I wonder if anyone has messed with that chip yet...mike?
@bktemp,
Bummer well it was worth a go. It seems reverse engineering this puppy is not so simple.
When you say shutter frame, do you mean that you have the option to actually ignore flat field events? When I tried sgstairs source the shutter still clicked away, so I assumed it was impossible to stop this even from happening. Like its handled by the firmware. Hmmm I wonder if anyone has messed with that chip yet...mike?
There is a bit that tells you if it's a calibration frame or flat field event or not, you can ignore them but they are still going to happen since that is in control of the firmware.
Maybe there is some USB command that can be used to prevent it but as of now you can't prevent them from happening.
My gradient is the opposite. Its not cold, it's hot. The shutter starts off about the same temperature as ambient. The longer it runs it gets hotter, and it seems to run about as hot as the sensor. People report the sensor at around 38°C and that about 100°F, which is close to what my shutter reads when forced shut.
I have written to SEEK asking for their assistance with my development of their product for other uses. I will be working with a standard bare PCB without the SEEK lens as I will be adding some specialist optics. The camera will be temperature stabilised and adapted to work remotely from the host. Sadly I have yet to receive a reply from SEEK Thermal so they may be too busy or unwilling to assist me in this development work. I will have to wait and see if they respond over the next few days. Plan B will be to order some more SEEK cameras when they become available in the UK.I think they are way too busy with production to be spending time talking to people about special applications.
Aurora
And Seek responded and they think it might be possible to address the problem via software.They had to write something to keep people buying this since it is still in top google search "Seek Thermal gradient" issue :-DD
For the moment frustrated customers will listen to what will be done in... not defined future.
Simply it is not fair.
I've watched Mike's video several times and I am not sold on his solution (no offense Mike). I just can't comprehend how lens position would be the cause of a gradually apearing gradient.Could be change in temp of the lens housing (relative to the sensor and/or lens)?
I got my camera a few days ago. I agree the gradient issues basically ruins the device.Such thing should be found by Seek team before they send it to customers.
I opened my camera at work today, did some experiments, even cracked the glue free of the lens housing. My imager was free of any residue at all. I attempted to reposition the lens which made no appreciable difference. I tried all different ways to prove it was a thermal issue. I simply couldn't make a difference in the gradient. I also may have destroyed the sensor because I think the lens housing pushed some bond wires together and now I have a black image output. I have to get under a microscope and look, might need to just bump them free of each other. I hope. Otherwise it's $200 in the garbage.If it's unfixable, don't sling it.... I could do with a sacrificial unit to teardown the sensor and trace out the PCB.
I was not seeing a lot of unhappy posts on Facebook regarding the gradient issue which surprised me (remember they did not delete my question regarding such) so the user base appears unaware of a problem. From pictures shown here, it would appear to be obvious BUT I wonder......
I would be willing to try that if they would ship the damn thermal module to EU... |OMaybe there are also other reasons than ITAR limitations?
There are no ITAR issues (well at least not as far as the finished product is concerned ;) )I would be willing to try that if they would ship the damn thermal module to EU... |OMaybe there are also other reasons than ITAR limitations?
EUR-Lex Access to European Union law (http://eur-lex.europa.eu/homepage.html)
In the case of our country when normal person not company fill such complain form, than wait I'm not sure 30 days I guess, than if the problem is not resolved and make lawsuit in the court than when unsolved and not repaired issue was found within 6 months than in the case of court lawsuit manufacturer have to proove that there is no issue at all, while after 6 moonths customer have to proove it which in the case of modern technology can extremelly difficult and probably one had to pay for expert in this area.
I didn't gone througth court with such issues, but in many cases one email and official letter is fine, while company lawyers knows that one can make lawsuit vs them if they dismiss official document (not email).
So, talki that something will be done sometime by Seek Thermal maybe also simply game for time... to pass this 6 month pwriod-but ok I'm not a lawyer so in the case of broken thermal device maybe layers offize could help in US...
There is also another issue with Seek Thermal-for me is not acceptable there is no even end user manual available, which as I know is required in EU - I'm not usr ehot it looks like in US, so maybe if someone destroyed this device becouse of tried somehow "tune" this device to avoid this gradient, maybe there is a chance even without any lawsuits that will get his money back, because of there is NO SEEK THERMAL USER MANUAL available :box:
If they ship from the US to the EU, then it's a personal import and not subject to EU consumer lawReally? I have to investigate this in local customers lawyers office.
I've watched Mike's video several times and I am not sold on his solution (no offense Mike). I just can't comprehend how lens position would be the cause of a gradually apearing gradient.Could be change in temp of the lens housing (relative to the sensor and/or lens)?
The fact the lens was glued and I had no way to accurately hold & adjust everything meant it was difficult to conclusively prove anything - having to manually hold things may also have contributed some thermal effects.
It is possible that the temp was different between my original "before" and "after" results, though I did leave it off for a while to stabilise after I'd been handling stuff.
Must remember to try the lens form the Audi camera on it some time.
There is also another issue with Seek Thermal-for me is not acceptable there is no even end user manual available, which as I know is required in EUThere is help in the app. What's the big deal about a manual?
As the lens holder is no longer stuck down it can't really be used at the moment!
Mike, how does your unit perform with real use now that you've made the modifications? im interested in the quality of the pictures and video.
As the lens holder is no longer stuck down it can't really be used at the moment!
Mike, how does your unit perform with real use now that you've made the modifications? im interested in the quality of the pictures and video.
Something that might be interesting to try is heating/cooling the lens holder.
How often does it calibrate in normal operation?
I don't have a working cellphone (mine is CyanogenMod 11, which doesn't work with Seek) -- so I'm trying it with the computer USB connection...
Congrats on resurrecting your camera :phew:
You should have watched Mike's video about the bond wires, it almost happened to him but he dodged the bullet.
PX F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12
01 3251 0 8733 15625 135 4256 8721 8278 8680 8701 8278 8683
02 0 2000 3237 15520 112 4257 3236 3236 3235 3234 3234 3234
03 3361 2000 8566 15626 139 4258 8540 8080 8500 8516 8076 8496
04 3221 2000 7266 15612 136 4129 7251 6772 7202 7227 6758 7200
05 3320 2000 6417 15588 139 4382 6384 5877 6360 6371 5878 6338
06 3304 2001 9039 15639 137 16287 9024 8570 8985 8997 8575 8968
07 3352 2001 7086 15587 141 4001 7067 6565 7026 7029 6560 7008
08 3133 2001 5748 15574 132 4255 5733 5223 5686 5699 5226 5673
09 3281 2001 6932 15589 138 4257 6914 6437 6882 6904 6427 6872
10 3088 2001 7765 15615 130 4257 7741 7293 7693 7707 7283 7688
11 4 9 8 7 10 5 1 3 6 1 3 6
12 3321 2002 6264 15595 140 4129 6255 5714 6201 6213 5710 6181
13 3353 2002 6949 15585 142 4223 6923 6404 6885 6892 6407 6859
14 3351 2002 8650 15623 141 3999 8635 8173 8603 8616 8176 8588
15 3408 2003 8593 15603 144 3998 8570 8088 8543 8540 8086 8520
16 3404 2003 6941 15600 142 4255 6919 6420 6870 6885 6406 6859
17 3397 2003 6417 15576 143 4126 6405 5887 6356 6374 5855 6349
18 3382 2003 8247 15611 143 4638 8229 7742 8177 8195 7732 8168
19 3432 2003 8360 15618 144 3868 8349 7862 8298 8305 7845 8292
20 3492 2004 7514 15604 146 4257 7491 6986 7450 7468 6984 7438
21 3391 2004 6048 15572 145 16289 6024 5486 5979 5991 5466 5969
22 3381 2004 6525 15587 144 3874 6500 5961 6462 6465 5957 6441
23 3263 2004 6276 15571 139 3746 6258 5746 6207 6227 5748 6205
24 3389 2005 6530 15580 143 4127 6511 5979 6458 6476 5981 6439
25 3488 2005 6730 15581 147 4000 6719 6185 6672 6687 6177 6656
26 0 2005 0 0 0 4511 0 0 0 0 0 0
27 3298 2005 5906 15568 140 4385 5883 5352 5847 5850 5351 5827
28 3392 2005 6634 15603 143 4095 6618 6077 6571 6580 6065 6556
29 3524 2006 9092 15630 149 4130 9059 8556 9022 9028 8560 9010
30 3474 2006 5879 15588 146 4256 5867 5271 5801 5814 5264 5788
31 3529 2006 7605 15604 147 4385 7582 7071 7540 7555 7067 7520
32 3602 2006 7792 15623 150 4255 7772 7243 7720 7740 7229 7705
33 3300 2007 6456 15596 140 4257 6436 5901 6376 6391 5893 6369
34 3266 2007 5959 15593 139 4513 5923 5388 5886 5900 5394 5867
35 3467 2007 9011 15668 142 4259 8998 8510 8959 8971 8514 8955
36 3469 2007 6178 15588 146 16288 6156 5583 6103 6118 5581 6087
37 3523 2007 8010 15598 149 4257 7981 7455 7939 7937 7446 7916
If the shutter is at an angle, as it has a slightly reflective finish, could it cause a change in the field? I can report my gradient has now moved, but only occupies one side of the image along the edge, and it doesn't go towards the center of the image. I didn't move the lens position.When we compare this Seek shutter with Flir E4 that probably the first suspect could be this Seek shutter, while there is no perfect symetry in its design and shutter holder with relative higher mass or maybe even comparable to its thin part when moves in sensor FOV than simply maybe faster moving end of shutter is cooled in air while part close to rotation point is at lower speed so I can imagine that there can be temperature difference.
So here are the first 8 frames of the camera facing down but not to scale range (value) wise, but so that the data is somewhat visible.Good work, but it is issue that those images are ONLY 8bit so they are useless for anything but display them only....
$ file Frame1.pngIf you provided those 16bit grayscale PNGs I suggested and using as input to my image processing soft while raw sensor data is 14bit, not 8 bit, then people could verify what you stated :-\
Frame1.png: PNG image, 208 x 156, 8-bit/color RGBA, non-interlaced
$ file sts_cal.pngThis is only two lines of code in OpenCV to output such 16bit grayscale PNG image after or durring processing from any internal matrix format:
sts_cal.png: PNG image, 208 x 156, 16-bit grayscale, non-interlaced
// Conversions
outf.convertTo(out, CV_16U, 16384 );
imwrite("sts_cal.png", out );
I used 16384 scaling factor since operated on real numbers 0.0..1.0 in software...it can be changed or keep oryginal raw sensor data intact...So here is some raw data, 20 frames from startup including those first 6 frames then calibration, capture and precalibration.It looks much better :-+ >:D
First file is with the camera facing down during startup for 20 frames.They were send at <10Hz ?
2nd file is with the camera facing the router during startup for 20 frames.
The next thing that needs to be done is to unlock that firmware. I'm curious to see how they process the frames off the sensor.ISTR someone said they'd found a firmware image in the .apk - should be fairly easy to determine if this is ARM code, or is obfuscated/encrypted.
First file is with the camera facing down during startup for 20 frames.They were send at <10Hz ?
2nd file is with the camera facing the router during startup for 20 frames.
Do you have any timing hint what frame rate in this raw data could be?
It could be helpfull to estimate when those events took place, so for example delays between calibration frames and normal-do they happen at the same constant frame rate and delay between each those frames?
Such time stamp information when each frame took place could help investigate this raw data...so suggested to output each frame with time stamp info.
OpenCV has builtin functions for calculating such timing, but one have to be carefull and check if task scheduling in OS doesn't affect those time stamp at higher frequencies :-/O
Has anyone made a USB API (something similar to the winusbdotnet program written by sgstair) in the form of a dll file that can be called from matlab?
I'll work on adding a time_t timestamp before each frame, what do you prefer, before capturing, after capturing, or both?I used to use this code to compute how much time some processing is made and when (of course using C/C++ OpenCV):
// http://docs.opencv.org/modules/core/doc/utility_and_system_functions_and_macros.html
double t= (double)getTickCount()/getTickFrequency();
calf.convertTo(cal256, CV_8U, 128 );
imgf.convertTo(img256, CV_8U, 128 );
outf.convertTo(out256, CV_8U, ((double)128/25.0) );
double dt= ((double)getTickCount())/getTickFrequency() -t;
fprintf(stderr,"%s: Timestamp: %0.9f [s] Processing time: %0.9f [s]\n",
argv0, t, dt );
It outputs nice time in seconds how when from system powerup something happened and processing time:./seek_thermal_opencv_test: Timestamp: 14736.406878773 s Processing time: 0.000353242] s
Frame 1 ID 4
08d1c9758415a0a4
08d1c97584209d4d <- 72.0041 ms
Frame 2 ID 9
08d1c97584209d4d
08d1c9758425584f <- 31.0018 ms
Frame 3 ID 8
08d1c9758425584f
08d1c97584384456 <- 124.0071 ms
Frame 4 ID 7
08d1c97584384456
08d1c9758441ba5a <- 62.0036 ms
Frame 5 ID 10
08d1c9758441ba5a
08d1c9758446755b <- 31.0017 ms
Frame 6 ID 5
08d1c9758446755b
08d1c975844b305d <- 31.0018 ms
Frame 7 ID 1
08d1c975844b305d
08d1c9758488d684 <- 404.0231 ms
Frame 8 ID 3
08d1c9758488d684
08d1c97584a07d8d <- 155.0089 ms
<- 4.0002 ms File Write delay
Frame 9 ID 3
08d1c97584a119cf
08d1c97584b36994 <- 120.0069 ms
<- 2.0001 ms File Write delay
Frame 10 ID 3
08d1c97584b3b7b5
08d1c97584c67cab <- 123.0070 ms
<- 1.0001 ms File Write delay
Frame 11 ID 6
08d1c97584c6a3bc
08d1c97584e2deb6 <- 185.0106 ms
Frame 12 ID 1
08d1c97584e2deb6
08d1c97584ff67d1 <- 187.0107 ms
Frame 13 ID 3
08d1c97584ff67d1
08d1c97585170ed9 <- 155.0088 ms
<- 2.0001 ms File Write delay
Frame 14 ID 3
08d1c97585175cfa
08d1c9758529fae0 <- 122.0070 ms
<- 1.0001 ms File Write delay
Frame 15 ID 3
08d1c975852a21f1
08d1c975853ce6e7 <- 123.0070 ms
<- 1.0001 ms File Write delay
Frame 16 ID 3
08d1c975853d0df8
08d1c9758554b520 <- 155.0120 ms
<- 0.9969 ms File Write delay
Frame 17 ID 3
08d1c9758554dc11
08d1c975856c5c09 <- 154.0088 ms
<- 1.0001 ms File Write delay
Frame 18 ID 6
08d1c975856c831a
08d1c9758588be13 <- 185.0105 ms
<- 1.0001 ms File Write delay
Frame 19 ID 1
08d1c9758588e524
08d1c97585a5472e <- 186.0106 ms
Frame 20 ID 3
08d1c97585a5472e
08d1c97585bcee37 <- 155.0089 ms
@eneuro, here you go, timestamps for all the first 20 frames,Thx, I hope someone else also will try to look into this raw data so will benefit from this timing info too :-+
Frame 1 ID 4
8D1C9A479478DFD
8D1C9A479526396 <- 71.0041ms
Frame 2 ID 9
8D1C9A479526396
8D1C9A479571E98 <- 31.0018ms
Frame 3 ID 8
8D1C9A479571E98
8D1C9A4796A0A9F <- 124.0071ms
Frame 4 ID 7
8D1C9A4796A0A9F
8D1C9A4797380A2 <- 62.0035ms
Frame 5 ID 10
8D1C9A4797380A2
8D1C9A479783BA4 <- 31.0018ms
Frame 6 ID 5
8D1C9A479783BA4
8D1C9A4797CF6A6 <- 31.0018ms
Frame 7 ID 1
8D1C9A4797CF6A6
8D1C9A479BA9CCD <- 404.0231ms
Frame 8 ID 3
8D1C9A479BA9CCD
8D1C9A479D243D5 <- 155.0088ms
<- 3.0002ms File Write delay
Frame 9 ID 3
8D1C9A479D2B907
8D1C9A479E9EADE <- 152.0087ms
<- 2.0001ms File Write delay
Frame 10 ID 3
8D1C9A479EA38FF
8D1C9A479FCFDF6 <- 123.0071ms
<- 1.0000ms File Write delay
Frame 11 ID 6
8D1C9A479FD2506
8D1C9A47A196000 <- 185.0106ms
Frame 12 ID 1
8D1C9A47A196000
8D1C9A47A35E91B <- 187.0107ms
Frame 13 ID 3
8D1C9A47A35E91B
8D1C9A47A4D9024 <- 155.0089ms
<- 2.0001ms File Write delay
Frame 14 ID 3
8D1C9A47A4DDE45
8D1C9A47A607C2B <- 122.0070ms
<- 1.0000ms File Write delay
Frame 15 ID 3
8D1C9A47A60A33B
8D1C9A47A736831 <- 123.0070ms
<- 1.0001ms File Write delay
Frame 16 ID 3
8D1C9A47A738F42
8D1C9A47A865438 <- 123.0070ms
<- 2.0002ms File Write delay
Frame 17 ID 3
8D1C9A47A86A25A
8D1C9A47A9967