Ringing artifact?

[Daniel Robert Griffiths]

We have had image artifacts develop in several miniscopes after prolonged imaging. A coworker describe it as a ringing or Gibbs artifact, but I have no idea if this is the correct terminology. It doesn't seem to be a problem with cables, commutators, or DAQs. We use green thread as a test target for imaging. I've attached an image from a 'good' miniscope on the left and a 'bad' miniscope on the right. The top image shows the full image and the bottom image is a higher magnification crop. Has anyone else experienced this? What causes it? How do we prevent it? Can we repair the miniscopes? Please let me know if you have any questions!

Thanks,

Dan

[Paul Vander]

Thanks for sharing - I recently discovered that my miniscope (V4, from open ephys ~1.5 years ago) started doing something very similar just a couple of weeks ago. Interestingly, I found that the artifacts showed up intermittently (see below: consecutive frames from a video of an out-of-focus benchtop). I don't have a second miniscope to test if the miniscope itself was the issue, but the DAQ and cable all are in good shape and the entire system worked well just before this issue started popping up.

--
You received this message because you are subscribed to the Google Groups "Miniscope" group.
To unsubscribe from this group and stop receiving emails from it, send an email to miniscope+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/miniscope/99e1346d-0dc4-4369-89bd-5bf4276eac70n%40googlegroups.com.

--

Paul Vander

Pronouns: he/him/his

PhD Candidate, AHA fellow

Correa lab | https://sites.lifesci.ucla.edu/ibp-correalab/

Molecular, Cellular & Integrative Physiology PhD Program

University of California, Los Angeles

[dsp]

What is the un-normalized intensity?  Only these look like digitization binning artifacts (posterization), the kind that show up if the total brightness is low relative to the pixel full well depth, which could show up if there was an illumination issue like a dim LED.  Are the raw pixel values similar?  Any notice of flickering LEDs?

best, dsp

To view this discussion visit https://groups.google.com/d/msgid/miniscope/CABQnEyh9720cSdxmUgLV_cukJ0CHNA5cSDABdTyBC15y2D-3xQ%40mail.gmail.com.

[Daniel Aharoni]

I wonder if this could be due to a specific bit of the 8 bit pixel values becoming physically disconnected on the PCB. This can cause what looks like rings or steps in imaging data. To check this, you can look at a bunch of pixels values from an uncompressed (or losslessly compressed) video, convert to binary, and then see if there is a specific bit position that is always 0 or 1 across all pixels.

To view this discussion visit https://groups.google.com/d/msgid/miniscope/CALWfTwH%2BJ4sRYSLHo%3D7eC3HcLxsRqZJn7QCPMew%2BNv6MKNYGiw%40mail.gmail.com.

--

Daniel B. Aharoni, PhD

Assistant Professor
Dept. of Neurology, UCLA

DBAh...@gmail.com
DAha...@mednet.ucla.edu

[Daniel Robert Griffiths]

Thanks for sharing! I have found that the problem starts intermittently and gradually gets worse over time, both in frequency and intensity.

[Paul Vander]

To answer dsp's question: the video screenshots I included were unaltered (raw video), and the mean pixel values for the example frames I sent are between 50-100 out of 255. And LED was set to 1, gain to 1 ("Low") and 15FPS. I'll attach the raw video for reference (see 0:08-0:09/0:16 mark for clear artifacts).

 0.avi

If it helps to demonstrate that the issue is highly transient - here are three consecutive frames in the video where the overall pixel values are very similar. The issue does seem to be lessened at brighter pixel values though.

 

Daniel could you give a bit more detail on what you mean by converting to binary? Do you mean converting the video file to binary color (0,1 pixel values) based on a threshold or extracting the raw video data as a binary file? I tried creating a binary file from the video using ffmpeg -i "1.avi" -f rawvideo -pix_fmt rgb24 "output.bin", but I can't make sense of the resulting file.

I tried re-attaching the UFL connector to the Miniscope and I wasn't able to re-create the issue when I tested the miniscope again today, so maybe my issue was just a slightly loose UFL-MIniscope connection. Fingers crossed it doesn't re-appear.

[dsp]

