OK, now I understand. Probably what’s happening is that the camera is correcting all files using a multiplicative factor, without taking into account the non-zero floor (it’s not using dark and bias frames as it should! ).
However, the math isn’t basically (Signal - Bias - Dark)? If it were only a multiplicative correction, it shouldn’t affect the end result. But maybe there is, as you say, a more complicated (non linear) algorithm involved.
On the other hand, if it is applying the correction also to the light frames, the question arises about how do you correct those. The effective noise floor will also be affected there by the camera correction, and it should show in a night mostly-black image.
Hello. I don’t have xtrans sensor but users told me that this square is only visible when you enable cosmetic correction. Disable it, you won’t see anything.
I will have to do some more experiments, but I have my doubts about that being correct. Cosmetic correction isn’t even implemented yet for X-trans.
The log even says this…
Cannot apply cosmetic correction on XTRANS sensor yet
I can try stacking with it enabled/disabled, but that is applied when pre-processing the light frames. The master dark will already show the box at that point.
@guille2306, A night sky is never black… if it is, the exposure was taken incorrectly. This is why we try to expose with the peak of the histogram not being all the way over to the left on the chart. The peak largely represents the sky background… and still has much higher values than a dark or bias frame.
I had the same thought about correcting the light frames though. The noise for those pixels is amplified along with the signal… so the dark and bias frames are not perfectly compensating. I guess the answer to that is to dither aggressively.
I am using the dev branch from a couple days ago. I did some tests using a short stack of M13. I used the DSLR_preprocessing.ssf script. I also ran it once with the -cfa and -equalize_cfa flags removed. In both cases, the resulting image showed a square.
Here’s a screen grab using a negative view and the histogram display mode on the green channel. I have applied a background extraction to remove a gradient. This makes it slightly easier to see, but the square was certainly visible before doing that. The images in this stack were dithered when acquired, so the edges of the square are a bit soft. I hope it shows up in this post.
I then used the same data and steps again. The only difference was I used my code to correct the master bias and master dark before those were applied to the flats and the lights. The result is as follows. Notice the square is gone.
If there’s something else I should try, please let me know. I did experiment with processing without darks and just using flats and bias frames, but the amp glow was then visible on the edges of the final image. The darks are needed to remove that.
This square can be very difficult to see depending on the subject matter and how well the processing takes care of the rest of the noise. Images like this with consistent backgrounds show it best. Dithering (during acquisition) actually makes it easier to see as it smooths out some of the other noise. I learned that with some of my tests.
Thanks for looking at all of this. I really do like Siril.
@setnes : please could you send me some files ? For example your dark frames, bias frames and flat frames and 2 or 3 lights?
I think I have an idea on how to implement it in the Siril workflow.
In any case, if raw values are being modified depending on their location, it might be something to consider in software like RawTherapee as well.
I would be interested in a series of shots taken with the lens cap on and with different shutter speeds (from relatively short like 1/10 s to relatively long like 5 s, or extremely long in the case of astrophotography). Could somebody make these and share them?
@setnes : I’ve coded something. So waiting for your frames.
If someone else has another camera model with same issue, please either send me a dark frame. I need to build a library of camera.
@Thanatomanic@lock042
Presently, I have access to an X-T1, an X-T3, and an X-Pro2.
I do not know if they are affected as well – but in case you
need some shots from any of them, just tell me (with clear
instructions, please).
The actual locations of the auto focus pixels can be really hard to find. I created this 8-bit tiff that shows their locations well. There’s also noise in this image, but the auto focus pixel pattern is easily visible.
I created this by taking several dark frames and first doing a minimum stack in Siril. Then I did some severe stretching and clipping until the pixel pattern popped into view. I clipped the dark pixels by about 90% or more until most of the low background noise was gone. I also pulled the middle triangle really close to the left triangle in the Histogram Transformation tool. It helps to use the zoom feature in the tool. It gives more granularity to the controls. Anyway, this might be helpful for anybody trying to find the auto focus pixels on their sensor.
It should be possible to get an even better map by doing this on only the green channel, but this worked well enough for me to find the locations.
Also, in some threads on dpreview where it was discussed how suitable are the Fuji cameras for astrophotography, the analyze showed that there is some sort of rawfiltering that the cameras make for exposures longer than 6 seconds. I can link it here if you find it helpful.
).
