MacOS: 3.0.0rc0 Minor artifacts in jpeg export.

[blj86]

Describe the bug
When exporting a jpeg I am experiencing minor artifacting in the lower right corner of the image. Represents itself as black pixels which are not present in the raw.

To Reproduce
Steps to reproduce the behavior:

1. Edit image
2. Go to library to export
3. forced width to 1920, quality 90, sRGB output profile, rest of settings at default ie. no high quality resample enabled.
4. exported image has a artifact represented by black pixels in lower right corner.

Expected behavior
I expect no artifacts on export.

Screenshots
Included in this google drive folder is the Raw, xmp file, jpeg I exported, screenshot of the export module settings, as well as a cropped jpeg pointing to the artifact. All files are licensed CC BY-SA 4.0 feel free to use as you need.

https://drive.google.com/drive/folders/1fhOmBMUQ3lcpJseviRyCRdOdu4RLpxOA

Platform (please complete the following information):

• OS: MacOS 10.14.6
• Version: darktable 3.0.0rc0

Additional context

I did do some messing around with the settings. Bringing up the quality to 95-96 and enabling resampling seems to reduce the artifact significantly but still a small amount of presence remains. I also did an export using Rawtherapee as a comparison point with as similar settings as I can get and artifact is not present.

[parafin]

1. Is lens correction part of edit?
2. Is OpenCL enabled in the preferences?

[blj86]

1. Yes lens correction and remove chromatic aberrations.
2. Yes OpenCL is enabled.

Being that you asked about OpenCL I did a quick test with it off. Using the same settings as in the google drive with OpenCL off the artifact in the corner goes away.

[parafin]

And what about if you disable lens correction? It looks to me like incorrectly cropped lens correction.

[blj86]

You are correct. OpenCL enabled. Lens Correction disabled and the artifact is not present.

Assuming darktable is using lensfun for corrections I will need to look into how to submit a fix for this lens.

[junkyardsparkle]

Assuming darktable is using lensfun for corrections I will need to look into how to submit a fix for this lens.

The scaling value is actually not part of the profile, but calculated within darktable for each case. I saw another mention of this happening in an unrelated issue recently. I wonder if something about the new pixelpipe situation requres some adjustment to how the scale factor is calculated?

[junkyardsparkle]

Hmm. I don't see this with or without OpenCL (GTX 1050 with the proprietary Linux drivers). I do see some slight difference in hilight brightness, but otherwise identical in the corners, without the artifact.

[blj86]

Interesting. For me it only happens with the lens correction enabled + OpenCL. Not sure if there is some special OpenCL paths for MacOS or not. Not sure if it is a Mac driver issue or not. I tried a paid software I own On1 which also uses lensfun and GPU enabled for edits and the issue does not exist as far as I can see. Has me wondering what could be causing it in my case.

[junkyardsparkle]

There's a lot going on in that history stack... it might be interesting to try removing other modules one by one, and see if you can eliminate the issue while still using OpenCL and lens correction. Maybe at least test with dehaze turned off... that one actually causes the lightness variations I was seeing, I think... it shows even more variation when toggling 'high quality resampling', but I think that's a known issue (EDIT: yep, #3339)..

[blj86]

@junkyardsparkle
Sorry for the delay so I was working and did not have time to do more tests. So here are my findings taking input into account.

1. As requested I disabled dehaze module and did an export. The artifact was still present using OpenCL.

2. So what I did next was reset the history stack only added lens correction and did a export the artifact was not present. OpenCL also enabled.

3. Curious I decided to edit the photograph again but this time doing a export after each module addition to the edit. The artifact appeared after activating and setting the sharpening module. Removed sharpening module and activated the contrast equalizer for sharpening artifact is also present in this case as well.

This is making me think perhaps the sharpening is exposing the artifact on the image but was present even tho not showing in previous exports of this test.

4. Disabled all modules minus the Lens correction and the contrast equalizer. Artifact is present in the export.

5. Turned off lens correction left on contrast equalizer. artifact is no longer present.

All tests were done with OpenCL on and Dehaze module was never enabled. Hopefully all of these efforts help in showing that there may be a issue with with the crop of the correction as stated in a previous comment. Seems to only happen with OpenCL and the lens correction with sharpening exposing the artifact.

[junkyardsparkle]

It certainly sounds like OpenCL on Mac somehow gets that scaling very slightly wrong... or just not precise enough? I'm assuming the module shows you the same derived 1.022 scale factor that I'm seeing for that file? Unfortunately, the way the lens correction module works doesn't allow for very convenient workarounds, at least not for a zoom lens (you'd have to create an adjusted auto-applied preset for every focal length... and each aperture if vignetting correction is involved).

[blj86]

Yes same scale factor of 1.022.

I will update to Catalina just to see if a assumed updated driver resolves the issue. It sure does seem like a OpenCL math error specific to MacOS.

[blj86]

@junkyardsparkle

Just had a chance to go through the update to MacOS 10.15.1 (Catalina). The artifact is no longer present at all no matter what modules or settings I use. OpenCL or not. I would say we can place this as a bug with the 10.14.6 Mojave OpenCL driver causing some sort of math issue. Which is resolved with a updated to the latest version of MacOS.

I feel this can be closed now as I doubt there is little point in trying to work around the issue in Mojave as it does not seem to be majorly wide spread from the reports on here as I was the first to mention the issue as far as I can tell.

[junkyardsparkle]

Good to know! It's subtle enough that it could easily be going unnoticed by some people, and would of course be eliminated by even a slight crop or rotation. I don't know if @parafin has any interest in patching for a special case or not. If so, it might be good to get an idea of what the range of severity is (maybe depending on distortion type) and if it happens only when correcting distortion, TCA, or both... those tests will be for the next person who reports. ;-)

[parafin]

No, I have no interest in fixing it. This looks to me like one of the many incompatibilities between various OpenCL implementations. That's not my area.

[junkyardsparkle]

Ok, then somebody should probably close this. Honestly, the best thing might be to just make the scale calculation more conservative, to allow for things like this. I don't think there would be many complaints about 1-2 fewer pixels retained at the edges; darktable already retains substantially more of this marginal area than cameras do, from what I've seen.