That wouldn’t affect colours would it…?
It’s a bit hard to tell from the screenshot as the image is a bit monochromatic but there appears to be more reddish/yellow on the left, sunlit side of the whale (?) in the lefthand image.
True, probably not. But the first thing I noticed was a difference in contrast/detail; I perceive the image on left as much more contrasty/detailed.
2 Likes
Depends on the profile fed as “softproof”. If it’s gamut is not materially different from the display gamut, the differences are probably negligible on the display.
As you’re finding out, it’s not that easy to trace the root cause of such differences. The key thing to narrowing down the problem is to make sure the color management mechanisms are doing their thing, or not. For instance, your browser may be color-managing what you throw at it by default to sRGB, not your display profile. For any display program, you need to understand how it does (or doesn’t) color-manage images. That extends to what system tools to which they interact, to make sure the OS is supplying the correct display profile to the display program, or, doing/not doing its own display transform.
The pedigree of your color profiles is also important. There are a few different variants of sRGB out there, for instance. Also, make sure your display is set to use your factory profile, and not sRGB, AdobeRGB, or some other mode.
Things external to darktable to consider…
1 Like
If you are on a new enough build you can toggle this and get a sense of the difference that you will likely encounter by exporting using yes vs no for HQ reprocessing…
1 Like
on my end, I set my display profile to system display profile and export setting to srgb . This made sure my images look the the same in any app that is color managed. (also had to do the same in krita). If I open the image in a non color managed app like microsoft paint, there will be slight differences because the app is not respecting the monitors profile. Still testing some thing though.
good video to check out. https://www.youtube.com/watch?v=-Inuk1aTwyc&t=4s
Hi Todd,
I like the concept of this feature to test the high quality processing. I just tried it on one image. I saw no color change but unexpectedly to me I saw it shift pixels a little towards the right. Seems strange, but nothing to drastic.
Huge thanks for the forum location change, and the advice. I wasn’t sure 100% where to put it. Here is the RAW and the XMP. As you can probably see from the history, this is the image I’ve been learning Darktable with. For fun, I also included the JPG in the original screenshot.
_MG_4407.CR2 (36.4 MB)
_MG_4407.CR2.xmp (62.0 KB)
_MG_4407_14|690x515
Regarding the post, on 4.6.1 the high quality processing button isn’t there, though I have noticed what you say about zooming in and seeing things change. I am exporting at full size, with High Quality Resampling on. I tried it with it off as well and got the same result, as you suggested would happen.
I am on version 4.7 so it is may be a feature not available on 4.6. I hope you resolve your problem.
Great point, there are certainly lots of external factors having their say as well. I’m not sure how to phrase this question, but when darktable uses the “sRGB colorspace”, is that something internal to darktable itself, or is that something already on my machine that it is looking up? I’m on a pretty standard Windows 10 install.
When I was researching my problem before making this post, I found your article on color management very helpful Article: Color Management in Raw Processing As I understood it, if my display profile is the same as my export profile, and the export profile stays with the exported image, when I view the export and RAW with the same display profile, they ought to look the same. That’s why I’ve been trying to make these comparisons in darktable itself, under the assumption that doing so is the most consistent way to approach this.
When it comes to stuff like this, I tend to assume that I am doing something wrong, or have some part of my system configured wrong - not that I couldn’t be the first person to discover a novel software bug, but it seems unlikely that I have done so compared to the odds that I have the wrong settings chosen or am missing a file somewhere on my computer…
1 Like
FWIW at least with this image I see what you are seeing… well I have not really looked at the color really hard but more the contrast. What I have on my preview just gets muddy when the image is exported and brought back into DT or a viewer… I tried a number of combinations of export settings and I saw that your jpg was a little down scaled so I was sure not to introduce that and I even went in to ART and did a sort of similar edit and then exported it and there the contrast of the water was maintained… I have felt for sometime that exporting in DT can be a bit of an adventure… My monitor is calibrated and not wide gamut and I can see this both by bringing the image back into DT, as a jpg or tiff or png …
I took your raw and processed it with rawproc, my hack raw processor. Exported it with Elle Stone’s sRGB profile, and got this:
So, I then extracted the ICC profile embedded in the green-ish JPEG you posted, and used it to export the processed raw, and got this:
No problem with the export profile.
I also opened the JPEG you posted in rawproc, color-managed it displayed green-ish. I then turned off color-management to see if there was a mismatch between the image data and the icc profile, and it stayed the same (my tablet display gamut is close to sRGB.
Methinks there’s some darktable processing going on…
1 Like
This is not something I’ve had an issue with (usually) but I see the difference. I just imported your raw and xmp files, then did a jpeg export with my normal settings, and appear to have a possible third variation now.
Screenshot from darktable below:
Left is the CR2, middle is your jpeg, right is my jpeg.
However. With my export, any slight differences disappear when viewed in full screen lighttable view (F), where as with yours it doesn’t.
Have you tried resetting your export module, than set the export profile to sRGB?
1 Like
Well this is much more interesting than I anticipated. Steven, I tried that, and no luck, at least for me. When I reset, the only setting it changed was to reduce the JPG quality from 100 back to 95. I set the export profile to sRGB, and it looks the same to me. I was using the output color profile module to define sRGB as the export profile, so I believe that should be the case. I also tried exporting at 76 like your image, but that didn’t seem to change anything besides the file size.
Can I ask what version of darktable you’re using? It seems like it’s working for you. If you view it at full size it looks like the JPG, which I believe is expected behavior based on some modules not previewing correctly at less than full size.
1 Like
I took some time to work with your image and came up with the same color differences. I started with a fresh edit, only applying base modules like exposure, filmic, and color balance RGB and denoise, and found that the deep blue water appeared to change green-magenta tint when exported to jpeg or tiff. I found the same result regardless of output profile.
Also, I noticed that the color shift is more pronounced in the deeply saturated blue water and less in the sky (the shift may be happening in both but less noticeable in the sky).
Interestingly, the differences seem to diminish as I zoomed in to 100 percent. I have to wonder if this is related to the higher noise in the photo, even with profiled denoise heavily engaged.
Taking the resulting tiff or jpeg and then exporting once again into the same format causes no color shift, so I think it’s something happening during the raw conversion.
I also tried this with my own shots on my Canon 7D2 and R7, which produce CR2 and CR3 files. There were some minor instances of color shift, but they were barely noticeable unless you compare them side by side.
So I wonder if this has something to do with the CR2 files from you 80D, or if it’s unique to deep blue tones.
1 Like
With darktable 4.7.0+693~g2a57b25fe3. I resized the window (the larger the difference between export size and view size, the larger the processing difference can be). I then took a screenshot, turned on the new ‘HQ processing’ option for the preview, and took the screenshot again (the difference is when scaling is applied to create the preview: as soon as possible, or only at the end). Sure enough:
So, this is one of those problematic images, when resizing changes the output.
BTW, your denoise (profiled) settings are a tad extreme. Note the popup:
I think the whale looks rather waxy – but then denoising is subjective. I’d go with something like this:
_MG_4407.CR2.xmp (22.8 KB)
(History is the same as yours, but I compressed it and removed disabled modules, then adjusted the denoising settings.)
1 Like
Do you think there is any chance that this happens as some sort of by product of the scaling in that while its not direct averaging of pixels it is combining them for a downscaling…there was this post a while back about how DT doesn’t calculate the correct value of an image with a checker board of red and green squares… DT would come up with a simple average value of 128 or something when it should actually be 180. The same image seemed to be handled properly in GIMP. I think there may even be an outstanding use marked to be worked on around this… in any case add in the extreme noise and it just makes me wonder if something around this sort of math processing might contribute to seeing these sorts of differences
I don’t know. I suspect that the modules that apply non-pixel-wise operations, such as blurs, don’t work 100% correct, even if they scale down the radius to try and match the downscaling of the image used to generate the preview. I did not have enough time to investigate, but I suspect that the denoise (profiled) module with its large search radius had something to do with this. You could try disabling it and see if the difference in the image rendering (when zoomed out) occurs to the same extent or not.
2 Likes
I’m running a weekly development build from the ‘windows insider program’ posts on this forum, 4.7.0+543~g7f31698655
It’s got me puzzled! But I’m no expert…
1 Like
Well I’ll be damned, when I turned that 2nd denoise module off, the export looks just like the 100% zoom in darktable, at least to my untrained eyes. I would like to shake your hand, this feels amazing.
I had that module in there because I felt like after the first denoise pass, the water became kinda blotchy with reddish and greenish patches, and I felt that 2nd denoise cleaned those blotches up quite nicely. The downside was the waxy whale, but I’ve been staring at this dang whale for [too long] and I had finally decided I preferred a too-smooth whale to a blotchy whale. I figured I would take the runtime hit and accept it as penance for my bad-photography-sins. Silly me, no sacrifice will atone for 6400ISO.
So it sounds like, if I read correctly, that there’s a risk with large non-pixel-wise operations of creating differences between the display and export images. Is there someone, or somewhere, this information would be valuable?
Thank you so so so much for taking the time to mess around with this picture and help me out, and to the rest of you guys who also played with it and chimed in. I’m so stoked.
1 Like
I have taken to using two instances for denoise. The first is the chroma preset for profiled denoise. I find adjusting the preserve shadows slider can really improve the result here. Then you can be left with the luma noise… I know it can be targeted in profiled denoise but I like the result of the astrodenoise module for that. I find I can get a good results esp if the noise is the sort of salt and pepper type. For extra color noise the surface blur module which was formerly named bilateral denoise is also good. THe contrast eq can also help in some tricky situations… I’m glad you found the culprit…
1 Like