Diffuse or Sharpen (local contrast) exporting issue with OpenCL on Intel MacOS about darktable HOT 27 CLOSED

I don't get the issue. So export is fine, the issue is only visible in darkroom? Then we need the -d pipe output while opening in dr. Maybe also --dump-pipe diffuse. Can you see the issue with 'toggle high quality processing' = on ?

For me (OP) the problem is in the export not in the visualization in dt. Also, please find attached the two log files obtained with with "darktable -d opencl -d pipe" (and, yes, "local contrast" of the DoS module was enabled).

thanks for looking into this

new_log_fuji_raf.log
new_log_ricoh_dng.txt

from darktable.

Can you share the RAWs + XMPs so I can try to reproduce on my Intel Mac.

from darktable.

Well, it seems that I can't just attach raw files (or even their xmp) here...

from darktable.

you can put them on a file sharing service and provide the url here.

from darktable.

could you suggest one? I normally use WeTransfer, but the link is sent automatically to an email address

from darktable.

why don't you have the link sent to you and then copy/post it here

there is also google drive and many others. google can provide a list.

from darktable.

We would likely want a first check, are issues related to CL compiler optimizing flag?

from darktable.

Ok, so here's a WeTransfer link to download the files:

https://wetransfer.com/downloads/2b0e90717e940da0d088c93c53da02e320240228130328/c182137df49c263a8f5e9d93b6bcef5c20240228130344/16dff5?trk=TRN_TDL_01&utm_campaign=TRN_TDL_01&utm_medium=email&utm_source=sendgrid

from darktable.

@gpagnon could you open the darktablerc file, locate the line with '-cl-fast-relaxed-math' and remove that string. Then clear all compiled kernels and restart darktable? (That would mean you don't have the opencl compiler doing some maths optimizations) We had some problems with intel devices some time ago on linux ...

from darktable.

When working with these two files darktable crashes on line 1993 in src/common/darktable.c

from darktable.

from darktable.

1. I tried here with current master on fedore both with gcc and clang compiled and can't reproduce.
2. @gpagnon I looked at your opencl enabled logfiles. In both logs i do not see the diffuse module being processed!. Could you repeat with darktable -d opencl -d pipe, export the files that don't work for you, close darktable and post the logfile?
3. @zisoft could you do that too?

from darktable.

Images exported with the settings described.

First image with log:
dt_1.txt

Second image:
dt_2.txt

from darktable.

with some files (I saw it on a Ricoh GR's DNG file) the exported jpg is just an unrecognizable set of stripes

This is the lighttable full screen preview of image 1:

from darktable.

I don't get the issue. So export is fine, the issue is only visible in darkroom? Then we need the -d pipe output while opening in dr. Maybe also --dump-pipe diffuse. Can you see the issue with 'toggle high quality processing' = on ?

from darktable.

The issue with the stripes is only in lighttable full preview (F).

Opening in darkroom gives this:

And switching 'high quality processing' on:

Log with -d pipe --dump-pipe diffuse:
dt.txt

from darktable.

from darktable.

Again, while exporting the diffuse module does not appear in the pixel pipe being processed.

from darktable.

I am not sure why, I can assure you the diffuse module is active (and its effect is visible within dt):

from darktable.

I think the log problems have been solved lately in master, from my current understanding we might have similar clmem management "problems" like when using the rusticl driver here. There is #16436 pending, could you test again after that has been merged?

from darktable.

Same problem on export with Darktable 4.6.1 + Linux Gentoo + OpenCL (NVdidia GPU + AMD CPU) : disabling local contrast in "Diffuse or Sharpen" module solves the problem

from darktable.

@fcoiffie could you share a logfile with -d opencl -d tiling -d pipe ?

from darktable.

Ok, can reproduce "some issue" on nvidia/fedora - sounds this could be the underlying "relevant thing"

1. reproduce via --conf resourcelevel="notebook" to enforce tiling
2. use "toggle hq processing" = on (to process full data)
3. it's not the specific preset but related to large values of the radii. darkroom canvas stays black

from darktable.

@fcoiffie could you share a logfile with -d opencl -d tiling -d pipe ?

darktable.log.gz

from darktable.

@zisoft @fcoiffie could you recheck this on current master? If still failing please share a -d pipe -d opencl log ...

from darktable.

Looks good! Made several tests now and could not reproduce the issues anymore.

from darktable.

Seems to be fixed in master so closing for now.

from darktable.