What's going on with Seek Thermal Compact Pro? - Page 1
Forum section: electronics / general

author: Ben321
author_rank: Frequent Contributor
timestamp: August 26, 2018, 09:01:59 am
content: I'm using it with software I wrote on my PC that allows you to use a microUSB-to-USB adapter to use the Seek Compact Pro on a PC. Now the software I wrote allows you to ignore the dark frame generated by the shutter in the device itself, and capture your own dark frame from pointing it at an object with a flat temperature gradient across it. It then subtracts this dark frame from all frames after that. This works fine for a while, but the moment that you hear the shutter click, something weird happens. Suddenly a bunch of very bright hot pixels show up on the image, for no apparent reason. You can take another dark frame, and subtract that, to get rid of those hot pixels, but that only works until the next shutter click. After the shutter click, once again a bunch of hot pixels appear on the screen.Now these hot pixels are distinct from noise. I'm talking about the noise that appears when you first turn on the camera before you subtract any dark frames at all. That noise looks like a uniform white-noise across the entire image. These hot-pixels are also distinct from the noise that you see when you point the device at an object with a flat temperature gradient and then bring up the contrast until noise can be seen. That noise looks like a bunch of light and dark horizontal and vertical lines. These hot pixels look like completely multiple pure white pixels scattered around the image that are much hotter than their surroundings, even compared to the heat coming from a human body, and have a huge impact on the auto-levels function in my program that automatically sets the brightest pixel to be displayed at 255 and dimmest pixel to 0 for display on the screen.I have added a 3x3 median filter to compensate, but this blurs the image slightly and also slows down the program so I don't get the camera's maximum frame rate of 15+fps. And even then, when too many hot pixels get clustered together, the median filter doesn't erase them all.Now if the camera was sending me true raw images, I don't think this wouldn't happen. I think I'd be able to use my own dark frames to subtract, without these weird artifacts in the image. Because these are NOT normal hot pixels (the camera does have some, and these are only slightly brighter than their surroundings). They are artifacts, because the image the camera is sending me has been pre-processed somehow, and by treating it as unprocessed (trying to get dark frames from it, as if it was unprocessed and I needed to subtract my own dark frame for getting a good image) I end up creating artifacts.Anybody have a good idea how to get around this? Attached to this post is an image showing its effect.

author: eKretz
author_rank: Frequent Contributor
timestamp: August 26, 2018, 12:11:35 pm
content: Those are likely the dead pixels on the microbolometer. You'll need to figure out a way to map them and have the sensor ignore them. My FLIR Exx has a way to do this in the service menu, pretty handy. It has a LOT less dead pixels than that though, wow. Out of the 76,800 pixels I believe mine has 27 dead IIRC.

author: tonykids
author_rank: Regular Contributor
timestamp: August 26, 2018, 02:15:10 pm
content: QuoteMy solution is: At the beginning ,use the internal reference,after about 10 min,the device has warmed up,then use external reference.

author: Vipitis
author_rank: Frequent Contributor
timestamp: August 26, 2018, 02:54:46 pm
content: are those always them same?we have had report on this forum before, where Seek had a deadpixel pattern every 35 pixel or something to evade some patent, the normal seek software just ignores those specific pixels.

author: Fraser
author_rank: Super Contributor
timestamp: August 26, 2018, 03:11:33 pm
content: Every 15th pixel is blind IIRC. FLIR sued SEEK over their 12um microbolometer design that infringed a FLIR owned Patent. SEEK blinded every 15th pixel to comply with FLIR's requirements for its use. That is a fixed grid over the whole microbolometer and filtered out in software. Easy in that case as it was a predictable dead pixel.Cheap Microbolometers are often covered in dead or bad pixels. The dead pixel map, FFC and associated processing remove them from view with little visible effect in most cases. The FLIR Microbolometers are normally pretty good but take a look at Mike's E4 dead pixel display..... it looked bad, but had little effect on the displayed picture thanks to clever processing.Fraser

