Shifted pixel columns on Therm-App - Page 1
Forum section: electronics / general

author: Ultrapurple
author_rank: Super Contributor
timestamp: August 19, 2017, 02:17:58 pm
content: A number of Therm-App imagers have one or more pronounced 'streaks' on the display, where an entire column is shifted down (or up) one or more pixels. This is quite distinct from normal bad pixel effects: experiments have conclusively shown that it is a column being 'read late' (or early). The attached picture shows an example, which was deliberately engineered to look bad (zoomed image, sharp horizontal transitions etc). In Real Life™ it doesn't look anything like as significant.Is the Therm-App (or the Pico384 it's based on) unusual in this respect, or is it something that's seen in other imagers?

author: Fraser
author_rank: Super Contributor
timestamp: August 19, 2017, 03:25:15 pm
content: I can state that this is not typical of the Pico384.It looks like a timing glitch in the read-out IC but this could be caused in the video processing stage as well.IIRC the ULIS Pico384 is the new generation of Microbolometers that just need the master clock input and not the usual H and V timing signals. The master clock generates all required timing signals for the ROIC. These are the H sync, V Sync and Pixel clock. The control lines to the ROIC set it up but do not create any timing signals.Older generations of ULIS microbolometer were slaves to external timing signals and could even suffer damage if a timing signal was absent ! Designers had to be very careful about how they supplied the H, V and Pixel clocks to the microbolometer and safeguards were designed in to protect against loss of a timing signal.The modern Pico384 acts more like a master timing source as once it is set up and has the master clock applied, it generates not only the internal sync and clock signals but it also outputs sync and clock signals to the video processing stages that follow. Effectively the master clock sets overall timing and the microbolometer ROIC sets all image related timings.In your image it looks like a column is out of alignment but I suspect the microbolometer is rotated 90 degrees so it is a row error as you say. I am wondering whether the master clock contains a glitch signal that is causing this problem. It would be interesting to see an oscilloscope capture of the master clock to see how clean it is. Remember, we know the Pico384 does not normally have this issue and all it's timings come from the external master clock. The master clock is therefore the first place to check for weirdnessI am not certain that this is the problem though as the following rows are read out with the correct timing with respect to the rows that preceded the glitch. I would expect a master timing glitch to throw all subsequent rows out of step.If this is a master clock glitch, the camera effectively has a fault and should be repaired under warranty.Another possibility is a bug in the video processing stage that is introducing a timing offset in one row as it is read out. Note that the offset does not cascade through the following rows. The timing steps out of spec for one row of pixels and is then correct in the next row. Weird stuff. A software timing issue would be harder to diagnose without the camera in some form of debug mode.Hope this is food for thoughtFraser

author: Fraser
author_rank: Super Contributor
timestamp: August 19, 2017, 03:47:03 pm
content: The more I think about this, the more I think it is a software timing glitch in the video processing stages. The H and V sync signals are sent to the video processing stage. If for some reason one of the row read outputs is delayed during video processing, you will get your symptom. The next row will be resynchronised by the ROIC sync signal that is always correct and in step with the ROIC reading of the microbolometer.Your symptom of a stepped row is like the video processing stage having a hiccup before resuming normal operation and synchronisation. Such a hiccup could be caused by higher priority processing task that interrupts the video processing stream. The fact that the stepped row remains on the image rather than just a single frame glitch suggests a repetitive hiccup caused by a timing locked interrupt of some sort.I am way outside my comfort zone when it comes to the idiosyncrasies of software video processing timing signals and interrupts so maybe someone else will better understand what could cause this problem ? I may even be talking out of my backside. Forgive me if this is the case.Fraser

author: Fraser
author_rank: Super Contributor
timestamp: August 19, 2017, 04:52:45 pm
content: The attached block diagram may assist you in understanding the topology of modern ULIS microbolometer camera system.This information is already in the public domain so I am not releasing sensitive materialThe DAC's set the bias voltages on the pixels and the ADC converts the analogue read-out of the pixels to digital format for video processing. Note the Reset/INT/MC inputs. The MC input is the Master Clock. The sync signal outputs can also be seen.This is a development board for the ULIS Nano and Pico 384 and 640 microbolometers. It is similar in many respects to what will be configured within the therm-App but minus the ancillaries like the display etc.Fraser

