I’ve loaded your exported version and your input JPG + XMP into darktable. The exported file looks more saturated. Then, I exported the input + XMP using the default settings, loaded it back to darktable, and it matched the editor almost perfectly. So it’s something in your output/processing.
Your export vs mine, in Gimp, merged in difference mode, and then the histogram stretched:
The moire pattern is not due to downscaling, it was there in the original.
My export settings were simply:
However, my darktable settings have this non-default option enabled:
So, I disabled it, exported again, but nothing changed – with and without the option, my exports matched the editor, but not your export.
Edit: however, the may be something going on when explicitly changing the profile to sRGB (web-safe) in the export dialogue. I’ll check later, now have to work.
On my system, Win 11, DT 4.8, everything works as it should. Your export, viewed in Windows Photos looks exactly the same as your original in my Darktable (with your sidecar loaded).
I’ve never seen this - been on Win 11 for years and Win 10 prior to that and always used Photos. Admittedly I suppose I might have missed it if I never made comparisons, but… I would have noticed compared to Darktable’s preview surely…
Maybe there’s different versions of Photos and I somehow missed the weird one?
It could depend on some windows and or laptop or display settings for “enhancements” in the OS… I wonder if it could be hardware specific but it seems that for some people anyway there is the possibility that there is some adjustments to brightness made due to these settings… I don’t use it anyway… Xnview is my go to app for viewing images outside of DT so I don’t care too much… If I recall it was funny in that the image preview in file explorer was fine it was just when I went to the photo’s app I would see this…but it doesn’t happen on my work PC…but now that is a laptop with and external monitor so a different setup as well…Still getting back to the OP’s question… I can’t reproduce that export that they have… I get one that matches the DT preview even when tweaking a few settings I even loaded it ie the exported file as a sidecar and I don’t get that output…
I thought maybe the same but I think I checked that last night and no difference… I was wondering if the export was done with a non-default profile… I myself use the color.org profile and then I can access the rendering intents and I often like relative rendering as its a bit more punchy …but I think the OP did not indicate modifying the output profile… You should maybe still check…
So, I’ve checked always use LittleCMS 2on vs off, profile = sRGB (web-safe) vs image settings. I’ve also compared exporting directly from the darkroom vs from the lighttable. That’s a total of 8 files, but in fact they could be grouped into 2 sets of 4: the only difference was LCMS on vs off. And there was no visible difference between the two groups, but both (of course) showed a difference to your export.
Yours vs LCMS on, 32-bit linear light in Gimp, difference mode, histogram in the Levels tool:
LCMS on vs off:
This time I used the current development build on Linux, but what I saw is consistent with what I saw earlier on Windows with 4.8.0.
Huh, switching to sRGB in the softproofing menu seems to solve it.
Have a look: Imgur: The magic of the Internet
Windows Photos still looks a bit more saturated, but Google Photos in Firefox looks a lot closer to the preview in DT.
So, the conclusion is make sure that the display profile matches the color profile of the photos?
Your display profile is there to describe your display. If you’re display does not match sRGB (e.g. has a much wider gamut), it will show false colours.
Then calibrate your display to sRGB, or calibrate it properly and have the soft-proofing on, I think. If you set your display profile to sRGB, it simply means your OS and darktable will handle it as sRGB, sending values that represent colours according to the sRGB encoding, but if your display has a wider gamut, everything will appear oversaturated.
Oversimplified example: let’s say a particular colour can be represented by the sRGB values 200, 100, 50. If you send those numbers to a display calibrated to sRGB, it will displayed the exact colour. However, if the display is uniformly 10% wider than sRGB, it will display 10% oversaturated values, it would need the values 180, 90, 45 to display the same colour (warning: oversimplified, very unscientific, very inaccurate).
Something with your export is simply wrong: on my machine, if I load your edit and your export, the darkroom preview appears less saturated for the edited source than your export. It is my understanding that normally, that should not be the case: the working space, Rec 2020, is wide, and can represent more saturated colours than sRGB, so I’d assume it’s OK for the the editor preview to show saturated colours that cannot be represented when exporting to sRGB, but not the other way around. Additionally, when I export your edit on my machine, I don’t see such a difference.
I always thought the whole idea of embedding the image colour space (NOT any kind of display profile!) was to allow correct colours independently of the display device (within the limits of the system). The display system should do the required conversions…
Of course, for that to work, the display device must be set to the correct colour space (with perhaps also a device profile for extra precision). That means, a screen that can display AdobeRGB should be configured as such, and then (ideally) the OS, or individual programs (but not both!), should take care of any needed conversion.
That also means that any image should either have the correct colour space embedded, or give a reference to a well known standard colour space, or be exported after conversion to sRGB (or whatever colour space the output format prescribes as default).
It should not have a display profile applied.
I think it can be a mix: the OS can be responsible for loading values into the video card LUTs (part of the calibration), and the apps can convert their working space representation to the display representation.
