I’ve had this happen often with my exported files. The final exported jpeg seems to lose the local contrast that I’ve added. This might have been covered in another topic (feel free to just point me towards that topic) but I just wanted to revisit it. I’ve always suspected that its the profile I export with and based on the examples below that could be the case. I have only changed the export profile. Is this correct thinking? Would fitting the photo in a specific color gamut affect local contrast? Should I be editing a different way to best export without the final jpeg (in this case) being modified from the darktable preview? Do I need to move modules in the pipeline?
darktable preview/ linear proPhoto RGB profile + relative colormetric
file:///home/eswain/Pictures/Screenshots/Screenshot%20from%202023-08-31%2009-03-59.png
I’ve uploaded to piwigo and viewed from there. So I need to acknowledge that piwigo might only work within sRGB. If thats the case then why are the two exported photos different, with linear proPhoto looking closer to darktable preview?
Because the zoomed-out preview is generated using early downscaling to improve performance of the darkroom preview. That is, if you work on the image zoomed out to say 25%, then the image is downsized to the corresponding dimensions early on, and darktable has to process 1/16 of the amount of data. You don’t have to wait several seconds when you drag a slider.
It’s not specific to darktable, RawTherapee also does this.
thanks I’ll check it out. Do most people edit zoomed in? Or, in most cases the differences aren’t significant enough to notice. I swear I always seem to look at my exported photos and go damn, should have added more contrast.
I think it’s only things like sharpening and local contrast where you’ll notice a massive difference. Generally I do that sort of thing at the end anyway. You can always export, look at the final image and then tweak after.
If you are using the srgb from DT it does not support rendering intent… I think it is hard wired to actually be relative even thought the default in the dialogue is perceptual. I feel feel like someone working through the code in a github post noted this… In any case the profile has no tables for rendering intent… I have also noted that if you look at your image zoomed out to full screen then selecting no to high quality reprocessing will give a closer match. Where as if you set it to yes… it will look more like what you seen on preview when you zoom in to 100 percent… The two will be noticeably different…
I also noticed recently since getting a device to profile my screen that using displaycal and making a profile that had a lut made Windows photo do a terrible job rendering my files for preview. It was never perfect but generally default exports with the DT profile looked okay. If I did a curves and matix profile Win11 photo’s was much better …
So you can try standard export conditions and try the yes vs no to see how that fairs and then you need to be sure that your display profile being used in DT and your OS are in sync and compatible with your chosen viewer… For me on windows xnview lets me use the system icc profile or choose one so I know I am using the same profile in DT and with the viewer and it seems to work with all types of icc profiles…
If you want to try rendering intents you can use the srgb profiles from color.org…
You can try this one… relative should be more contrasted than perceptual… but I suspect on top of that, that setting the reprocessing quality to yes or no will still impact it as well… sRGB_v4_ICC_preference.icc (59.5 KB)