author: IwuzBornanerd
author_rank: Frequent Contributor
timestamp: August 26, 2018, 04:33:00 pm
content: What you are seeing is the constant pixel by pixel adjustment of the bias used to read the resistance.Every time the camera captures a shutter frame (with ID 1) it determines what the bias on each pixel should be based on the value of the pixel in the shutter frame. If it determines that the bias should change for a given pixel, that pixels values for subsequent frames will be different by several thousand. I have observed pixels in the non-pro that toggled back & forth between the 6000 range & 9000 range EVERY shutter frame at a certain ambient temperature. The pro does the same thing but the values are higher. My guess is that they make this adjustment in order to keep the ADC output in the upper half of its operating range. Regardless of the reason it is a pain because the change in bias affects the gain compensation that you use to get smooth images. One level shift in that bias alters the gain compensation by about 5%The effect is worse for you because you don't subtract the shutter frame from frame 3, so you don't get the advantage of the value shift in frame 1. So you see a magnitude of temperature difference that corresponds to several thousand delta in pixel value. I think you'd be better off using frame 1 and trying to compensate for the bias in the gain factors. When I do my gain calibration I also save the current frame 1 to file & read that in when the program starts then with each frame 3 I check the values of the "current" frame 1 against the values of the stored fame 1 to see if they are greatly different. I scale the values with the current gain correction factors before comparing and if the difference in the old vs new scaled frame 1 value is greater than 450 I apply the 5% correction to the gain correction factor. With this threshold I catch many of the shifted bias pixels. If the camera temperature is more than a few degrees different from what it was when I captured the reference frame, though, I still get quite a few "off' pixels. I don't think the Seek app compensates for this at all, either.