What he means is that the say value from 0-255 is encoded in a binary stream, so each bit has some value.  Each position of that 00000000 encodes some value of 2^n, n (0-7).  If one of those is always screwed up, you will end up with contours, because you can't infil some of that range.  Because it has lots of gradations, it could be a lower value bit.  This would make it so anything between some sets of values gets stuck because the bit doesn't flip up (or down) when going through a range of values it is supposed to help encode, giving this posterization.  You could maybe even decode the bit it may be from the difference in the intermittent blip.  Meaning plot a line profile and compare the jumps to try to guess the bit(s).

Hope this was (somewhat) clear.  Why the bit gets messed up, I don't know... but...

cheers, dsp

[dsp]

I should say, I figure most everyone knows binary encoding, but more trying to help figure out which bit is corrupted and where.  I use something like HxDen sometimes to see binary files, and then just look at the extracted frame, etc.  I haven't had this issue with miniscopes, but have had it with other board level cameras where a cable got janky...

[Paul Vander]

Thanks for the clarification, I think I understand. I used MATLAB VideoReader to convert .avi file to array, then grabbed all the unique values from that array and converted them to binary. It seems, at least when taking into account all of the frames, that there is no issue, and there are 0s and 1s in every position (see below).

I might try to isolate the frames that had the artifact visible. Is it possible that the bit could go in and out of a "stuck" state even between individual frames?

[Paul Vander]

So I wrote a short script in MATLAB that went through pixel values from each frame, and it looks like no bit is "stuck" at any point, and 0s and 1s are present in all 8. Will update if anything changes and thanks again for the advice!

[Federico Sangiuliano]

Just to add to Daniel's message, this kind of behavior appears when the pixel pins of the image sensor physically disconnect from the serializer. In the case of the v4, this happens when there is damage on the flex cable between the serializer and the image sensor board.

[Daniel Robert Griffiths]

Paul - Thanks for sharing! I have found that the problem starts intermittently and gradually gets worse over time, both in frequency and intensity. In the beginning it can be difficult to recreate. And thank you for sharing your code and results!

[Daniel Robert Griffiths]

DSP – I think it's very interesting that you mentioned the LED intensity because some of the miniscopes have posterization and LED issues... I thought they these were separate issues but maybe not? Some of the scopes with the posterization have LEDs that will turn on but are not adjustable and others have LEDs that will not turn on. Do you think these issues are related? The posterization is visible even when the LED is off or doesn't work. And thank you for explaining the bit position… it’s something I know almost nothing about but need to learn!

[Daniel Robert Griffiths]

Daniel – Thank you for replying!

Federico – Thank you… that is very helpful! Just to make sure I understand, that is the flexible ribbon between the CMOS PCB on top of the miniscope and the PCB on the side of the miniscope with the UFL connector? Is this normal expected wear? Can the scopes be repaired? Any tips or suggestions to prevent this type of damage?

[Daniel Robert Griffiths]

Here is a link to a video of our last failed imaging. 

https://youtube.com/shorts/USLy2JyGrJw?feature=share

Brief description of the imaging in the video caption. Please let me know if you have any questions! Thanks again for all of your help!

[Federico Sangiuliano]

The fix is to unfortunately replace the PCB as the damage might be in between layers.

[Fa Peng]

Hello, everyone. I would like to add a few questions.

We also saw the halo phenomenon (steps in the image); we used the microscope on rats (cable pulling, microscope heat dissipation was probably the cause for halo phenomenon; replacing the circuit board was the quickest solution).

Out of curiosity about the problem, we converted the image data to binary data, and we did not see the phenomenon ‘a specific bit position that is always 0 or 1 across all pixels’. We used an oscilloscope and saw fluctuations in the 5V level pin (with a normal microscope, there was no level fluctuation in the 5V level pin). After replacing L4 L5 C29 C30, the halo phenomenon did not change.

Have you tried replacing the serializer chip or power_Chip(U8、U10) of the microscope? We can't replace it manually here; if we return PCB to the factory for repair, we are not sure that it will be repaired; replacing the serializer may solve the problem.

There is also a strange phenomenon. When we first saw the halo phenomenon, we pressed our finger at the IPEX terminal and the halo phenomenon disappeared. We baked the circuit board and replaced the IPEX terminals (IPEX on the PCB, IPEX connects coaxial cable), the halo phenomenon has always existed (there is no longer the phenomenon of 'press our finger at the IPEX terminal and the halo phenomenon disappeared ').

As shown in the figure below, ‘halo phenomenon’_on the left side; ‘level fluctuation in the 5V level pin’ _on the right side.

Fa Peng.