As started here: Siril needs distortion correction in stacking - #27 by Entropy512 Siril has a problem with the color management which is not correctly done. However, none of the developers in siril (@cissou8 , @vinvin, Adrian and I) have strong skills in this area and would be happy to have the contribution of one of the developers present on this forum.
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.
Hopefully in the next few weeks I’ll finally have more time to resume doing some work on various opensource projects.
One thing that came to mind which is semi-related after reading LRGB composition via command line - linear or nonlinear? - #9 by RandomThoughts is that it might be beneficial to do that sort of blending operation in a more deterministic “perceptually linear” space such as JzAzBz , rather than doing nondeterministic stretching/histogram modification operations - see JzCzhz color space - #9 by snibgo for some of the discussion on that. JzAzBz is a relatively new development in colorspaces, with the original research paper for it being published in 2017.
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.