author: Ultrapurple
author_rank: Super Contributor
timestamp: August 19, 2017, 05:04:27 pm
content: Thanks FraserMine is not the only one that has this issue; there has been some discussion about it on theFlickr Therm-App group. The few examples posted on the Flickr page have the glitches in different positions on different imagers; by no means all are affected, and it seems to happen with different back-end processing software (the native Therm-App app and Therm-App Plus for definite, not sure about others) so that suggests it's either happening in the hardware/firmware or the driver. My thought is that it's probably happening in the hardware (ie sensor) because I had the same effectin the same placeon the original firmware before it was upgraded from 9Hz to 25Hz frame rate.Just to make sure we're speaking the same language, for the 4:3 384 x 288 Pico384 I'm calling the 384-pixel axis a "row" and the 288-pixel axis a 'column'. So, when held in TV orientation the rows are horizontal. The scan definitely seems to be row-by-row (the 8.7Hz version has the classic rolling vertical shutter effect), so why it would glitch at exactly the same place on each line - and read out thepreviousline is a total mystery.My cameras are old enough to be out of guarantee. It was onlybecausethe warranty had expired that I felt comfortable having the case opened for the 25Hz upgrade: doing so goes straight through the 'warranty void' label.So yes, it is very odd indeed. The only practical 'cure' suggested so far is to mark that entire column of pixels as bad, but that would probably be even more noticeable than the present glitch.Can you post a link to fuller details of the dev board? I guess it's expensive...

author: Fraser
author_rank: Super Contributor
timestamp: August 19, 2017, 05:27:55 pm
content: A ROW is the horizontal line of pixels ON THE MICROMETER DIEA COLUMN is the Vertical line of pixels ON THE MICROMETER DIEThe read out process is as follows:The detector is read row by row in a continuous frame rolling shutter mode (electronic scanning). Inthis mode the row V integration and row V-1 readout run simultaneously. While a row of pixels is beingreadout, another row is being integrated; the start of each row integration for rows is staggered.I have sent you some bed time readingEnjoy !Fraser

author: Ultrapurple
author_rank: Super Contributor
timestamp: August 19, 2017, 06:14:31 pm
content: Quote from: Fraser on August 19, 2017, 05:27:55 pmYes, we agree (and, naturally, you state it more precisely than I did).QuoteThanks - I will enjoy my treat!G

author: Fraser
author_rank: Super Contributor
timestamp: August 19, 2017, 06:30:26 pm
content: I have found with some thermal cameras that the microbolometer is rotated 90 degrees and so the microbolometer rows change to a vertical plane on the display unless the frame is rotated in the video processing stage. It can get quite confusing !OK, as you say, the rolling shutter effect suggests that the rows on the die are horizontal in the displayed image. As you can see from my comment regarding the read-out of the microbolometer, a row is extracted into a FIFO buffer. It is integrated whilst another row is loaded. The two rows should not interact as it is a serial data stream and not parallel. Something very weird appears to be happening. Could it be a faulty memory cell in the FIFO ? If so I cannot see why it would contain any useful data, let alone that of the previous row. I regret I cannot explain this situation.Fraser

author: Bruno28
author_rank: Regular Contributor
timestamp: August 19, 2017, 10:12:37 pm
content: Mine had this issue. One of the guys in flicker helped to fix. Apparently the 1.bin file needs to be modified to adjust the pixel shift. Or you can send to Opgal which they said they can fix buy costs $400 usd.As you can see I had one very bad line that was fixed.First photo is with the line issue and second is corrected.Sent from my SM-G935F using Tapatalk

author: Fraser
author_rank: Super Contributor
timestamp: August 19, 2017, 10:18:41 pm
content: Very interesting !So the question is, is it a hardware issue that the software can compensate for, or a software issue that needs to be 'tuned' to correct it ?Either way, I feel sure those who own a Therm App will be pleased to hear that it can be corrected in software.Fraser

author: Bruno28
author_rank: Regular Contributor
timestamp: August 19, 2017, 10:24:07 pm
content: Quote from: Fraser on August 19, 2017, 10:18:41 pmCORRECTED POSTNot sure if its hardware of software. All i know os it can be corrected via software.From what i gathered from the guy who helped me, the 1.bin file can be adjusted to correct. The guy that did for me said that sometimes the line moves and others stays in same location. Luckily for me mine stays fixed so the file can be corrected once and the file can be dropped inside the folder where they are located. The only issue is that any new mobile attached to it will not have this correction and the file needs to be copy and pasted to the new device.He never showed me how to modify. I wish I knew in case I have any issue again.Sent from my SM-G935F using Tapatalk

