Hi
I import image into DT 4.6.0 and see these artefacts on high contrast edge.
the raw image in Camera, Canon R5, does not show them and when opened with Canon DPP4 it also does not show any artefacts
both images are imports with no processing at 100%
Would you mind uploading the raw file?
_MGC9382.CR3 (32.6 MB)
I think itâs the file. I get the same jagged effect when loading it into darktable 4.6, RawTherapee dev and ART 1.21.17 (other CR3s load cleanly). DPP shows it without the jaggies so it must be doing something to âfixâ it. The JPG thumbnail is in AdobeRGB color space, but that should have no bearing on it and I donât see anything strange.
So basically the same thing youâre seeing, but itâs not just darktable.
As expected, no problem in Adobe Lightroom. It just works. Great detail too.
This is at default import at 100% (no changes in LR):
No problem with darktable 4.4.1 that I still use or RawTherapee that I use.
I converted to dng in Adobe DNG Converter. Looks fine in darktable 4.4 and Ubuntu 22.04.
But I got this in RawTherapee with demosaicing method IGV
Has been discussed github. Currently libraw doesnât support some compressed cr3 format.
Thatâs a bug during inverse quantization for CRAW compressed CR3s. As there are no overflow checks in Libraw code, the decoded image is corrupt. Iâve tried to convert the file with dnglab and hit an shl-overflow.
thread âdnglab-tokio-workerâ panicked at rawler/src/decompressors/crx/iquant.rs:143:46:
attempt to shift left with overflow
That needâs some investigation 
Can you point me to the discussion, please?
Nice you are stepping in here âŠ
Do you have more shots from same scene with idendical problems?
If this is the only file, I assume the file itself is corrupt. There are no checksums in CR3. If image data has some corrupt bytes, decompressed output may have artifacts like your DT screenshot.
I belive Canon and Adobe (which uses CRX decoder from Canon) has a recovery routine for such corruptions. If I filter out the invalid quantization values and assume 1, the image in DT looks âokayâ:
Yes I have a couple more shots taken at the same time that show these errors.
I not an expert with Dark Table
I am using a windows executable build of 4.6.0 on a windows 11 laptop
Could it be high ISO (noise) error? The highlight areas have lower resolution than the darker areas (feathers)
Thx for your input 
â If I filter out the invalid quantization values and assume 1, the image in DT looks âokayâ:
Is that something I can apply in DT ?
Iâve suggested a fix at libraw Potential problem with compressed high ISO CR3 · Issue #624 · LibRaw/LibRaw · GitHub
For now, Iâll implement the same fix in dnglab.
@Jens-Hanno_Schwalm There is no issue with âunsupported compression formatsâ. There is simply a glitch during IQ. I assume that darktable has changed some compiler-flags or OP is using a build from a compiler where the shift result is 0 instead of 1.
Edit: That explains why users like @Peter donât hit the bug. It just depend on CPU/compiler/flags/whatever.
My darktable source for 4.4.1 was Install package graphics:darktable / darktable
Also the pictures from here looked good CR3 compressed RAW files at least not supported for EOS R6 Mark II in LibRaw · Issue #15955 · darktable-org/darktable · GitHub
Could the difference be caused by OpenCL on vs off?
I never tried to turn off OpenCL on my desktop 4.4.1. I only changed big resources to small or what it is called.
My laptop with 4.6 on the other hand doesnât have OpenCL.
I also turned on/off performance before IQ with 4.4.1 desktop.
I exported to TIFF with my 4.4.1 desktop without issues.
FYI, thatâs the better part of two years old. I got the same issues in the current ART.