author: Ben321
author_rank: Frequent Contributor
timestamp: August 26, 2018, 06:08:35 pm
content: Quote from: Fraser on August 26, 2018, 03:11:33 pmThat was only on the original Seek, I think, where the intentional dead pixels could be verified in raw mode. In the Compact Pro, there is no raw mode that has yet been discovered (the USB command to start raw mode for old Seek devices doesn't work on the Pro), only normal mode. Normal mode sends an image where the intentional dead pixels have already been compensated for (or maybe there are no intentional dead pixels at all, since the microbolometer array size is different so no pattent infringement, but I can't tell because this isn't a true raw image mode), and also likely contains additional pre-processing steps. As you can see from the sample picture above, these hot pixels are not in any pattern. They appear in random locations after the device has warmed up. And they don't gradually appear during warmup. Instead, they appear at full strength suddenly after a shutter click, after the device has had some time to warm up. And they only appear when doing dark frame subtraction. An unprocessed image from the camera (no dark frame subtraction) shows noise on the image, and a few naturally occurring hot pixels, but not these tons of processing-artifact hot pixels that appear to come directly as a result of me subtracting a dark frame from an image.Attached to this post is a picture that shows the natural noise from the camera, without any dark-frame subtraction, followed by an image that shows the result of dark frame subtraction. Notice the shotgun scatter of new (and quite strong) hot pixels in the image where a dark frame has been subtracted.

author: Ben321
author_rank: Frequent Contributor
timestamp: August 27, 2018, 09:15:09 am
content: Quote from: IwuzBornanerd on August 26, 2018, 04:33:00 pmOk, so is there any USB command that can be sent to stop the shutter's operation? I want to not depend on the shutter for calibration, and I don't really need the temperature calibration info for my purpose (just creating an LWIR image). I want to simply be able to capture a dark frame image using an object with no temperature gradient across it, and then subtract that from all future image frames. Once the camera warms up, the difference between the image frame's brightness and the dark frame should remain constant, so only one dark frame should be required. With my software's auto-levels feature it should be able to easily track the shifting brightness of the image, as the sensor's temperature changes, and once the sensor's temperature stops changing I can switch to manual levels mode, and set the levels sliders as needed for selecting the range of brightness that I want to examine. I don't need, and I don't want, the Seek Compact Pro to FORCE me to use its internal shutter.So if anybody out there has managed to reverse engineer the USB command for disabling the shutter, please let me know. Thanks in advance.

author: Ben321
author_rank: Frequent Contributor
timestamp: August 31, 2018, 01:44:55 am
content: Quote from: IwuzBornanerd on August 26, 2018, 04:33:00 pmHow do I compensate for bias in the gain factors? I think you will see from the image below I just captured, that not all hotpixels are removed when I subtract the shutter frame. Also, there is a gradient across the image (brighter near the edge, darker near the middle). I believe this gradient may have something to do with the shutter frame not taking into account temperature differences across the lens itself, as the shutter prevents the lens from being seen by the imager chip.By the way, you should read the 2 previous posts too (both by me, and neither has been replied to yet). It will give some insight into the problem I'm having, and maybe provide you with a clue how to fix it. And if you figure out how to fix it, maybe you can tell me how to fix it.Thanks for any help you can provide.

author: Ben321
author_rank: Frequent Contributor
timestamp: August 31, 2018, 08:47:41 pm
content: @Fraser last 3 posts I made, with lots of important info about my problem, yet nobody has replied. I feel like I'm going to have to figure this one out without help. The little bit of info provided earlier in this thread, didn't help me really. It just provided more questions than answers, like "what is a gain bias factor?". I'm not familiar enough with LWIR technology to know what that is, or how it might help me solve my problem, or where do I even read these factors from so that I can use them. Fraser, you seem to be an expert on thermal imaging. Maybe you can help me.

author: IwuzBornanerd
author_rank: Frequent Contributor
timestamp: September 01, 2018, 07:58:06 am
content: Well, you know, people have other things to do. I have gone for weeks and months at a time in the past without looking at this board. Likely nobody responded to reply #7 because nobody knows how to control the shutter with software. What do you expect? Do you want dozens of people to reply with "I don't know."?As for the gain compensation I don't understand how you can NOT be doing that and get any kind of usable image. Everyone else who has released software does that. I don't have time to expound on that right now either. Maybe Monday.

author: Ben321
author_rank: Frequent Contributor
timestamp: September 03, 2018, 09:34:26 am
content: Quote from: IwuzBornanerd on September 01, 2018, 07:58:06 amFrazer has been active on the thermal imaging section. He's an expert on the topic. He has responded only once to this thread, and has not provided any additional followup, even after I posted more information on the problem I'm having, information that could help him better diagnose the cause of my problem. Yet he's not replying to this thread anymore. He has replied to other threads within the last few days, but not this thread. It seems like he's intentionally ignoring this thread, forcing me to try to figure out my problem completely on my own, even though I don't have the knowledge on the topic to figure it out. And this means, unless he finally does the right thing and helps me, my project is doomed to failure.

author: Mechatrommer
author_rank: Super Contributor
timestamp: September 03, 2018, 10:23:11 am
content: Quote from: Ben321 on September 03, 2018, 09:34:26 ami guess people in the area ignoring some type of discussion because they havent encountered the problem or they have no access/knowledge about or specific to it. Fraser maybe a thermal nuts but i dont know (never closely follow him) maybe he doesnt own your camera or doesnt know how to program one. btw i own Seek Thermal Compact (not Pro) i wonder how and wish i can program in PC (WinXP/Win32 API VC++/VB) like how you do it, so hopefully i can replicate your problem. searching around led me to some linux or VC# infrastructure which i'm not familiar with. so i just ignore this topic or.. just come by as a silent guest/viewer, maybe i can learn something...

author: Fraser
author_rank: Super Contributor
timestamp: September 03, 2018, 11:16:02 am
content: Ben321,Not ignoring you or this thread. I simply have no experience on the SEEK cameras. I bought the original Classic model when released, was unimpressed with what I saw and rehomed it. The SEEK cameras are not something I have studied or am likely to. For this reason I tend to avoid threads discussing the SEEK products. I will revisit this threads contents though and see what sense I can make if it.I try to only comment when I have useful input, otherwise it just decreases the signal to noise ratio of the threadThis is only a hobby to me these days so please understand, I feel no compulsion to provide information in a timely manner, but I do try to respond quickly.Fraser

author: Fraser
author_rank: Super Contributor
timestamp: September 03, 2018, 01:11:44 pm
content: OK, I have read the thread. Hmmm, did I say I do not like SEEK phone cameras ..... nothing has changed on that frontI think some microbolometer basics are needing to be covered here. Forgive me if you already know all this but it is essential that you understand the basics so I am just making sure.1. Microbolometer pixels are inherently unstable ..... note this well !2. Microbolometers using the 12um pixel size appear to be more noisy and less stable that larger pixel Microbolometers. That is just the trade off that must be accepted and dealt with in image processing etc.3. To use a microbolometer successfully in terms of a decent image there are various issues that must be dealt with....a) The bias voltages must be set on the microbolometer pixels to provide the required sensitivity. Higher sensitivity is usually accompanied by lower dynamic range. The bias voltages are normally generated 'off chip' by a microprocessor controlled multiple channel DAC. This enables fine tuning of the voltages but they are Global and not pixel specific.b) the temperature of the microbolometer Die is monitored using a number of diodes on the Die itself. This enables the host system to compensate for Die temperature drift. In a non temperature stabilised Microbolometer, the Die can drift easily and this often limits the sensitivity set using the bias voltages.Offset tables are used to counter the effects of Die temperature drift but these are often Global offsets and not pixel specific. It is not unusual for geneneric offset tables to be used in budget cameras. This means they are offset tables that are generated from real world testing of many sample Microbolometers to profile the Die Delta T response for the series. That means it is a compromise offset table and not always perfect in every camera. The further away from the 'ideal' Die temperature you go, the more error creeps into the offsets applied. The Die is usually profiled at its nominal operating temperature. In a non stabilised core this is the point at which thermal equilibrium is reached. As a non stabilised system, that Die temperature is subject to change however.c) A microbolometer FPA is basically a Collection of unmatched thermistors. I say unmatched because they are formed by the same process during fabrication but there is no 'select on test' applied to each pixel ! As such the microbolometer can be a relatively unruly 'beast' that needs taming. Failure to tame the Microbolometers bad habits will result in poor imaging that contains flickering pixels, blotches and temperature gradients across the scene. More detail on taming the Microbolometer later.d) The scene information coming out of the microbolometer can be very noisy, especially in budget Microbolometers using 12um pixels. This noise is usually dealt with using DSP and produces cleaner images that are pleasing to the eye, yet still accurate in temperature content in a Radiometric camera.The quality of the video processing often dictates the quality of images produced by any given thermal camera (beyond using decent hardware of course). Poor video processing normal, means ugly pictures.4. Taming the microbolometer. This is where Ben321 may find something of interest.....As stated, microbolometer pixels are unstable by nature and prone to output drift. Remember that a thermal scene heats or cools each pixel so it's surface temperature is ever changing. If presented with a constant temperature flat field scene, the pixels come back to a nominal point in their operating range and it is possible to see if any pixels are different to those around them, or outside the acceptable nominal for the majority of pixels.At the time of manufacture a thermal camera is configured to produce the required picture quality and measurement accuracy. This is commonly called calibration, but in truth it is two processes. Image correction followed by calibration of measurements from the 'corrected' microbolometer ROIC output.The camera is aimed at a full field thermal scene that is 'flat' with little or no Delta T present. The microbolometer pixels all see the same scene at their surface but there may be differences in the actual energy present on each pixel due to the characteristics of the optics. A computer analyses the output from each pixel and maps the levels ready for correction. Any pixels that are producing a level outside a predefined acceptable range are 'marked' as 'Bad'. Dead pixels are treated as outside the acceptable range so are also captured. Pixels that are providing an output that is within the acceptable level range are further analysed to determine whether any adjustment is needed to the level in order to bring them into the closest possible match across the FPA. There will always be pixels that need to be corrected to make them appear the same as the rest on the FPA. This is Non Uniformity Correction and it can take account of all manner of naughtiness on the part of the microbolometer. The end product is an output to the cameras measuring and display systems that looks nice and 'flat' across the whole FPA. Dead or rejected pixels are disguised using image correction that masks their 'spot'. Such pixels do not adversely effect the measurement accuracy of the camera as they are 'repaired' in the system software.As already stated, Microbolometers are unruly beasts that have a habit of drifting with time, scene and ambient temperature. The NUC is carried out at a specific ambient temperature and looking at a set scene temperature. It is possible to have multiple NUC correction tables though. These would be created at differing ambient temperatures and different scene temperatures to effectively map the behaviour of the microbolometer in most expected operating conditions. Such techniques are used in shutterless microbolometer cameras. Profiling a microbolometer can be time consuming though, so some manufacturers may choose to cut corners in the way such NUC tables are created.The NUC process is effective at identifying dead or unacceptable pixels. It generates the base line for each pixels output compensation to achieve a nice flat field across the image. This can also include corrections for a less than perfect lens system. Remember lenses are thicker at the centre than the edges so transmission loss through the lens material does differ across its profile. This is why you can sometimes see a 'cooler' centre to an image when the lens characteristics have not been compensated for.There is a need for dynamic correction of the output from the pixels as they are anything but stable when in use. As the scene illuminating the FPA is ever changing, it can be hard to keep track of pixels that are drifting away from the others in terms of nominal output level tracking. There are dynamic pixel monitoring algorithms in non shuttered cameras that use scene pixel group analysis to detect such rogue pixels but a shuttered camera uses a known flat field to bring rogue pixels into line.During a Flat Field Correction event, a shutter or "Flag" is brought into the optical path either between the lens and microbolometer or in front of the lens objective. OEM's decide which they wish to use. The temperature of the shutter/flag is normally that of ambient within the camera or exterior ambient in the case of the external shutter/flag. This temperature and the fact that the shutter/flag is relatively flat in terms of Delta T across its surface, enables a FFC offset table to be produced that results from analysis of all pixels on the FPA. This is a sort of fine tuning pixel gain adjustment map that is dynamic in nature, unlike the factory set NUC tables. If a pixel, or pixels, drift away from the average of the others when looking at a flat field, they are corrected in the FFC table. The global temperature measurement offset may also be extracted from the FFC event in order to maintain camera measurement accuracy during use in different environments. Remember, the FFC shutter/flag has a known temperature. The FFC event has a period dictated by the OEM based upon their knowledge of the Microbolometers stability. Most industrial grade thermal cameras carry out an FFC every 120 seconds or so. They often offer the option to increase this period or even deactivate FFC for video capture. Such deviations from the standard setting normally come with the warning that measurement accuracy and flat field performance will be adversely effected. The SEEK cameras use a very short FFC event period and this reflects the very poor stability of the microbolometer that they are using. It drifts so quickly and badly that the only way to tame it is to have an FFC event every few seconds ! Using a single FFC after warm-up and then running without further FFC events will very likely result in lots of sparkling pixels and blotches on the displayed image within a relatively short period of time. SEEK know this, hence the inability to either increase the FFC period or disablement of it.Ben321, I do not know the internal software design of the SEEK cameras, but I do know that the OEM was trying to make a Silk Purse out of a Sows Ear with the microbolometer they are using. All manner of effort has gone into taming it as without such it likely produces ugly images that require a lot of processing to tidy up. They already tax the average phone with the current processing required in their Apps. There will be an amount of processing of some sort within the camera so true RAW data may not be available in your case. With that in mind you are effectively 'fighting the system'. You want to do something that the OEM never wanted to happen.... disablement if the FFC event that makes the Microbolometer useable. The 'system' will likely continue to apply FFC offsets no matter what post processing you are doing. As such the offsets may create these troublesome pixels you keep finding.That is enough from me for now. Please excuse the likely many typos that this response contains as I typed this in a hurry on an iPad.Fraser

