After being told by QHY that the grid artifacts that plague users of the QHY5III178mono could not be fixed, I decided to take a stab at it myself. To be fair, this is a problem of Sony's IMX178 sensor, and cameras from other brands have the same problem. The issue is that the camera appears to have a Bayer mask, despite being mono. The pixels that correspond to "red" on a color camera are overbiased and will appear brighter than surrounding pixels. For reasons unknown, this seems to affect monochromatic sources with longer wavelengths more than other subjects, thus H.alpha users are particularly screwed when it comes to this camera.
While undertaking a project to write an autoguider utility for linux for use with solar, lunar, and planetary imaging, I found myself needing to rip apart the .ser video files to grab individual frames to guide upon. For whatever reason, the images acquired this way were particularly bad with regard to the IMX178 bug, so I decided to take a crack at correcting the image. It took all of 3 minutes.
Here is an example image before correction. This was a shot, albeit upside-down, of my kitchen (the sink, and the faucet specifically), and you can clearly see the grid artifacts if you zoom in:
By doing a simple modulo to identify pixels that are in both even numbered rows and odd numered columns, a correction factor can be applied.
Here is the result:
The correction isn't perfect as it is slightly non-linear, but that can be fixed with a little extra effort. That's the good news.
The bad news... depending on the bias, these "red" pixels will lose a fair amount of the high end data. For example, in the image shown here, the defective pixels were 1.74 times more luminous than they should have been. This means that for a value exceeding around 150, the defective pixels record 255 in 8bit mode, and everything over 150 is clamped to 255.
The not-so-bad news is that in most .ser files, the bias is much lower than this 1.74 value. Additionally, since these "red" pixels are particularly hot, most people will end up reducing exposure to avoid blowing out the image. This has the side-effect of preventing the clamping mentioned before, but it simultaneously makes the other 75% of the pixels darker than they need to be, resulting in a loss of dynamic range. Regardless of how it's done in post processing, the camera will not be true 8bit unless the underlying issue is solved.
Anyway, once I get some testing knocked out, I will release the utility. I expect that it will be sometime in the next week or two, but it will likely remain a linux-only utility just like the autoguider unless someone wants to port it to Windows. I'm going to finish up the autoguider first since that is more critical for me at the moment.
Regarding the autoguider, it works by pointing the utility at a .ser file that is in the process of being written. This will work with the imaging utility I currently use, but I don't know if other utilities (Ekos, FireCapture, etc) write the .ser file incrementally or not. I would assume so, given the size. It calculates the center of contour of the subject in the most recent frame, and then spits out an X,Y coordinate for the center. It then works to keep the mount aimed such that the X,Y coordinate remains stationary with some filtering to smooth out atmospheric seeing effects and scope vibration.