I think part of the confusion here is that sRGB happens to describe both a gamut (primaries) AND a transfer function.
It is possible (and very common) to combine sRGB primaries with a transfer function other than sRGB. (frequently linear - see WIP: Bundled profile for reference image by Entropy512 · Pull Request #6646 · Beep6581/RawTherapee · GitHub and Reference TIFFs are not tagged with an ICC profile that indicates linear data · Issue #5575 · Beep6581/RawTherapee · GitHub)
In the event that Siril is saving linear data, the profile currently being embedded is definitively wrong. In the event that siril is not saving linear data into TIFFs (when almost the entire siril pipeline operates as linear…), then it really should be, along with an ICC profile that properly describes it as being linear data. At least looking at src/io/image_formats_libraries.c · master · FA / Siril · GitLab I’m not seeing any application of an sRGB TRC, so the output is likely linear unless something is triggering nonlinearization elsewhere? Ideal defaults would be to encode 8-bit output nonlinearly, and 16/32 bit output linearly.
The profile is also vastly oversized (it doesn’t REALLY matter for the most part), but saving a 1024-point LUT TRC for something that can be described using parametric TRCs is really unnecessary.
WIP: Bundled profile for reference image by Entropy512 · Pull Request #6646 · Beep6581/RawTherapee · GitHub provides an example of an ICC profile with sRGB primaries and linear encoding.
While it is technically wrong to save raw sensor data with an ICC profile that indicates sRGB primaries, it isn’t nearly as egregious as misrepresenting linear data as not or vice versa. (In the case that the input files are raw sensor data from libraw, then you could probably generate appropriate primaries on the fly from the metadata reported by libraw though, which would be ideal.)
This attitude is, by the way, one of the primary reasons I stopped using siril for stacking and wrote my own stacker, albeit for a fairly specific subset of siril functionality. ( pyimageconvert/pystack.py at master · Entropy512/pyimageconvert · GitHub ) If you intend to remain a non-color-managed application, then you should make it less painful for users to postprocess your images in a color-managed postprocessing workflow. The requirement to use FITS as an intermediary on input was understandable/acceptable, as while it was unnecessary in my use case it is necessary for memory management in many others. The difficulty of performing further postprocessing after stacking, on the other hand, appears to be an intentional design decision based on comments like this. I would have poked at potentially improving the export system, but again, comments like this imply to me that such a contribution would be rejected as being not compatible with design intent.
“not color managed” and “program output is not intended to be processed any further” are fundamentally incompatible attributes for anything that is processing raw sensor data from a camera. If you’re processing raw sensor data, you MUST be color managed OR support further postprocessing by an application that IS color managed.
I fully agree with this one here. Specifically in regards to whether or not to apply an sRGB TRC - I’m 100% OK with “don’t do colorspace/gamut conversions”, and mostly OK with “yeah the primaries/colormatrix are wrong”, but 16-bit TIFFs should at least have the option for linear export.