Interesting way to check your SEEK SHOT bad pixels - with pictures - Page 1
Forum section: electronics / general

author: Logan
author_rank: Frequent Contributor
timestamp: September 01, 2021, 01:23:23 pm
content: Hi guys.I found that when you point SEEK to something very cold and even, you can force it to show the bad pixels that is normally hidden.Just 3 pictures showing both the Pro and non-pro version when pointing at clear sky:I don't know if the Reveal/Compact are also affected by this, but it's interesting anyway.Thanks for watching.(Seems the inline picture is not working, never mind, just click the thumbnails to enlarge)

author: Fraser
author_rank: Super Contributor
timestamp: September 01, 2021, 01:43:49 pm
content: That is actually quite appalling and the first time I have seen a camera fail so badly at concealing it’s dead pixels when looking at a cold target, if that is in fact what you are seeing. It could also be that you are just revealing the variation in low temperature scene sensitivity of the pixels in the array rather than dead pixels. Dead pixels should be concealed from the user at all temperatures as it is a pixel replacement system that uses surrounding pixel values. I have not seen this effect previously on a thermal camera and sadly it is a deficiency in the design, but one that likely only occurs when imaging outside of specification.Fraser

author: Logan
author_rank: Frequent Contributor
timestamp: September 01, 2021, 01:48:19 pm
content: Quote from: Fraser on September 01, 2021, 01:43:49 pmWhy notBoth on saved images(1 and 2), and another camera point at the screen(3).

author: Fraser
author_rank: Super Contributor
timestamp: September 01, 2021, 01:51:49 pm
content: Because dead pixel correction does not care about the scene per se. It uses a dead pixel map that identifies the dead pixels and uses surrounding pixel values to create a value for the dead pixel that hides it from the user. Pixel temperature response and correction applies to all active pixels and can fail at extremes of temperature specification and lead to loss of flat field in the image.

author: Bill W
author_rank: Super Contributor
timestamp: September 01, 2021, 03:39:20 pm
content: Quote from: Fraser on September 01, 2021, 01:51:49 pmMay well depend upon the background maths being used which may then hit the limits of number space and suchlike. So if correcting a pixel with some neighbours at -39°C and applying the expected gain and offset function gives a digital wrap around or clips to zero at some point ....It is though surprising how bad a sensor can be and still come out looking OK. I have seen (through misadventure not manufacture) a sensor with around 15% dead come out virtually indistinguishable from a good one. You needed a resolution chart to show them up

author: bap2703
author_rank: Regular Contributor
timestamp: September 01, 2021, 08:52:09 pm
content: Seek sensors do not have the weird reference pixel pattern anymore?They would be hidden with a different algorithm than real dead pixels and not show up here among them?

author: Fraser
author_rank: Super Contributor
timestamp: September 01, 2021, 09:48:14 pm
content: The early Seek Thermal 1st Generation microbolometer had every 15th pixel inoperative in order to comply with a Patent claim by FLIR. I understand that Seek Thermal were not going to do this on later generations of microbolometer and we are now at least 2 Generations on from that point in timeThe original disabled pixels were treated as dead pixels as that is effectively what they were. The treatment to camouflage those non operative pixels is no different to that of normal dead pixels.Fraser

author: IwuzBornanerd
author_rank: Frequent Contributor
timestamp: September 01, 2021, 10:14:50 pm
content: Is the claim that all those white specs are dead pixels?If so the next thing that needs to be checked is if the pattern changes with each FFC flag event [edit:] (less change once the thing is warmed up). It appears to me that the pattern is the same in the first 2 photos but vastly different in the 3rd photo [edit:] Oh, wait, different camera? And what is the span that the camera reports for the first photo? If it's only a few degrees then how can you claim the white spots are dead? I believe that this is nothing more than the effect of the constantly changing pixel bias that gets re-figured with each FFC flag frame (if the shot has one). The bias change has about a 5% effect on the gain correction (for one step change) & if the temperature of the sensor is different from what it was when the gain correction factors were calculated there will be those pixels where the difference in gain will show up. This, of course will be more obvious at narrower temperature spans [edit:] and with scenes at temperatures farther from the flag temperature--as it appears in the difference between the first 2 photos above. As far as I can tell, Seek makes no attempt to correct for this effect of the bias change [edit:] other than with their image smoothing.I attach 2 fresh samples from my FF Pro shortly after a fresh 2-point NUC (when a uniform temperature should ideally make a single-shade image). These show the effect of the already changed bias as one image is with my bias correction turned on & the other is with it off. The minimum temperature pixel in the images may well be dead as it appears to be in the same place in both photos & the max was jumping all over the place at that time. It's stable now though...Edit: I should clarify that the attached images are from my software, not the Seek app and I had my pixel averaging off also, so my white specs are not fuzzy like the ones in the images above. And the camera was not fully stabilized at temperature yet.Also, I believe that Seek has indeed gotten rid of the every 15th pixel=0, as a forum member posted some raw frame data from a newer Compact & the data did not have the zero pixels.

author: Logan
author_rank: Frequent Contributor
timestamp: September 02, 2021, 01:30:20 pm
content: Quote from: IwuzBornanerd on September 01, 2021, 10:14:50 pmThey are indeed different cameras.The pattern do not change by FFC.If the temperature is not that cold, but close to, then the white pixels will be darker.

author: IwuzBornanerd
author_rank: Frequent Contributor
timestamp: September 03, 2021, 02:23:14 am
content: Thanks for the response.I should have thought to note that when the sensor is stabilized at a temperature the pixels affected by bias change will be fairly stable, but I still expect a few to come & go. Does the pattern NOT change during the first 2 or 3 minutes after turning the camera on? Or was that the situation in the images above? If they are what I claimed they are the number should change noticeably during warmup. If this does not happen I'll have to shut up about it.I could be wrong; it has happened before.But again, what does the camera say the temperatures of those pixels are? Apparently they are warmer than -40 but cooler than 149. Maybe they aren't dead but reach a limiting value that yields a temperature above -40; perhaps for the reason Bill W. suggested.

author: Logan
author_rank: Frequent Contributor
timestamp: September 03, 2021, 12:26:13 pm
content: Quote from: IwuzBornanerd on September 03, 2021, 02:23:14 amNo, the pattern never changes.All pixels are shown as -40C, I think the camera just capped the display value at -40, but it can actually sense something lower.

author: Ultrapurple
author_rank: Super Contributor
timestamp: September 09, 2021, 10:17:28 am
content: This is proving very interesting. I will point my SEEK Reveal Pro at the cold sky and see whatIget. I will report back.

author: Fraser
author_rank: Super Contributor
timestamp: September 09, 2021, 11:35:26 am
content: The Infiray T3C seems to have some issues when imaging the sky as well…..https://www.eevblog.com/forum/thermal-imaging/infiray-t3c/My FLIR E4 and E60 do not display such anomalies when viewing the sky so this is not a universal issue amongst thermal imaging cameras. As Bill has stated, it is likely just a case of a particular camera reaching its minimum temperature ‘end stop’ and misbehaving as a result.Fraser