Vertical and Horizontal Stripes in reconstructed image

[cytan299]

Hi Cedric, I am beta-testing WaveSharp (WS) with the author, Cor Berrevoets and he discovered something interesting in my raw image that was reconstructed by J'Solex. There are vertical and horizontal stripes when the background is disabled in WS:

This is from a single frame, so there are no stacking artifacts from AS4!.

The original single frame reconstructed file can be downloaded here:

https://1drv.ms/i/c/30d77764ca14119b/EdEJ4SKADg9NmyDq1FmM3L8BOdGFzEaxGeiRJ6MFYtCfHw?e=fsn2XE

I can provide the SER file, but it's 5 GB large and I don't have a free place to upload. If you can point me to a server to upload, I can do that.

Note 1: Ordinarily, I don't see these stripes. It is ONLY when the background is disabled in WaveSharp when these stripes become visible.

Note 2: I get this message in J'Solex which I have always ignored when doing reconstruction. Can this be the reason for the vertical stripes:

Found pixels with value 0, which may indicate a problem with the acquisition: the background should never be zero. Please check your acquisition settings. This may also be caused by a cropping window which is larger than the slit, in which case this is not necessarily a problem unless the geometry correction is not working properly.

I hope that you can shed light on why there's these stripes and what options in J'Solex that need to be enabled to get rid of them.

Thanks!

cytan

[CorBer]

This is some additional info showing the sum of the columns/rows after background removal from the image. Below is the code I used in python to construct this information

import cv2
import matplotlib.pyplot as plt

filename = "cytan_sun.png"

img=cv2.imread(filename,-1 ) #read the image
img1=cv2.GaussianBlur(img, (51,51),0.25) #blur using a largescale gaussian to create a background
img=img-img1 #remove the background

plt.figure(figsize=(20,10))
plt.subplot(2,1,1)
#plt.imshow(image,
plt.plot((img.sum(axis=0))) #calculate sum in the rows/cols
plt.subplot(2,1,2)
#plt.imshow(image,
plt.plot((img.sum(axis=1)))#calculate sum in the rows/cols

regards Cor

[melix]

I wonder if these actually don't come from the sensor itself. For instance I see some grid pattern on my 178MM, it's subtle but it's here... As for sharing a file, you may want to try with https://fromsmash.com

[cytan299]

Hi Cedric, Sorry for the delay. I had to queue for about 15 hours at smash before I could upload. Here's the link to the same ser file that I've used to generate the image above:

https://fromsmash.com/Sun-12-11-18ser-file

It's available for download until 08 Jul 2025.

Thanks for looking into this.

cytan

[vnp85]

To me it looks like a sensor issue. Please see https://github.com/melix/astro4j/issues/570

I can also confirm the grid pattern for the 178MM sensors, it is a royal PITA in full disk H alpha imaging. It doesn't show however in CaK. They say, the 178MM and 183MM are weird especially in the red half of the spectrum. I avoid both, that's why I got a 533MM and a 571MM for imaging the full disk Sun.

[melix]

I also strongly suspect the sensor, I'm seeing grid patterns in Ha too.

[CorBer]

Hi,

As the pattern is very regular (show by me above) it might be possible to compensate this. Ive tested the early horizontal/vertical pattern also for a dependency on luminosity. In my view the dependency is clearly there, so at a higher luminosity the gridpattern also becomes wider. If its really static that is something that can be compensated. And I am not imaging with this sensor, just interested as cytan has been one of my testers (using waveSharp) for some time.

cheers Cor

[cytan299]

Hi vnp85, Cedric, and Cor,

I wouldn't be surprised that it's the sensor grid pattern because of the regularity. Note that I'm using the Touptek 678M camera which has the IMX678 sensor and not the IMX178 sensor.

TBH, I would not have suspected that the pattern is there if not for Cor discovering it while testing out WaveSharp. It'll be interesting to see whether the 533 or the 571 sensors also has the pattern, but hidden unless the background is disabled in WS.

cytan

[CorBer]

The python-code on top makes it easy to test any image for this kind of pattern. And an alike routine can be also used to remove the pattern.

[CorBer]

This shows the horizontal gridpattern (in blue) the subtracted background (orange) and below the gridpattern/background which clearly shows a more stabilized pattern.

[CorBer]

Hi I have asked cytan for a few raw frames from the SER just to see if that noise is persistent and easy to remove. Turned out that the two frames (see included) have no grid-pattern.

This is the background subtracted image for one of these, nothing suspicous. Which makes me - and cytan - wonder how the pattern arrived into the full image.

This shows the same background removed view in waveSharp as the original post of this thread.

As I do not know how these curved spectrographs get combined into a full image I am sure Cedric might have an idea. From the time I was developing RegiStax I remember that I sometimes had cases where alignment "locked" onto a pattern instead of locking onto a feature. But this style of alignment/stacking is not something I have studied before. But it looks as if the original frames are not having this pattern.

cheers Cor

[vnp85]

For SHG, I also use the 678MM. In my ticket, I think it is readout related, as the noise dimineshes when insertnig an ND filter into the light path to allow an increased exposure time. Fromsay 0.8 ms to 3 ms (2-4 ms is a sweet spot of my setup at least)

[CorBer]

Hi vpn85, Do you have a comparable single SER frame (not a full image but a section) with/without that ND filter available ? I dont mind having a peek at the data.

cheers Cor

[vnp85]

I'll look into the archive.

[vnp85]

@CorBer I didn't forget, this is on my list.