Black picture with flimic rgb

[cryptomilk]

Describe the bug

I've edited a few photos with 'filmic rgb' already. With the latest master 0ae2c5c those pictures are rendered to completely black. Disabling filmic rgb doesn't fix it. If I go in the history stack back to the item before filmic was enabled the first time it works again ...

I'm using OpenCL (AMD ROCm)

@aurelienpierre

[aurelienpierre]

What if you change the chroma preservation mode ?

[cryptomilk]

It stays black if I change the chroma preservation mode.

[cryptomilk]

Reverting 0d01bb0 doesn't fix it.

[aurelienpierre]

what if you move filmic before input profile or after output profile ? That could be related to RGB spaces conversions.

[cryptomilk]

Moving it before input profile works

[cryptomilk]

Moving it after output profile works too!

[cryptomilk]

Do you want the XMP?

[aurelienpierre]

So it's definitely linked to the colour conversion.

If you put filmic back between input and output colour profile, but change the working RGB space (in input profile), does it change anything ? (please try internal RGB spaces like rec2020 and possibly spaces provided by ICC profiles in ~.config/darktable/colorin).

I have 2 bets here:

1. the colour profile from the RGB space is not loaded
2. AMD OpenCL doesn't have built-in dot multiplication support, so it doesn't like the change I have made.

[cryptomilk]

The input profile is the standard color matrix and the working profile is rec2020. Changing doesn't do anything to the image only to the histogram.

[TurboGit]

You may want to check again with master, an OpenCL fix has been put in place.

[flannelhead]

This wasn't fixed for me by #3129 unfortunately. I was also about to report this one.

[cryptomilk]

With master I get now:

/home/asn/workspace/projects/darktable/data/kernels/filmic.cl:231:1: warning: control may reach end of non-void function                                                           
}                                                                                        
^                                                                                        
1 warning generated.

[TurboGit]

@cryptomilk : this hasn't changed so I supposed you already had this warning before.

[TurboGit]

BTW, I cannot reproduce so maybe an iop-order issue. Can you reproduce this with new edits?

[cryptomilk]

data/kernels/filmic.cl:231 should call return 0 for example

[aurelienpierre]

@cryptomilk what if you revert 26341e0 ?

[aurelienpierre]

@flannelhead what GPU do you run ? AMD as well ?

[flannelhead]

I have Intel UHD 620, using the Intel Compute Runtime OpenCL driver on Arch Linux.

[cryptomilk]

@TurboGit

data/kernels/filmic.cl:229:14: warning: double precision constant requires cl_khr_fp64, casting to single precision
      return 0.0;                                                                                                                                                                  
             ^                                                                                                                                                                     
1 warning generated.

Reverting 26341e0 doesn't fix it. I still get a black image ...

[cryptomilk]

@TurboGit it needs to be: return 0.0f

[TurboGit]

Fixed. Thanks.

[cryptomilk]

We can do a debugging session tomorrow if someone is interested ... :-)

[aurelienpierre]

I'm able to reproduce on Intel OpenCL, which is weird because I developed with it.

[aurelienpierre]

Ok, issues don't affect colorbalance, so the changes done in colorspace.cl can be discarded from the possible culprits.

Putting any native Lab module (tone curve, levels…) in the RGB parts of the pipe works properly, so the RGB -> Lab -> RGB path works.

Putting any native RGB module (filmic, channel mixer) in the Lab parts of the pipe breaks, so the Lab -> RGB -> Lab path is failing.

Nvidia OpenCL is fine in all cases though.

[cryptomilk]

Fun fact: the preview renders correctly :-)

[flannelhead]

@cryptomilk: do you mean the low-resolution view before the full-res image is rendered (pardon my ignorance, not yet familiar with darktable lingo)? If yes, that's the case for me as well. There are indeed interesting lines in darktable debug log if started with darktable -d opencl:

2,373503 [pixelpipe_process] [thumbnail] using device 0
3,933719 [pixelpipe_process] [full] using device 0
4,695126 [pixelpipe_process] [preview] using device -1

The preview seems to use a different device id. -1 means no OpenCL, I guess.

Edit: Consistently with the above, the thumbnail is rendered black for me as well.

[flannelhead]

Also something else that happens on my system: only with chroma preservation = no, the image is rendered black - in all the three chroma-preserving modes, it is light gray.

[aurelienpierre]

Previews usually use C SSE2 code path, unless you set the OpenCL perf profile to "very fast GPU".

I think we are dealing with low-level issues on memory allocation done differently between GPU vendors. I will keep investigating.

[cryptomilk]

I've changed

opencl_memory_requirement=1024

to

opencl_memory_requirement=2048

and it seems to work now!

[cryptomilk]

I don't now if this needs to be a multiple of 2. But setting it to 2047, I get a black picture.

[parafin]

I think increasing opencl_memory_requirement can only have one effect - disabling OpenCL in darktable.

[cryptomilk]

@parafin can you explain in more detail? The GPU has 8GB of memory.

[cryptomilk]

@parafin Ok, you're right -> 0.297747 [opencl_init] discarding device 0 gfx803 due to insufficient global memory (8192MB).

Sorry for the noise.

[aurelienpierre]

@cryptomilk could you checkout on a48ea3e, run on OpenCL, enable the channel mixer module, ensure it is between input and output profile, and report if the image is still black ?

On Intel Neo drivers, I get the same error (black picture) prior the commits introducing Filmic RGB OpenCL and other OpenCL colour space conversions optimizations, so it seems that this bug was there for a longer time.

[cryptomilk]

@aurelienpierre Checking out a48ea3e, everything works just fine. The picture is rendered correctly, even if I enable the channel mixer.

[flannelhead]

Works for me since the merge of #3189 :)

[cryptomilk]

This has been fixed with #3189

[kanyck]

I still have it on 3.1.0+8~g7871a4f25-dirty.

FilmicRGB with color preservation set to RGB (norm) plus Local Contrast enabled caused black field instead of image. Disabling LC causes washed out colors (HDR-style looking), after few manipulation it gets to normal. Disabling OpenCL seems to fix it.

Steps to reproduce the behavior (darkroom mode):

1. Enable Filmic RGB
2. Set color preservation to RGB (norm)
3. Enable Local Contrast in default mode (laplacian)
4. Enjoy pure black

Platform

• OS: [Gentoo linux]
• Version GIT [3.1.0+8~g7871a4f25-dirty]
• OpenCL activated
• Radeon RX470 Ellesmere + amdgpu + OpenCL blob from amdgpu-pro