If I could suggest, how about an image sharpness filter? Even a basic unsharp mask or a regular sharpening filter would really put the final touches on determining what can be pulled out of the sensor. If you manage to implement a sharpening filter
Excellent work. Impressive results. 👍Thank you. ;)
Is there any chance to port kind of this soft to android? I know that you are using specific libraries that are only windows compatible.I don't think I'll be porting it to android. Mainly because I don't have the knowledge to make android apps. ;D
I may have to buy a cheap SEEK camera and use it with your software :)Why on earth would you do something like that? :-/O (With my software it's just a little less crappy...)
I really want SEEK to succeed and that maybe why I do not want to completely abandon them ?
Is there any chance to port kind of this soft to android? I know that you are using specific libraries that are only windows compatible.I don't think I'll be porting it to android. Mainly because I don't have the knowledge to make android apps. ;D
I will go into a different (hardware) way: RPI2 + 5" TFT + 5000mAh powerbank + nice handle + Seek with external shutter
You could make a USB OTG cable yourself. Just make sure you connect sense pin to the ground.
This way you don't have to worry about socket orientation on the tablet.
(http://tech.firstpost.com/wp-content/uploads/gallery/2012/jun/difference_circuit_271738111300_640x360.jpg)
Cool. Now how about instead of posting the source code, post the latest compiled EXE file.
It may be that .net is the latest "cool" thing in writing Windows software, but it also requires the MASSIVE .net framework, making it an overbloated way of writing software.
If you don't happen to have the correct version of .net, you need to download it and install it, and that total process of downloading and installing it takes about 1 to 2 HOURS.On dial-up perhaps? Client Profile verisons are about 40MB and it takes another 5min on regular pc to install... And the latest .net 4.5 is 50MB (complete version).
So for the love of all that is good, PLEASE rewrite this software in a way that doesn't require .net
//get gain of each pixel:
gainCalArr[i] = avgID4 /arrID4[i]
//subtract frames and apply gain to diff:
currentFrame[i] = (arrID3[i] - arrID1[i]) * gainCalArr[i] + 7000;
Cool. Now how about instead of posting the source code, post the latest compiled EXE file. I may some day eventually get a Seek thermal imager, and when I do I don't want to be stuck compiling the software myself. I don't even think I have the right version of Visual Studio to compile this. And by the way, PLEASE don't use .net for it. Please write a non.net version, for those that don't have the particular version of .net required by this program. I HATE programs that use .net instead of being plain old Windows EXE files. If you don't happen to have the correct version of .net, you need to download it and install it, and that total process of downloading and installing it takes about 1 to 2 HOURS.
It may be that .net is the latest "cool" thing in writing Windows software, but it also requires the MASSIVE .net framework, making it an overbloated way of writing software. Unlike most programmers out there, I have NOT jumped on the .net bandwagon. When I write my own software, it's plain old Windows software. I usually use VB6 for the majority of the programming, and if there's a feature that VB6 doesn't have that I need in my program (such as the atan2 function that C and C++ has, but VB6 doesn't) I will then use VC++ 2010 to write a plain old DLL file (nothing that requires .net) that wraps the required C or C++ functionality (such as the atan2 function) in a function that is exported by the DLL file, so that it is accessible to VB6. That's as a software writer.
As a software consumer, I usually will avoid LIKE THE PLAGUE any software that requires .net because I don't want to possibly have to spend 1 or 2 hours downloading and installing the latest version of .net, or an older version (yep that's right, the latest version doesn't have everything the older versions did, so if you have a program that depends on an older version of the framework, you actually have to go back and download an OLDER version of .net, and if it's too old MS might not even supply a download for such an older version of .net anymore).
So for the love of all that is good, PLEASE rewrite this software in a way that doesn't require .net, and PLEASE include the compiled EXE, not just the source code.
There are a lot of smart people here and I need your help. ;)
This values were taken while pointing Seek to uniform thermal plate.
Columns:
ID4 - values of gain? pixels which never change; (avg=3950)
gain - calculated gain (ID4/avgID4)
ID10 - values of gain? pixels which never change
ID1 - calibration frame, this is thermal image of shutter; (avg=7700)
ID3_25C - image of uniform thermal plate at 25*C (77*F); (avg=7400)
ID3_75C - image of uniform thermal plate at 25*C (167*F);(avg=9500)
diff - subtracted: ID3_75C-ID3_25C (should be 2900)
So in ideal world all ID3_25C values would be 7400 and all ID3_75C would be 9500.
Difference would be 2900 which corresponds to 50*C (90*F).
What needs to be accomplished is:
1. How to use ID4, ID10, ID1, to fix values ID3_25C so that all are 7400.
The same algorithm should also work for fixing ID3_75C so that all values are 9500.
2. How to use ID4, ID10, ID3_25C, to fix values ID3_75C so that all are 9500.
Or how to use the same columns for fixing difference ID3_75C - ID3_25C so that all diff values would be 2900.
Tnx! :)
P.S.
CSV file is in the attachment.
I never see any mention of frameID9 on here; don't other cameras have a curve in frameID9?
Frame 2 (ID 9) is a bit bizarre, because it shows a nice gradient, like if during boot the chip shows that the memory is writable and is just to make sure it can be read. It's pretty smooth with no dead pixels (other than pixel 10) and maybe some others that I can't see. the original range goes from [2000 to 16383] (both included) it didn't translate well to 8 bits. Maybe that's the actual sensor range for raw data, not sure. Also it might be the firmware that outputs the gradient, doesn't have to do anything with the sensor for all we know.(https://www.eevblog.com/forum/testgear/yet-another-cheap-thermal-imager-incoming/?action=dlattach;attach=117244;image)
I never see any mention of frameID9 on here; don't other cameras have a curve in frameID9?
I still think it must represent the range of sensor values but didn't look more into it since then.
I believe you mean that someone should capture raw values while pointing seek to a black body with adjustable temperature?
My is seek is the one with apple connector, Can "run this siftware with a "special wiring ?