bias, are them "inside" the darks/flats?

Hello,

in the last days I have been experimenting a lot with siril and so I am reading all the scripts that comes with it.
I have a few doubts:

Are bias frame needed when preprocessing the light with darks/flats?

if you have a look at the script “DSLR_preprocessing_Cosmetic.ssf” that cames with siril we can see that the bias are integrated inside the flats and then they are not used to make the lights, because they are already inside the flats

preprocess flat_ -bias=../biases/bias_stacked
preprocess light_ -dark=../darks/dark_stacked -flat=../flats/pp_flat_stacked -cfa -equalize_cfa

but, in “DSLR_Preprocessing_NoDark.ssf” they are both into flats and lights

preprocess flat_ -bias=../biases/bias_stacked
preprocess light_ -bias=../biases/bias_stacked -flat=../flats/pp_flat_stacked -equalize_cfa -debayer -stretch

again, in “DSLR_Preprocessing_NoFlat.ssf” they are not used at all:

preprocess light_ -dark=../darks/dark_stacked -cfa -debayer -stretch

From free-astro i found another two interesting script like “DSLR_preprocessing_opt.ssf” here the bias are used both in the preprocess of flat, dark and lights

preprocess flat_ -bias=../biases/bias_stacked
preprocess dark_ -bias=../biases/bias_stacked
preprocess light_ -dark=../darks/pp_dark_stacked -flat=../flats/pp_flat_stacked -bias=../biases/bias_stacked -opt -cfa -equalize_cfa -debayer

I am really confused, where I should use the bias?
Maybe my doubts are silly for experienced users but I am learning and I would like to make the best results possible

btw in “DSLR_preprocessing_opt.ssf” and “DSLR_startrail.ssf” I found a strange piece of code:

#stack calibrated lights
stack pp_light_ max

#That's a workaround here to save result in another place.
#These lines are not mandatory
#load image in memory
load pp_light_stacked

#and save it at root
cd  ..
save result
close

maybe this workaround is not anymore needed because there is the -opt= options?

Wrong. Because they are already inside the darks.

Of course, there are no darks.

Workaround in other scripts is just an old stuff to save result outside of the tree.

I don’t think analyzing the scripts are the best way to start astrophotography. You should first take a look to the documentation and/or YouTube video, and maybe grab a book to understand the preprocessing maths :). The one of Thierry Legault is stunning.

Then try to process your images manually. This is for me the best method to learn.

Cheers.

1 Like

I put it on my wish list :slight_smile:

About the calibration frames there is something that it not completely clear to me, and I am struggling to understand:

  1. yes dark, yes flat → bias inside flat (it is already in the darks)
  2. no dark, yes flat → bias inside flat and light
  3. yes dark, no flat → no need to put bias inside nothing (since it is already in the darks)
  4. no dark, no flat → bias inside light

I think that the 4 statements above are right

I can’t understand this script: File:DSLR preprocessing opt.ssf - FreeAstro
It preprocesses the bias inside dark, flat and light

The only problem I’ve with consider that bias are inside flats and darks is that if you latter scale darks (to adjust exposure time), then you are also scaling the embedded bias, so the results could differ because at this point the scaled bias doesn’t match with the no scaled one on lights and flats.

I prefer to remove bias from all the other calibration frames (and lights, of course). this way when you apply any additional transformation there are not cross-talk between operations.

Scaling dark is dark optimization. In this case of course bias is removed.
If no dark optimization this is not needed, just a waste of time.

1 Like

You are right, actually it was explained on the old website: Siril:Tutorial preprocessing - FreeAstro

At the beginning I searched only in the new site and I wasn’t able to find this information: Siril btw the documentation is wrote half in english and half in french, and seems that some arguments haven’t been brought there

@argonothe if you can clarify this in the documentation, that’d be greate, the same kind of thing you put in one of the latest videos. Thanks :slight_smile:

I think it is better to use this topic instead of opening a new one:

I wasn’t able to find in the docs (both new and old) an explanation for the “flip” argument of the “preprocess” command, could you add it with an example where it could be useful? (maybe in pic with a bright foreground? for example: https://media.macphun.com/img/uploads/customer/blog/1303/15505757645c6be8945a6975.41048694.jpg)

Is it possible to use in a script the “autoSketch” as shown in the videos? (https://youtu.be/6sOZJkiTCmo?t=83)?

Also, in the scripts, an option to change the output prefix of the preprocessing would be very useful, as it is possible in the GUI

Sorry but flip i explained.
Capture d’écran du 2020-04-16 13-47-01

flip is useful when the acquisition software stores FITS images top-down instead of bottom-up.

autostretch is a rendering mode, it does not modify the images, so in a script, with no image display, it makes no sense. You may be looking for an automatic histogram enhancement, which is not available in scripts, but ddp and asinh will do something that approaches.

indeed we could add the option to change the ‘pp_’ prefix…

Sorry but flip i explained.

my bad, I saw it, but since it says “for demosaicing operation” I thought that it wasn’t only flipping the image but also applying some different algorithm :sweat_smile:

Yep, something automatic would be wonderful!
Just checked them, ddp is not scriptable while asinh is, I will experiment with them!
usually my post processing workflow in siril is made by:

log
rmgreen 1 

and then I play with the rl deconvolution

indeed we could add the option to change the ‘pp_’ prefix…

:+1:

Just for my own curiosity: I guess that siril won’t ever support some timelapse utility like export a whole sequence of tif to jpg to make a video, right?

in the sequence tab, the bottom of the panel is related to sequence export. From here, you can export a sequence to other image types and to an mp4 film. It’s not a feature widely used so it may not work very well, especially in the development version.

To prepare frames for an animation it will be nice if you can apply the same histogram transform to a whole sequence. I know, histogram transformation is not scriptable by now. This is only forward thinking :slight_smile:

apply the same histogram transform to a whole sequence

Absolutely agree! Furthermore, I think it would be also useful to export a sequence to jpg/png

May I ask which kind of magic you and @lock042 made with the autostretch feature? I have been tried for two days to achieve something like it with both siril and darktable and I wasn’t able to reach the same nice image :joy:

Find a way to modify the image with the autostretch-magic would be a killer feature imho
But if it is too complex to do it also the asinh 100 is very near anyway :smile:

The autostretch is a midtone transfer function. Just click on the gear button in histogram transfer function.
But doing it manually is far better as usual.
Why trying to do it in darktable at this stage. Siril is done for this task. I really think you need to watch some tutorials and not only the commands as everything is not in the command line.

Yes Rafa, it’s been asked a lot for sequence export… It’s not very simple to do in terms of user interface and currently not planned for next version…

Well I was thinking about a command to be used on scripts like in

seqhisto r_pp_ 0.00 0.12312 0.999

This completely fictional command will apply the histogram transform defined by the 3 float numbers to each image in the r_pp_ sequence and generate, for example, stretched_r_pp_ sequence.

Latter I can use the current option to generate the MP4 file with the frames stretched.

Saludos,
Rafa Barberá

implemented in last commit: https://gitlab.com/free-astro/siril/-/commit/2d3ddd917258fc1cb75b66e027e265c65d40918e

3 Likes

Wow!!! That was very fast!!! Thank you very much!