DNG files from a X-T3 file have strong purple cast

[Alex-Vasile]

Short description Opening a X-T3 raw file that was converted to DNG will result in an extreme purple color cast.

Steps to reproduce

1. Convert RAF to DNG
2. Open DNG in RawTherapee

Expected behavior Looks identical to the .RAF version.

Additional information

• Using RawTherapee 5.9 (arm native version)
• Using Adobe DNG Converter 14.3.0.1072
• m1 mpb on macOS 13.4.1
• Other raw editors read the file fine

Other useful information:

• Reproducible with https://raw.pixls.us/getfile.php/2783/nice/Fujifilm%20-%20X-T3%20-%2014bit%20compressed%20(3:2).RAF
• Screenshot of opening the DNG in RawTherapee:

[Lawrence37]

The dng is a different resolution which is causing RawTherapee to incorrectly interpret the color filter array pattern. A quick hack is to set the raw crop in the camconst.json like so:

"raw_crop" : [
   { "frame" : [6384, 4182], "crop": [0, 5, 6252, 4176] }, // RAF
   { "frame" : [6240, 4160], "crop": [3, 2, 6237, 4158] } // DNG from ADC
]

A proper solution is to fix the CFA interpretation.

[hedwig2013]

For SONY ARW it is the same IF taken in RAW with lossless compression (S/M/L) only. Images taken with uncompressed RAW works fine without any issues. My camera model is ILCE-7M4. Like @Alex-Vasile I convert ARW into DNG with Adobe DNG Converter too.

Darktable can show and edit without issues. Digikam can show and edit without issues. Other Viewers like IrfanView, XNViewMP and others can show and edit without issues.

Is there a workaround without programming knowledge? I am a photographer.

Adobe DNG Converter: 15.5.0.1595 OS: Windows 10 22H2 RawTherapee: 5.9

Something more I observed. The resolutions are different: SONY ARW uncompressed 7028 x 4688 -> DNG 7040 x 4688 SONY ARW lossless compressed (S) 3504 x 2336 -> DNG 3514 x 2344

[kmilos]

The dng is a different resolution which is causing RawTherapee to incorrectly interpret the color filter array pattern. A quick hack is to set the raw crop in the camconst.json

Why is anything DNG related taken from camconst.json to begin with? DNG is an open spec and all the relevant/minimum image rendering information is self-contained, no?

[Lawrence37]

@hedwig2013 I can't reproduce for the ILCE-7M4 lossless compression. This issue is specifically for X-Trans images. Bayer images work fine, and therefore what you are seeing is caused by something else. Please open a separate issue and provide a sample file.

@kmilos I recall there is some information from certain DNGs that override the values from camconst.json. I do think DNGs not produced in-camera should not use camconst.json, or at least use separate values.

[Entropy512]

I do think DNGs not produced in-camera should not use camconst.json, or at least use separate values.

There's some overriding specific to DNG converter for matrices in https://github.com/Beep6581/RawTherapee/blob/dev/rtengine/dcraw.cc#L10672 - but it looks like there needs to be other overrides too

It would probably have been better to implement a blacklist of "known bad" DNG sources with corrections/overrides for just those. Sadly at this point any knowledge of which SOOC DNGs were actually broken is probably long lost.

[sgotti]

Since there's no reference I'll add here that PR #6833 accidentally fixed also such issue by changing the X-T3 camconst raw_crop to some specific raw sizes (f09612453aa11eb58a131f1c67e9e1af32bef6c9).

@kmilos @Lawrence37 @Entropy512 Obviously the comments about using the DNG raw crop/mask instead of camconst ones and for which kind of dng to do this (all DNGs vs blacklist of bad DNGs vs only Adobe DNG Converted vs ...) are still valid and perhaps e dedicated issue to track this should be opened. Looks like this is a topic that is often remarked here and on the pixls forum.

I already implemented this change but before opening a PR I'd like to know to which kind of dngs to apply this change and how to defines such rules.

[Lawrence37]

I don't have the background to say which dngs to ignore. The code has been there since before I became actively involved. However, I still stand by my opinion that camconst.json should only apply to raw images straight from the camera.