author: Fraser
author_rank: Super Contributor
timestamp: September 03, 2018, 01:55:13 pm
content: Ok, further to my last.......When using a microbolometer 'core' it is advisable to make full use of the OEM's correction measures that tame the microbolometer. That is to say, you respect any warm-up period for reasonable Die stability, you use any and all NUC correction information and you use the provided FFC information to maintain a decent data set to process in your computer.With Microbolometers "RAW" mode with no NUC, FFC or other pertinent corrections is not normally desirable as the data produced by the ROIC can be very ugly indeed. These are not like CCD chips. Microbolometers have become useable because of the clever correction systems, not in spite of them.Say after me . "True RAW microbolometer output is nasty"If an OEM has not done a decent job of processing the corrected microbolometer data then by all means improve upon that software processing element. If the OEM has done a poor job of the basic corrections needed for their microbolometer to produce a good image.... ditch the core and buy something better from an OEM who does the job properly !The SEEK should really be seen as a complete "core" and so a sub system of a thermal camera system. It was not intended to offer up its true RAW data and presents its data for processing on the host after cleaning up the many issues that would exist within the scenes produced. You are not accessing the microbolometer ROIC directly and that is both intentional on the part of the OEM and good practice for such a modular solution.If you really want to get to RAW data, either find a core that provides such, a microbolometer development system or build a core around a ULIS microbolometer. Modern Microbolometers contain very friendly ROIC's that talk I2C for configuration, generate their own clock sets and make interfacing easy via built in DAC's and ADC's.Fraser

