During a long imaging session, I took 600 images. The last 200 were shot after a meridian flip, that means Siril have to rotate 180° these images to align them with the other one.
When I check them, each one of these rotated images appears to have some kind of deformed grid-like pattern noise that does not exist before. The pattern is not the same size from frame to frame.
Does somedy knows if it’s normal, or if there is any way to avoid that? Since the pattern size is never the same, it does not show up in the final stack, but I guess the final image would be better without it…
Hi, this is probably related to pixel interpolation during the rotation of images. Since the global registration transforms the images to make their stars match the stars of the reference image, they are often rotated, especially in your case, and even scaled or sheared. The rotation is rarely exactly 90, 180 or 270 degrees, so some interpolation is needed.
There are several options for interpolation in siril, but I guess this may occur with most.
I’ll try to manually rotate them of 180° in the first place to see if that change anything. Because small rotation are less problematic if I consider the first half of the pictures.
I am curious to see how other softwares handle this problem.
Indeed since other images don’t have the problem that could be a solution, but if not automated for 200 images it won’t be fun… Maybe we could do this in siril. But as you said it’s not visible in the final image.
Also, is it visible when the image is viewed at 100% zoom? Because this kind of Moiré is often only visible when zooming out.
Siril uses OpenCV for these operations, the exposed interpolation options the its.
I think Siril could easily detect when a meridian flip occured (ie rotation greter than 180) and first do this rotation before interpolating the remaining transformation. Would be a nice feature.
I am not sure how this problem could damage faint nebulae structure. Tests should be done, but for now my poluted urban sky won’t allow me to investigate.
It’s not visible à 100% zoom but the image are 6252 x 4176 on my 2K display. When working fullscreen with Siril, (about 25% zoom on my display), it’s quite visible (that’s how I noticed it, when reviewing quickly image before stacking).
EDIT : just noticed you were one of the developer. If you want I can send to you some of the FITS file.
I’m not sure that would improve something by the way.
It will. Because I did the test manually rotating file after calibration and before alignment, and no pattern was visible.
However, when you say that. It looks like a moiré of the display.
I don’t think so because the pattern size scale with the level of zoom.
Please send two calibrated files. One before alignement, the other after.
Here it is. Before. After.
I use Auto-Adjustement to see the pattern.
I’am kind of new with astro-photography, so I may be missing something with my post-processing or shots.
More globally, I have noticed that after registration, images looks a lot less good than before. Even for the image taken before meridian flip, after registration it like some dew/faint altitude clouds were appeared. It’s very visible when going from file to file in a sequence. Unfortunatly I don’t have any other sofware to make a comparison to be sure it’s the software and not me messing with something I don’t understand.
had a look at your files, it is indeed moire interpolation pattern. This can happen when there is little signal in the background, which may be the case with short exposures (5s from what I see in your fits header).
Could you pls also share another calibrated light before the meridian flip? We’ll try to see if changing the interpolation algorithm and the transformation model can make a difference. Also see how making a first 180 rotation beforehand can change the outcome. Don’t see an obvious reason from the maths but maybe smthg we’re missing.
Thanks!
C.
But why would it happen only when more than 180° rotation is needed? And this pattern is always grid-like but its size widely change from file to file.
Could you pls also share another calibrated light before the meridian flip?
You’ll find image before meridian flip here. Before/After registration.
This can happen when there is little signal in the background, which may be the case with short exposures (5s from what I see in your fits header).
Indeed the exposure time is short, but : sensor is quite sensitive (QHY268M) and I am shooting from suburban area so light polution is a pain (that’s why I have so many subs). So it does not make sense to take longer subs, right?
Okay, just throwing my best guess here, then I’ll check your data I would say that it is not so much linked to the 180-something rotation but more to the fact that you may have a slight cone error. What it means is that before meridian flip, all your subs just mainly undergo a shift one wrt. the other, while after the flip, there is also a slight rotation added, say in the order of 0.1-0.2 deg. This additional rotation may trigger why the pattern occurs (more visibly) after the flip.
To understand why this happens anyway, I’ll refer to this post : https://www.cloudynights.com/topic/623185-woven-fabric-pattern-on-stacked-image/?p=8670975
which is the best explanation I’ve ever found.
Now why the pattern changes in size between the images would be linked to both the amount of rotation and the other degrees of freedom being used. From the shape of the grid I saw in your aligned frame (the fact that it’s curved), I would say it arises from the homography transform being applied. Hence why I want to try changing the number of degrees of freedom of the transformation with the data you’ve just sent.
I think you could lengthen a bit your subs for mainly two reasons:
there’s hardly any saturated stars (I can spot 2 which have one or two pixels which have clipped at 1.) in your sub
if I measure the amount of noise in your background (either with command bgnoise or by drawing a selection on a portion of black sky, then right click, Statistics and look at the std value), it reports 13.1 ADU. Now, from your camera spec (https://www.qhyccd.com/qhyccd-qhy268ph-imx571-cmos/ , section Read Out Mode and Curves), I can guess (correct me if I’m just plain wrong) you are using Mode 1, because your gain setting is at 56. At this gain, with this mode and your 16b-ADC camera, the read-out noise is 1.6e- and the electronic gain is 0.16e-/ADU. So that the read-out noise in ADU should be in the order of 1.6/0.16=10ADU (you could also make a real measure by computing the std of a bias frame). Now, this value is very close to what we measure in your calibrated frame (13.1), which means that the background is dominated by the read-out noise of the camera.
As a practical rule of thumb, you could use as a target for your background noise 3 times the read-out noise so 30 ADU. You can find many topics over astrophotography forums as to why this is a good enough target. So I would say you can safely increase the length of your subs. Of course, it will depends on the targets, and should be a compromise between avoiding overexposing bright parts of your images and getting good signal on the background.
I’ll try to have a look at your before/after subs and tell if I can find a better transform/interpolation method to avoid this pattern.
EDIT: Just tried downloading the Before/AFter frame, but I see it’s an already aligned sub. Could you share the same calibrated-only frame (so pp_light_L_00500.fits)? I would like to work from frames which have undergone no geometric transform at all. Thx!
Thanks for the explanation. Topic on Cloudy Night is for sure interresting!
EDIT: Just tried downloading the Before/AFter frame, but I see it’s an already aligned sub. Could you share the same calibrated-only frame (so pp_light_L_00500.fits)? I would like to work from frames which have undergone no geometric transform at all. Thx!
I thinks you missed the fact that there is two distinct links : the Before is pp_light_L_00500.fits
Indeed
So I took your 2 calibrated subs and stored them in a folder to which I cd-ed. Then typed the following lines in the command line in siril: load pp_light_L_00500 crop 50 50 6202 4126 save pp_light_L_00501 load pp_light_L_00783 rotatepi save pp_light_L_00782
I now have a sequence of 4 files.
#500 is the original file before flip
#501 is #500 “shifted” by 50 pixels in X and Y (also smaller but siril can deal with that during registration)
#782 is like #783 with a 180deg rotation so that is roughly aligned with #500
#783 is the original post-flip image
If I run a registration with the default parameters (transformation=homography, interpolation=pixel area relation), I see the following:
r_501 has no grid pattern
r_782 and r_783 have exactly the same pattern, with some curviness in the pattern.
So 1. is probably why you see no pattern before meridian flip. And 2. tells that making a 180 rotation beforehand should not change the outcome. But interested to see how you came to a different conclusion regarding 2.
I can also see from the log that the rotation before/after flip is 0.315deg mod pi
Note: to reveal the grid, you can switch preview to Histogram and to rainbow colormap
If I redo the same forcing the transformation to be a similitude, same but now the grid pattern is rectilinear, so that is is the homography (or more accurately the slight warping it implies) which triggers the curviness.
The only setting that gets rid of the pattern is using Nearest Neighbor algoritm for interpolation (because there is no real interpolation involved). I don’t know what it will produce on the stack, but thanks to your very large number of frames, it could still hand out good results.
I had read the thread on optimal exposure time a while ago. And no doubt the theory is right, provided no other parameter comes at play. In your case, I still believe there is not enough signal in the background to avoid interpolation artifacts, at least with the set of alorithms we use. I’ll have another read when I have a bit more time, always interesting.
But interested to see how you came to a different conclusion regarding 2.
I obviously made a mistake during my initial test, because when doing it again this morning, I was not able to reproduce my initial result. I’ll do some other tests with other software to see if there is any difference (need to find someone using Pixinsight).
I still believe there is not enough signal in the background to avoid interpolation artifacts, at least with the set of alorithms we use.
I will give a try to your proposed exposure time the next clear night (that should not happen before a while).
Regarding theorical optimal exposure time, I also could have made a mistake when estimating the light polution where I shoot. I used a light polution map, but it’s obvious that if I am shooting west (toward a big city - Bordeaux - near) the light polution will be more important than when shooting north or east (toward the country side). I’ll try to make some adjustment.
Like I said, I still have a lot to learn and your comments were very welcomed.
Sorry if there is no direct link to the previous comments, but is there any way to suggest new options/features? I didn’t find anything regarding this matter on Siril website.
I would say that it is not so much linked to the 180-something rotation but more to the fact that you may have a slight cone error. What it means is that before meridian flip, all your subs just mainly undergo a shift one wrt. the other, while after the flip, there is also a slight rotation added, say in the order of 0.1-0.2 deg. This additional rotation may trigger why the pattern occurs (more visibly) after the flip.
