AfterShot Pro 3 generating artifacts with OpenCL GPU use?

Question

I discovered an artifact on a shot when I printed a large blowup of a tight crop. Initially I thought, "Oh no, I have a camera problem!" Further experimenting demonstrated that the artifacts are generated when exporting raw to JPG with OpenCL enabled to use my Nvidia GPU. Exporting with OpenCl disabled did not generate the artifact.

I'm running Linux and have not tried this on Windows.

I put both "with" and "without" OpenCL JPGs in GIMP layers and did a "Difference" of the two layers. The artifacts turned out to be more extensive than I initially saw and manifest as several rectangular block discontinuities.

I tried the samething in Darktable and got exactly what one would hope to get, a black "Difference" as the images were identical.

AfterShot has small brightness differences with OpenCL hardware acceleration that's small enough to live with, but the block artifacts are unacceptable.

Has anyone else encountered this problem?

I'm running the latest Nvidia drivers on an arguably old GPU, but that should only be a speed issue.

The CPU only, GPU OpenCL, Difference images can be seen at:

AfterShot Pro 3 GPU generated Artifacts

Bouncing back and forth between the two main images allows you to see the artifact shift points. The most obvious one is a perfectly horizontal thin line through the cat's forehead.

My immediate question is regarding Aftershot Pro 3 on Linux, but I'm now curious as to a more extensive "Difference" check across many platforms and RAW editors that support using GPUs.

             ---- Edit ----

I've identified the specifics of the problem!

There are 4 OpenCL utilization settings: Minimum, Low, Standard, High. And of course NONE if OpenCL is disabled.

Comparing the output of the 4 settings to NONE as the reference standard shows:

All 4 OpenCL settings shift the output image by 2 pixels in both X & Y.

Only the "Minimum" setting generates artifacts that appear as rectangular areas that "Do Not Shift by 2 pixels".

I think that this is the essence of the problem. The OpenCL processing has a 2 pixel offset in both X & Y. As long as all of the image is processed by the GPU, it's self consistent. If part of the image is processed by the CPU, then there are 2 pixel shift boundaries between the CPU and GPU processed parts of the image.

It's likely that this may occur at any setting or not at all, depending upon CPU and GPU speeds.

It's possible that it's the CPU calculation that has the 2 pixel shift, but the key is that they are different!

             ---- Edit 2 ----

I compared an uncropped image on both "Aftershot" and "Darktable" for alignment in order to attempt to identify which 2-pixel shift is in error.

"Darktable CPU", "Darktable OpenCL", and "AfterShot CPU" all align!

"AfterShot OpenCL" has a 2-pixel shift in X & Y.

Answer 1

This is a bug in Corel's implementation of OpenCL Hardware GPU usage.

The underlying problem is that Corel's OpenCL implementation shifts the exported layout by 2-pixels (approximately) in X & Y compared to other RAW to JPG (TIF too) conversions. Shooting RAW + JPG in-camera and comparing to Corel's export of the RAW to the camera JPG confirms that it is only Corel Aftershot OpenCL that produces this shift. Aftershot using only CPU export matches the camera JPG, as does all Darktable exports.

So why does a mere 2-pixel shift matter?

First and foremost it creates artifacts in any image that has pieces created with and without OpenCL, this is what caught my attention in the first place. In my testing this occurred only on the "Minimum" OpenCL setting. However this may not remain true with a different GPU/CPU mix.

Somewhat theoretically, Corel OpenCL misalignment would cause problems with attempts to use images processed from multiple raw converters. While this is an unlikely use in most cases, it impacts attempts to use both Raw & JPG images if you try to overlay them.

I've contacted Corel concerning this issue.