This thread is the starting point of such a contribution in order to not flood the other topic anymore.
This is too late for the Siril 1.2.0 beta but could be implemented in the stable release if we find a suitable workflow.
No problem on not making 1.2.0 - good work should never be rushed (and I’ve been really busy with other stuff lately, so will take some time to get back up to speed with siril as it’s been a long time).
Also this probably would wind up being something that needs a multi-phased approach - initial short-term should be handling display transforms and tagging of linear data better, and just kick the gamut can down the line.
At some point, probably either some digging needs to be done in the raw color management/color transforms, or just lean into focusing on Siril as a stacker and pushing the color management heavy lifting to other tools, with a focus on Siril preserving the required metadata to do this. (e.g. for input that originated from a DSLR/mirrorless raw file, don’t do color transforms, just stack, and output a DNG that has appropriate color metadata for further processing. Note that it is possible and in fact becoming very common to have DNGs that are already demosaiced now that mobile devices are doing their own variations on stacking - it’s often referred to as “linear DNG” which is a bit of a misnomer because mosaiced DNGs are usually linear too…)
Cecile tagged me in the discussion. I’m afraid colour management is an area I know nothing at all about, at least implementation-wise, though I’m happy to help adapt any of my code if changes are required, or with testing. Great to see we have a willing volunteer to contribute in this area!
We do have a bit more of an interest in post-stacking processing now, with improved stretch capabilities and other new functionality since the 1.0 series, so ideally I guess we would handle the colour transforms correctly through the processing stages rather than assuming that would be done later by another application.
I haven’t encountered the phrase “perceptually linear”. It is potentially confusing. The usual phrase is “perceptually uniform”. The JzAzBz colorspace is an attempt at perceptual uniformity, meaning that equivalent numeric differences have equivalent perceptual differences, regardless of their positions in the colorspace.
Linear colourspaces are not perceptually uniform. Perceptually uniform colorspaces are not linear.