A small issue when processing stars with beta version 1.4 of Siril. I’m not sure I understand how clipping works.(this option was not there in previous release 1.26). Basically, I get the impression that when stretching the background, some sort of stretch is being applied (I’m definitely in linear display mode). Before, when the black point was properly aligned with the background, I had a black background. Now that’s no longer the case. I can tell it’s related to clipping, but the logic escapes me.
The clipping mode shouldn’t make any difference for background pixels, it only has any significant effect where one of the colour channels in a pixel is clipped and others are not.
I can’t see from your screenshot what colour stretch model you’re using for the background, however the default is “independent colour channels” which maybe isn’t the best choice. Try changing it to human-weighted luminance and see if that solves the issue. If you can confirm it does I’ll change the default, as we shouldn’t have a default that may introduce colour shifts.
Thanks for the response.
the colour stretched model was set to “Human weighed model”.
None of these settings have a material impact on the issue.
this is new behaviour to the 1.4 beta.
i added a screen recording (speedx2) of the issue. Again the main behaviour is that the blacks are not black even though the histogram is pushed to the left.
also note that:
- every time a parameter is changed, the recompute of the image is quite heavy ona very decent PC
- the UI is really problematic with sliders hiding etc. and the window size too small (hence need of sliders) to show all settings in one screen
further evidence of the stretch behaviour attached in the video.
When i add the starless image it seems to show a stretch of the file. then i add the starmask and the image goes back to linear? this happens also when i perform the single stretches on the starless side…
The recompute can be heavy, that’s true. There isn’t really a lot that can be done about that, at least in the short term: GHT stretches are mathematically heavy, requiring expf, logf or powf functions for each pixel and each channel, plus a number of other operations all on float32 data. As much as possible is precomputed and there was some optimisation work during 1.3 that significantly improved the speed, but especially in Star Recomposition where at least 2 GHT stretches and a blending operation need to be done for each pixel it just is naturally quite CPU-expensive.
We know about the UI, there is an issue in gitlab about it and believe me I would like to improve it. However in the past we have come across GTK issues when making the dialogs resizable and simply having them fixed size but larger makes them unusable for some of our users who have small screens (I guess people using it out in the field on small format devices…) So unfortunately we don’t have much of a way ahead to improve it at the moment. But it’s definitely on our radar as something to work on if / when toolset changes allow.
Would you be able to share a link to your Iris nebula image so I can investigate the blue issue, as I don’t really see the same thing with my images. Thanks!
note: I was the author of the usability issue on gitlab !
you dont address the main issue: the image is stretched by just changing the stars (sec 40 in the second video).
this is really what i am enquiring about. same behavior happens during ght. (computing and usability i can live with)
I just spotted why: it’s the sliders. They are in min/max mode, and with your background the min and max are both quite low so effectively the preview is showing a linear stretch across the brightness range of your image. Then when you add the starmask the max value jumps up to over 20,000 ADU. So the displayed brightness range changes and the image preview appears to become darker. It’s just an artefact of the preview mode: if you don’t like it, set the sliders to user and drag them to 0 and 65535. At any rate there is no effect on the underlying data.
1 Like