PiThermalCam icon indicating copy to clipboard operation
PiThermalCam copied to clipboard

Image not displaying correctly

Open timbot18 opened this issue 1 year ago • 3 comments

in a fresh rpi 4 raspbian os 11 install, the image will not display correctly. it is only showing 1 colored square, and the rest are reading near 0. you can faintly see the image thats supposed to be there. when using plt.imshow in the adafruit example, it shows the image correctly, so the sensor is working.

adafruit sample: 20221213_161203

matplotlib from sequential folder 20221213_161226

opencv from sequential folder 20221213_161241

timbot18 avatar Dec 13 '22 22:12 timbot18

after digging into it, i found that one of the pixels was being reported as -273.15, skewing the entire range of the image, resulting in the pics above. after adding a for loop to find pixels beyond the camera's range in the opencv_therm_cam.py file, it started working correctly. there is probably a better way to find them, but this got mine working. i added it into the section of code for the mode i was using, right after it read the data from the camera. it just checks for a number outside the working temps of the camera, and if found, makes an average of prior and following numbers and replaces it.

        for i in range(len(image)):
            if image[i] < -40:
                image[i] = (image[i-1] + image [i+1])/2
            if image[i] > 300:
                image[i] = (image[i-1] + image [i+1])/2

the reason the adafruit example worked is because they have the range defined in their code. something like this probably needs to be added to avoid bad pixels.

timbot18 avatar Dec 14 '22 22:12 timbot18

That's useful to know. Is the camera itself just producing bad data for that pixel in your case? I.e. that sensor element is broken? It sounds like it's intermittent if prior and following numbers are reasonable; have you had issues with it reporting bad data over longer periods? If so, at what point do you interpolate from the surrounding pixels instead of prior and subsequent values?

Am Mi., Dez. 14, 2022 at 17:47 schrieb @.***>:

after digging into it, i found that one of the pixels was being reported as -273.15, skewing the entire range of the image, resulting in the pics above. after adding a for loop to find pixels beyond the camera's range in the opencv_therm_cam.py file, it started working correctly. there is probably a better way to find them, but this got mine working. i added it into the section of code for the mode i was using, right after it read the data from the camera. it just checks for a number outside the working temps of the camera, and if found, makes an average of prior and following numbers and replaces it. for i in range(len(image)): if image[i] < -40: image[i] = (image[i-1] + image [i+1])/2 if image[i] > 300: image[i] = (image[i-1] + image [i+1])/2

the reason the adafruit example worked is because they have the range defined in their code. something like this probably needs to be added to avoid bad pixels.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

tomshaffner avatar Dec 15 '22 12:12 tomshaffner

it does appear to be consistent. seems to be the same place every time, and the exact same number, so i think it is a bad cell. i haven't had it in use long enough to see if any pop up anywhere else, but do not appear to at this time. to fix it, i inserted the for loop right after the image data is read from the camera in the camera_read function (since that was the one i was using, but a function would prob be better for use in all other display functions):

def camera_read(use_f:bool = True, filter_image:bool = False):
...
try:
        while True:
            # Get image
            try:
                mlx.getFrame(image)  # read mlx90640
            except RuntimeError as e:
                if e.message == 'Too many retries':
                    print("Too many retries error caught, potential I2C baudrate issue: continuing...")
                    logger.info(traceback.format_exc())
                    continue
                raise
            
            for i in range(len(image)):
                if image[i] < -40:
                    image[i] = (image[i-1] + image [i+1])/2
                if image[i] > 300:
                    image[i] = (image[i-1] + image [i+1])/2

            temp_min = np.min(image)
            temp_max = np.max(image)
            img=temps_to_rescaled_uints(image,temp_min,temp_max)

this lets it pass the corrected values to the temps_to_rescaled_units function, as it appeared thats where the image was going "bad" at since the temps were so far apart. i figured it out by printing the values for image and temp_min and temp_max at each step in the code. after inserting the for loop, the temp_min was corrected, as it wasnt even picking up the corrected averaged value as the minimum, it was picking up the actual minimum from elsewhere in the image. thank you for your work on this. it saved me a lot of time!

timbot18 avatar Dec 15 '22 16:12 timbot18