Any way to have border set to pure black when using "-framing=max"

Software Siril
1

I’m stacking some panels for a mosiac and using the “-framing=max” option. I have some field rotation so there is a bit of a border around my stacked output. These are areas where no pixels from any lights fall but represent blank areas in the expanded rectangle needed to hold the entire stacked image.

The problem is that SIRIL doesn’t set this area to black, it sets it to a dark gray (0.0392 is the value I see). So when I stack these panels as a Mosiac (I do use APP for this), they get treated as sky values and not as blank data to be ignored.

Is there a way to have SIRIL usea value of zero for any blank border area that it creates when doing “-framing=max”. Perhaps it’s a configuration for the registration function as the rotated/expanded frames are created during registration.

Other programs like APP set that area to pure black (value 0.000) which helps when doing panoramas.

2

Hi, I think it’s supposed to be black… I have seen a similar issue on another type of processing but with non-uniform values, that’s interesting to see you have this issue too, unfortunately for you

3

Siril definitely set this value to black.
If you don’t see it black there’s an issue somewhere. Not sure it is related to the previous bug however.

4

I’ve checked a few other older results and they all had non-zero backgrounds. Two were 0.0007 (0.07%), one was 0.0231 (2.31%). I integrated with Lights, Biases, and Flats with no darks as I shoot with very short exposures with a cooled camera. No other anomalies with the results other than the background being dark, but not black.

5

Hi Steven,

would you mind sharing one of the images with the gray borders and a log that contains the registration?

Cheers,

C.

6

I’m not sure what information you want but I exported the console to a log file but it won’t allow me to upload a .txt file, and the full raw 32-bit float image is too large, but here is a tiny section with both the image and background saved as 32-bit compressed .TIF (not stretched).

resultCrop.tif (5.0 MB)

As for the log, perhaps you can tell me how to upload it.

Here is the start of the registration:

20:07:16: Trial #1: After sequence analysis, we are choosing image 11 as new reference for registration
20:07:16: Recomputing already existing registration for this layer
20:07:16: Matching stars in image 4: done
20:07:16: Initial pair matches: 602
20:07:16: Pair matches after fitting: 602
20:07:16: Inliers: 1.000
20:07:16: scaleX: 1.000
20:07:16: scaleY: 1.000
20:07:16: scale: 1.000
20:07:16: rotation: +0.197 deg
20:07:16: dx: -7.43 px
20:07:16: dy: -11.91 px
20:07:16: FWHM: 3.31 px
20:07:16: roundness: 0.78
20:07:16: Matching stars in image 36: done
20:07:16: Initial pair matches: 507
20:07:16: Pair matches after fitting: 507
20:07:16: Inliers: 1.000
20:07:16: scaleX: 0.998
20:07:16: scaleY: 0.999
20:07:16: scale: 0.998
20:07:16: rotation: -23.160 deg
20:07:16: dx: -1094.60 px
20:07:16: dy: +784.53 px
20:07:16: FWHM: 3.26 px
20:07:16: roundness: 0.78
20:07:16: Matching stars in image 1: done
20:07:16: Initial pair matches: 549
20:07:16: Pair matches after fitting: 535
20:07:16: Inliers: 0.974
20:07:16: scaleX: 1.003
20:07:16: scaleY: 1.001
20:07:16: scale: 1.002
20:07:16: rotation: +4.380 deg
20:07:16: dx: +355.73 px
20:07:16: dy: -312.07 px
20:07:16: FWHM: 3.31 px
20:07:16: roundness: 0.79

and here is the end:

20:07:17: roundness: 0.77
20:07:17: Matching stars in image 15: done
20:07:17: Initial pair matches: 502
20:07:17: Pair matches after fitting: 502
20:07:17: Inliers: 1.000
20:07:17: scaleX: 1.003
20:07:17: scaleY: 1.000
20:07:17: scale: 1.002
20:07:17: rotation: +4.675 deg
20:07:17: dx: +355.17 px
20:07:17: dy: -334.45 px
20:07:17: FWHM: 3.48 px
20:07:17: roundness: 0.74
20:07:17: After sequence alignment, we find that image 11 is 89.1px away from sequence cog, i.e. within allowable bounds
20:07:17: Total: 0 failed, 37 registered.
20:07:17: Execution time: 9.11 s
20:07:17: # Now doing: seqapplyreg pp_light -framing=max
20:07:17: Running command: seqapplyreg
20:07:17: Interpolation clamping active
20:07:17: Processing all images in the sequence (37)
20:07:17: Apply registration: with the current memory and thread limits, up to 16 thread(s) can be used
20:07:17: Applying existing registration from layer #1 to transform the images
20:07:17: Apply registration: processing…
20:07:18: Reading FITS: file pp_light_00024.fit, 3 layer(s), 5072x4024 pixels, 32 bits
20:07:18: Reading FITS: file pp_light_00009.fit, 3 layer(s), 5072x4024 pixels, 32 bits
20:07:18: Reading FITS: file pp_light_00019.fit, 3 layer(s), 5072x4024 pixels, 32 bits
20:07:18: Reading FITS: file pp_light_00004.fit, 3 layer(s), 5072x4024 pixels, 32 bits
20:07:18: Reading FITS: file pp_light_00011.fit, 3 layer(s), 5072x4024 pixels, 32 bits