author: IwuzBornanerd
author_rank: Frequent Contributor
timestamp: September 04, 2018, 12:19:53 am
content: Quote from: Fraser on September 03, 2018, 01:11:44 pmI have been making my claim of pixel bias adjustment based solely on what I have observed on my Seeks and I should always preface that claim with "I think" or "I believe", but I guess I have gotten too comfortable with the idea even as I have been unable to find any factual confirmation of that rationalization...until, perhaps, a few minutes ago when I finally picked the right set of search words to get something useful. U.S. patent #5,756,999 from 1998 says:Correction for temperature-induced non-uniformities in the response characteristics of the microbolometers in an infrared focal plane array (FPA) is performed by applying a non-uniformcorrective bias to the individual microbolometers. The corrective bias is applied either before or during the bias or integration period during which the detectors are sampled. The bias-correction can be applied to two dimensional detector multiplexers at each column amplifier input, the reference potential for each column amplifieror the voltage supply for each detector element... This invention allows the operation of a microbolometer FPA over a wider range of device substrate temperatures and thereby significantly reduces the complexity and cost of the system as compared with the conventional technique of cooling the FPA.I found this here:https://patents.google.com/patent/US5756999and it kind of looks like what I need to back my claim. Or am I interpreting it wrong? Just because there is a patent does not necessarily mean it has been implemented I guess.