author: Ultrapurple
author_rank: Super Contributor
timestamp: August 20, 2017, 01:33:12 am
content: You may be thinking of the 1.bin file:QuoteThe 1.bin file marks bad pixels so masks the issue rather than fixes it. Jinhua is right that it could be fixed in software, but it doesn't explain the curious origin of the problem.

author: Vipitis
author_rank: Frequent Contributor
timestamp: August 20, 2017, 01:59:04 am
content: Not a ThermAppBut in my CAT S60. The visual image of the MSX capture has those vertical lines.... Two of them - every time.I believe it is an artifact of slight warping by downscaling to 240x180 or some stupid res before they extract the contrast data.I can capture an image of something with a clearly straight, horizontal lines tomorrow and show upload it; but it's 4am right now so that has to wait.

author: Bruno28
author_rank: Regular Contributor
timestamp: August 20, 2017, 03:49:26 am
content: Quote from: Ultrapurple on August 20, 2017, 01:33:12 amYes the 1.bin is the bad pixel correction. And it substitutes the pixel that is bad with possibly and average of the ones around. It's shifting the pixels to correct the shift. If you see my pbotos it's just a pixel or two that has been shifter down.Sent from my SM-G935F using Tapatalk

author: Ultrapurple
author_rank: Super Contributor
timestamp: August 20, 2017, 05:18:48 am
content: Interesting. I have only seen one 0.bin file, and it was something like 150 bytes long, compared to the 432kB or 864kB of the other .bin files (ieexactlyfour or eight bytes per pixel).What size is your 0.bin file? Sounds like it might hold some key data.

author: Bruno28
author_rank: Regular Contributor
timestamp: August 20, 2017, 05:25:14 am
content: 152bytes for 0.binSent from my SM-G935F using Tapatalk

author: Ultrapurple
author_rank: Super Contributor
timestamp: August 20, 2017, 01:34:26 pm
content: Only one of my cameras has a 0.bin file. I opened it with a hex editor - unfortunately I couldn't find an easy way to export it as text so here's a screendump.

author: Fraser
author_rank: Super Contributor
timestamp: August 20, 2017, 01:48:05 pm
content: Maybe time to play with changing some numbers to check for effect ? Presumably, as this is just a file that can be cut and pasted, no harm should be possible.You could try removing the file completely to see what error code or effect occurs ? It is surprising if only one of your cameras has this file. Maybe it is the boy needed if a priblem with alignment is present ? Pretty weird if that is the case though.Fraser

author: Bruno28
author_rank: Regular Contributor
timestamp: August 20, 2017, 02:02:04 pm
content: Make sure you safe a copy of the original file before playing with it. So you can restore to previous/original.Sent from my SM-G935F using Tapatalk

author: Bruno28
author_rank: Regular Contributor
timestamp: August 29, 2017, 02:56:29 am
content: I just checked something about the bin file. I WAS WRONG!it is 1.bin and not 0.bin that has the line issue. So ignore my posts that say 0.bin and change to 1.bin.I don't know why I thought it was the 0.bin. silly me.I've corrected the posts I said the wrong things.

author: Fraser
author_rank: Super Contributor
timestamp: August 29, 2017, 01:52:44 pm
content: If, as has been previously stated, the 1.bin contains the dead pixel map, it is possible to mark a whole column as dead. You know this already though. The software will try to mask the failed column with interpolation of the pixels either side.Please note that in the thermal camera industry. A complete column fault in a microbolometer would usually render the sensor outside acceptable spec and it would be a reject. Full column replacement in software is not an ideal situation but possibly the only solution to this particular anomaly ?Fraser

author: bap2703
author_rank: Regular Contributor
timestamp: August 29, 2017, 05:36:14 pm
content: Can the faulty column already be dead ?What you are seeing would be "corrected" data and not actual measured values.Then if the correction algorithm calculates the correction from the line above, suddenly your corrected column looks like it is shifted by 1 pixel.Maybe somewhere you can play with how the replacement pixels are calculated (modify the kernel)Is the process of declaring good/bad pixel known for that software ? You could intentionally declare good/bad pixels to test that hypothesis.