and the end of ApplyRegistration:

20:07:42: Saving FITS: file r_pp_light_00018.fit, 3 layer(s), 6553x5817 pixels, 32 bits
20:07:42: Saving FITS: file r_pp_light_00016.fit, 3 layer(s), 6553x5817 pixels, 32 bits
20:07:43: Saving FITS: file r_pp_light_00036.fit, 3 layer(s), 6553x5817 pixels, 32 bits
20:07:43: Saving FITS: file r_pp_light_00037.fit, 3 layer(s), 6553x5817 pixels, 32 bits
20:07:44: Saving FITS: file r_pp_light_00003.fit, 3 layer(s), 6553x5817 pixels, 32 bits
20:07:45: Saving FITS: file r_pp_light_00006.fit, 3 layer(s), 6553x5817 pixels, 32 bits
20:07:45: Sequence processing succeeded.
20:07:45: Execution time: 28.14 s
20:07:45: Applying registration completed.
20:07:45: 37 images processed.
20:07:45: Total: 0 failed, 37 exported.
20:07:45: # Stack calibrated lights to result.fit
20:07:45: Running command: stack
20:07:45: Stacking sequence r_pp_light_
20:07:45: Processing all images in the sequence (37)
20:07:45: Stacking result will be stored as a 32-bit image
20:07:45: Computing normalization…
20:07:45: With the current memory and thread (16) limits, up to 16 thread(s) can be used for sequence normalization
20:07:46: Reading FITS: file r_pp_light_00025.fit, 3 layer(s), 6553x5817 pixels, 32 bits
20:07:46: Reading FITS: file r_pp_light_00013.fit, 3 layer(s), 6553x5817 pixels, 32 bits
20:07:46: Reading FITS: file r_pp_light_00028.fit, 3 layer(s), 6553x5817 pixels, 32 bits
20:07

And finally, here is the Script I run:

############################################

Script for Siril 1.0

July 2020

(C) Cyril Richard

Preprocessing_WithoutDark v1.0

########### PREPROCESSING SCRIPT ###########

Script for color camera preprocessing

Needs 3 sets of RAW images in the working

directory, within 4 directories:

biases/

flats/

lights/

############################################

requires 0.99.4

Convert Bias Frames to .fit files

cd biases
convert bias -out=…/process
cd …/process

Stack Bias Frames to bias_stacked.fit

stack bias rej 3 3 -nonorm
cd …

Convert Flat Frames to .fit files

cd flats
convert flat -out=…/process
cd …/process

Pre-process Flat Frames

preprocess flat -bias=bias_stacked

Stack Flat Frames to pp_flat_stacked.fit

stack pp_flat rej 3 3 -norm=mul
cd …

Convert Light Frames to .fit files

cd lights
convert light -out=…/process
cd …/process

Pre-process Light Frames

preprocess light -bias=bias_stacked -flat=pp_flat_stacked -cfa -equalize_cfa -debayer

Align lights

First doing: register pp_light -2pass -noout

register pp_light -2pass -noout

Now doing: seqapplyreg pp_light -framing=max

seqapplyreg pp_light -framing=max

Stack calibrated lights to result.fit

stack r_pp_light rej 3 3 -norm=addscale -output_norm -out=…/result

cd …
close

7

ok, thanks.

If you need to share large images or logs, you can use online services like wetransfer. Make sure you select Get a Link to be able to share without having to fill in a recipient email.

But nonetheless, I’ve seen what I wanted for now with your log and the script. Could you please try the following:

  • Duplicate the script and change the line seqapplyreg pp_light -framing=max to seqapplyreg pp_light -framing=max -noclamp
  • run on a few sequences and tell us if the nasty grey borders are gone.

I suspect it may be an image initialization somewhere which is not done properly, hence why I’m asking you to run more than once. Without proper init, the values assigned to the borders are random and it could be that by accident, we get occurences where it does behave as intended. Whereas if you run a few times and we get consistently black borders, we’ll know this is it. Unfortunately, I can’t reproduce myself because the init behavior is very much OS- and resource-dependant.

If adding -noclamp fixes it, I’ll make a patch and generate new binaries for you to test. On which OS do you operate?

Many thanks for helping us investigating this!

8

I’ll be out most of today, but I ran the same small sequence three times, twice with -noclamp and once without. I would quit and reload SIRIL each time.

-noclamp had 6.559% both times
Without -noclamp had a background of 2.287%

I’ll do more testing later if you feel it would be helpful.

9

Thanks for testing… I must say I’m a bit short of ideas right now. Don’t know what tests I should ask for… Let me get back to you in a short while.

Cheers,

C.

10

@smiller , thanks for sharing your files in DM.
I have opened this ticket -output_norm during `stack` can produce non-zero borders (#1159) · Issues · FA / Siril · GitLab for tracking.
As discussed, as a temporary workaround, removing the argument -output_norm in the stack command should do the trick. Just i case somebody else also needs the info while we fix it :wink:

Cheers,

Cecile

11

I verified that if I removed -output_norm from my script, it fixes the issue and the backgrounds are now black again. Thanks for helping to find the workaround!

1 Like