author: eKretz
author_rank: Frequent Contributor
timestamp: September 04, 2018, 01:02:36 am
content: Yes patents often leave things intentionally vague or provide several "possibles" so that one way or the other can be implemented and still be covered. There's no telling from the patent what they are actually doing. The patent is only saying "We can do it this way or this way." I researched a patent once that had over a dozen variations.

author: Ben321
author_rank: Frequent Contributor
timestamp: September 04, 2018, 08:33:51 am
content: Quote from: Fraser on September 03, 2018, 01:11:44 pmVery interesting.As for how I'm using the camera, and what my problem is:The unprocessed image from the Seek Compact Pro looks very grainy, but this can be fixed easily with a dark frame subtraction. When I take my own dark frame by pointing it at a surface with low DeltaT across it, and then subtract it from all future frames (and just discard the the Seek's own shutter-created dark frames, rather than using them), it works at first. But then later, I find that spontaneously pure white pixels appear. Keep in mind these are not pixels that just slowly drift into existence by temperature drift. These are pixels that look normal in all preceding frames, and then suddenly appear pure white at some point, and don't ever go away or even flicker in and out of existence (though they can be successfully subtracted out by taking another dark frame image by once again pointing the camera at a surface with low DeltaT across it, and subtracting it from all future frames). But even with these white pixels in place, the rest of the pixels in the image look perfectly normal. Something interesting about them is when they appear. While I can't predict exactly when they appear by counting the number of minutes of camera operation until they appear, there is one thing that is certain about when they appear. They ALWAYS appear after a shutter event. They NEVER appear during the normal stream of thermal video frames. It will be like normal video, then a shutter event happens and these white pixels appear on the first normal frame after the shutter event. And then they NEVER go away on their own. I need to take another dark frame to subtract them.I had been assuming that the image I was getting from the seek was truly raw, and that I could override the Seek's own dark frame subtraction with my own dark frame subtraction by simply ignoring the shutter frames. I'd been assuming that the Seek camera performed none of its own processing (instead depending on the app to do all the processing), and that the normal camera app simply was subtracting raw shutter frames from raw image frames. And I thought I could do better than the official app by allowing the user to take their own dark frames. But it now seems that the Seek does not provide any actual raw image or shutter frames. While it does provide shutter frames and regular frames, these appear to already be pre-processed in some manner. I don't know what manner of pre-processing this is, but whatever it is, it is such a manner that REQUIRES that the shutter frame be subtracted from the image frame, and does NOT allow (after a period of a few minutes) the end user to substitute their own dark frame taken of a flat-temperature surface in place of the shutter frame. I'm hoping @Fraser you can look at the images I have posted in my posts above, and by looking at the nature of those images, tell me just what kind of pre-processing it is likely that the Seek is performing on the image frames. Maybe there is some way to somehow cancel out the Seek's pre-processing (either by sending an undocumented USB command discovered by hackers, or else by figuring out the pre-processing algorithm and subtract that pre-processing algorithm from the image to get a truly raw image). And if I can cancel out the Seek's pre-processing algorithm, then I would actually be able to use my own dark frame captured by imaging a surface who's DeltaT is very small across that surface. That's what I'm trying for here. And that @Fraser is why I need your expertise on thermal imagers.

