The Tiff file is intended to be the last step of the process. Once the image has been delinearized. Moreover, it is not mandatory to save the ICC sRGB profile.
It is true for any file format. This is just to warn the user that the viewer is not set to linear. Nothing more.
I’m not sure what you mean by “it is not mandatory to save the ICC sRGB profile”. Is there an option to not do that? Regardless, I don’t see what the point of that would be. If the image during export is (forcibly) converted to sRGB, why would you not want to attach the ICC sRGB profile?
What would make more sense, is an option whether or not to convert to sRGB in the first place.
Okay, but the message implies to me that the export is supposed to be linear (while the editor is not), but maybe I’m misinterpreting it.
So glad I came across this post.
These images are exactly the kind of weird distortions I end up with when processing my 13mm images. The “square stars” (which my brother found hilarious and had never seen in his own astro work before), weird and inconsistent star trailing … often within the same image, on images that shouldn’t have any star trailing at all, are all here in your example images as they have been all throughout most of my wide field processing in Siril.
I thought it was the lens I was using but when I tested the lens it out specifically for these distortions they weren’t there. Even more folks typically pointed out how very low the distortion in the lens is as compared to many wide angle lenses and yet there I was: square stars and all.
So this is definitely a thing.
And since it appears that wide field stacking is not a Siril development priority and probably won’t be anytime soon that leaves me a tad frustrated at the moment, tbh.
Not so much regarding the lack of priority since priorities are what they are. But, more that I have been using SIril pretty much exclusively since I started this journey about a month ago. And it seems that so many of the issues I have been running into, and that I have spent north of a hundred hours working on because I just assumed my ignorance was the problem, have instead ended up as, basically, “Siril is no good with wide field substacks and probably will never be; shoot longer lenses or use something else”.
I’m not upset about this as a reality of the program but I am frustrated that nothing in Siril ever told me that. Nothing in the tutorials ever pointed this out. I have only discovered this as a truth built into the fabric of Siril, and its development priority scheduling, by finally giving up in frustration and scouring forums. It is only through those posts that I have come to see the many “don’t use wide field” as an implied, or occasionally explicit, refrain to folks asking for help.
Siril works fine, for the most part, for my 100mm+ substacks taken on my Nikon. It even has done ok with my Sigma 18-50mm lens on shots taken around 50mm. But my 13mm has been a miserable experience thus far and given that that lens was built, among other things, specifically for astro photography I have been very confused why my results have been so bad.
Not sure what to do, honestly. I like Siril and have learned a ton on it but at least half of the images I take are intentionally wide field and will continue to be so.
I don’t know.
Maybe I’ll try to figure out the other programs and generate a workflow I need to automate all the pre-Siril work that is required to help Siril produce what I know it is capable of producing. I’m on Linux so it isn’t like I have too many choices, here, that I know of but I pretty sure I have more than enough available to me to cobble something together.
Pixinsight works on Linux but trying to acquire an evaluation license from them is, ironically, how I landed on Siril to begin with. I’ll try them out and see if they are any better but I have no reason to believe they are, one way or the other. I’ll look into some of the other programs mentioned in this thread and see what can work and what can’t.
I’ll figure out the workaround but maybe Siril can, for now, post a warning in the application that many of its features will fail, or work sub-optimally, on lenses below “insert focal length here” so new users can at least have a heads up on this. It is not a problem that Siril doesn’t cover these focal lengths well, it is what it is, but it might help out those that don’t know that it is a thing so we don’t waste so much of our time trying to get results out of Siril that it just can’t, and maybe never will, be able to give.
I am a very stubborn person when it comes to learning things I’m interested in but even I have been starting to reach the point in this journey where I’m questioning if I’m actually good enough to do any of it given the crap results I have been getting. I’d hate to think that I might have walked away from all of this cool astro photography work thinking myself simply incapable when it was actually the software that I was using, not me.
So maybe help us newbies out with a well delivered heads up?
Siril only appends the sRGB color profile to the tiff file but it does not transform the image data accordingly. So as long as you didn’t apply a non-linear processing step to your data in Siril then the image data will still be linear.
Thanks a lot for this, interesting. I have a question though: why? That doesn’t make any sense whatsoever if the image is not actually converted into sRGB. It will only cause other software opening that image (Darktable in my case) to misinterpret the image, since it is not actually in sRGB.
Next question: what is the correct colorspace? Rec2020 linear, Rec709 linear, or something else even?
Siril gives you the option to write a tiff file with or without appending an ICC profile. However, Siril is not color managed so appending an ICC profile to the image data does not make much sense IMHO. I think you might find this discussion helpful Siril Colour Management
Right, a color managed application like darktable will apply the sRGB TRC to the data accordingly even though the data is not sRGB. In addition, Siril does not apply the display transform to the image data rendered in the preview. Therefore, the Siril preview image is not actually linear.
The raw image data loaded into Siril will be in (linear) camera RGB. Siril does not apply a color correction matrix (CCM) like other raw converters such as darktable. Therefore, if you are only applying calibration frames (darks, flats etc) and staking lights then the final staked image will remain linear camera RGB. However, applying operations like photometric color calibration or a histogram stretch will shift the data into a different (local) color space - but most likely not sRGB.
I still have not found where I can toggle that option. But it doesn’t matter much anyway, since you can always ignore the profile.
Exactly. Attaching a sRGB profile to an image that is not actually in sRGB is just lying. I really don’t understand why Siril does this since I can’t think of anything this will accomplish, except that when opening the image in other software, that software will misread the image.
I see. Thanks for clarifying!
We only did this so that photoshop/Lightroom would open the images properly. Without that it was catastrophic with a lot of complain.
If you have a better solution don’t hesitate to contribute.
The role of Siril is not to play with the color profiles. This is the role of the software used after.
It’s exactly the other way around. This way, software like Photoshop and Lightroom are not properly opening the images, since they assume they are in sRGB when they aren’t.
Sure, I’ll look into that!
Yet “playing with color profiles” is exactly what Siril is doing, I would say, since it is haphazardly attaching color profiles when it’s not correct.
But this is not mandatory:
Maybe but doing like that, now, users see image in photoshop as it is in Siril. While it wasn’t…
Oh, and to understand the origin of that:
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.
Hello @Entropy512 . Thx for your message.
In Siril, and in general in astrophotography, we try to stay as much as possible with a linear image. However, at the end of the process, we usually want to stretch the histogram, either to work in another more classical software, or directly show the image.
In Siril there are 3 algorithms doing such things:
Generally, TIFF images are images that have been stretched by one (or more) of these algorithms. These tools are dedicated to astronomy images, but that’s all I can say, because I don’t have enough skill in color managements. Adding sRGB is probably a mistake for the purists, however it fixed a problem that was reported very often.
I don’t know why you are saying this. All contributions are very welcome, especially in a domain where none of us know something. If someone want to contribute to improve the export part of Siril, please do it.
I’ll take a look at this later then. So based on this, you are doing some transformations, but NOT transforming into a gamma-encoded space?
If that is the case, then linear is definitely the correct transfer function for the exported ICC, however it might be pure luck that some of those transforms make things look OK when misinterpreting as sRGB.
In general:
Linear encoded data misinterpreted as sRGB looks very dark overall
sRGB data misinterpreted as linear looks washed out
Do you have any issues with adding a dependency on LCMS2? It would be far better to generate ICC profiles on the fly based on image metadata/properties than to store canned bytestreams for some predefined ICC profiles. elles_icc_profiles/make-elles-profiles.c at master · Entropy512/elles_icc_profiles · GitHub is one reference for generating ICC profiles programmatically, RT’s source probably has another one.
I do agree but … All images exported from Siril, and opened as sRGB in GIMP or other software looks great… This is why I’ve used it. For me, sRGB was the profile that best matched the image display and I have not enough skills to understand where the issue is.
Not at all. It won’t be for 1.2.0 but adding LCMS2 will be a great improvement, for sure.
Thx a lot for your help.
I can explain this phenomenon.
The first problem is that Siril does not apply the appropriate display transform, which is typically the sRGB TRC in most cases, to its preview image. So, a raw (linear) image is rendered too dark in the preview window to begin with; that is, the raw linear image the user sees in Siril’s preview window is not linear data.
Next, the user processes the linear image based on what they see in the preview window. This usually involves applying non-linear operations like Asinh until the user is satisfied with the look of the preview. The processed image is then saved with the ICC sRGB profile but Siril does not apply the sRGB TRC. Basically, the saved image is stretched more than required in order to compensate for the missing display transform; that is, the image would look too bright (or washed out) if the equivalent operations were applied in color managed software.
Finally, the user opens the saved “sRGB” image in a color managed application (darktable, rawtherapee, photoshop etc). These software typically use an intermediate linear working space, like linear Rec2020, for processing. The software is expecting sRGB data and so applies the sRGB TRC accordingly to transform the image data into the working space before rendering the image in the preview window. Being color managed, unlike Siril, the software also applies the appropriate display transform to the preview image. These two operations, i.e converting from sRGB to the working space and then applying the display transform, will effectively cancel each other provided that the display profile is also sRGB. When that is the case, which is certainly true for the majority of users, then the image displayed by the color manged software will more-or-less match Siril’s preview image (discounting gamut mapping).
So, it’s the ubiquity of the sRGB color space rather than luck which explains why things look OK to most users. Unfortunately, this is rather a false sense of security because the reference for comparison, i.e Siril’s preview image, is incorrect to start with. I see two potential problems for users when the ICC profile is appended to the image file:
When the display media is not sRGB, e.g AdobeRGB or printer color space, the displayed image colors will not match Siril’s preview (remember the user bases the look on Siril’s preview image).
A linear image, say a stacked light calibrated with biases and flats, is transformed into non-linear data when it’s loaded into color managed software. Any operations intended for linear data are actually performed on non-linear data but the user is not really aware of this.
Hello, as Cyril said, we don’t know much about this side of image management, this is also the case for me. I don’t understand this sentence. How does a raw linear image, displayed with a linear transfer function, does not display linear data?
Transfert functions used in siril are nonlinear.
Disclaimer: I’m going to completely ignore gamut and primaries for now. As I said, this is in general far less egregious than getting the TRC wrong. As such, any time I say “sRGB” in this post I am talking about the transfer function part of sRGB, and not the gamut/primaries.
Aha. Based on this, it sounds like:
siril (mis)feeds linear data to the display - which is in most cases expecting the sRGB TRC
As such it looks dark, so the user does heavy massaging to fix it
In the end, the data has been so heavily massaged that it looks good when (mis)interpreted as being sRGB TRC
This data is then exported and (mis)tagged as having an sRGB TRC - two wrongs wind up making a right in these use cases, but are problematic for users who wish to further postprocess linear data in another application
Honestly, naively assuming the display is sRGB in both gamut and TRC would be better than the current scenario, it’s going to be a solid match for 95%+ of users (hey all of the perfectionists would love for everyone to have a calibrated display, but it isn’t going to happen. Hell, I don’t even have one at the moment but I at least understand that this could cause problems for me.)
A better (partial) interim solution would likely be:
In preview, transform data to an sRGB TRC (which matches 95%+ of displays out there, and in fact most OSes will assume that a non-color-managed app is putting out sRGB anyway, so the OS will likely handle most of the remaining 5% well)
For export, transform data to sRGB TRC and tag as such if it’s low bit depth
For export, preserve data as linear and tag it as such if it’s high bit depth
Probably have a toggle that lets the user override the transforms to preserve legacy compatibility.
This would likely result in users having to perform far less manual massaging to have an image looking “good”, they would have a reasonable starting point.
For reference, the last time I used siril I ignored the preview, because my goal was linear raw in, average-stacked raw (not even demosaiced!) out.
I suspect what he means is a raw linear image, misdisplayed with a nonlinear transfer function (since that’s what appears to be happening based on his description), because unless you’re color managed and TELL the OS/compositor that you are feeding it linear data, the OS is going to assume you’re feeding it sRGB-encoded data