author: Fraser
author_rank: Super Contributor
timestamp: September 04, 2018, 11:00:07 am
content: Ben321,I am sorry but I cannot provide what you are asking. You assume I know more about the image processing than I do. I just do not have the spare time at the moment to dig deeper into the SEEK camera.This is going to be your own voyage of discovery and I wish you well on it. I am, and always have been a hardware tech. The intricacies of the image processing side of thermal cameras remains a mystery to me.Fraser

author: Fraser
author_rank: Super Contributor
timestamp: September 04, 2018, 11:23:27 am
content: IwuzBornanerd,Nothing you have previously stated was incorrect, hence I did not make comment at the time.As stated in that Indigo Patent, there is a need to adjust the output level of each pixel as required to form a flat field scene when the microbolometer is exposed to a known flat field with little or no Delta T across it.As we know, each pixel in a microbolometer has a bias voltage applied to it. This bias voltage directly effects the behaviour of the FPA when used in a camera. The Microbolometer manufacturer normally provides bias data with the device. There is normally more than one bias voltage specified to suit different performance needs. These bias voltages are the baseline settings for the microbolometer and may be fine tuned in a specific camera to achieve the desired performance. The bias voltage is Global in nature. That is to say, all pixels see this nominal bias voltage. There is also blind pixels bias to consider but I will not delve into that now.Now we have already established that pixels vary in output and require both Non Uniformity correction and Flat Field Correction by some means to produce a good image. To achieve the required correction, the output of a pixel needs to have a correction offset applied. There is more than one way to apply that correction offset. Yes it can be via direct changes to the bias on a particular pixel, or it can be via changes to the offset input to the appropriate ROIC amplifier. It may also be applied in software that interprets the ROIC ADC output. There are many ways to achieve the desired result. Basically each pixel is profiled at the standard set bias during NUC and the required corrections for each are established. FFC is just a dynamic fine tuning version of that that process. The pixel corrections are normally carried out in real time and, as stated in the referenced Patent, there are convenient points in the read-out process to apply the corrections.As with many systems, there are often several ways to achieve the same result. What must always be born in mind though is that the bias voltage applied to the pixels and amplifiers must be very low noise as any noise introduced at that stage of the image forming process ends up as more work for the noise reduction processes that follow.Fraser

author: Fraser
author_rank: Super Contributor
timestamp: September 04, 2018, 12:25:33 pm
content: I have been asked (offline) why the pixel bias voltage needs to be chosen with such care.I have a two word response ....... "Self Heating"The bias voltage applied to the microbolometer creates a current through the resistive pixel. Current through the pixel produces self heating. The higher the pixel bias voltage or longer the duration of it on the pixel, the greater the self heating effect. For this reason the lowest useable bias voltage and resultant current needs to be determined for a particular microbolometer type.Self heating is BAD for microbolometer performance. To minimise the self heating effect the bias voltage, and the duration that it is applied to the pixel, is carefully set.Blind Pixels are also used in some Microbolometers to provide an unexposed reference for differential comparison to a live pixel and counter the effects of the bias heating on the live pixel output. Microbolometers and associated ROIC's deserve a thread to themselvesThey are far more complex than some would expect. Did I mention they were unruly beasts that need some serious taming to meet the needs of a decent thermal sensor FPAFraser