Rawtherapee: RT 5.4 RC DNG support regression with some Sony ARW files

[cuniek]

Hello

I have noticed that dng files (converted using Adobe DNG Converter 10.2) are properly displayed in RT 5.3 but 5.4 RC2 and RC3 are heavily overexposing them (I mean that RAW histogram is shifted about +2.2 eV). The strange thing here is that this happens only to files from Sony alpha 580, and not Nikon D750 or Minolta 7D. I attach original ARW file and DNG file.

https://drive.google.com/open?id=1vtnxvAdETjwjcLddoJCskh3aeXb_qg3Q
https://drive.google.com/open?id=1Zwe2yjgGJiQaYXUyPlSfENh-il6lKniA

Win 7, 64 bits.

[heckflosse]

Maybe related to #4129 ?
@agriggio Do you have an idea?

[heckflosse]

Loading Sony DSLR-A580 image from _DSC5638.dng...
no constants in camconst.json exists for "Sony DSLR-A580" (relying only on dcraw defaults)
black levels: R:0 G1:0 B:0 G2:0 (provided by dcraw)
white levels: R:4075 G1:4075 B:4075 G2:4075 (provided by dcraw)

Loading Sony DSLR-A580 image from _DSC5638.ARW...
no constants in camconst.json exists for "Sony DSLR-A580" (relying only on dcraw defaults)
black levels: R:512 G1:512 B:512 G2:512 (provided by dcraw)
white levels: R:16300 G1:16300 B:16300 G2:16300 (provided by dcraw)

[heckflosse]

This patch should fix the issue:

diff --git a/rtengine/dcraw.cc b/rtengine/dcraw.cc
index dfde7878..871fcf7c 100644
--- a/rtengine/dcraw.cc
+++ b/rtengine/dcraw.cc
@@ -8302,13 +8302,13 @@ void CLASS adobe_coeff (const char *make, const char *model)
    { 6038,-1484,-579,-9145,16746,2512,-875,746,7218 } },
     { "Sony DSLR-A390", 0, 0,
    { 6038,-1484,-579,-9145,16746,2512,-875,746,7218 } },
-    { "Sony DSLR-A450", 0, 0xfeb,
+    { "Sony DSLR-A450", 0, 0,
    { 4950,-580,-103,-5228,12542,3029,-709,1435,7371 } },
-    { "Sony DSLR-A580", 0, 0xfeb,
+    { "Sony DSLR-A580", 0, 0,
    { 5932,-1492,-411,-4813,12285,2856,-741,1524,6739 } },
-    { "Sony DSLR-A500", 0, 0xfeb,
+    { "Sony DSLR-A500", 0, 0,
    { 6046,-1127,-278,-5574,13076,2786,-691,1419,7625 } },
-    { "Sony DSLR-A5", 0, 0xfeb,
+    { "Sony DSLR-A5", 0, 0,
    { 4950,-580,-103,-5228,12542,3029,-709,1435,7371 } },
     { "Sony DSLR-A700", 0, 0,
    { 5775,-805,-359,-8574,16295,2391,-1943,2341,7249 } },

Background: For all the cameras in the patch, using arw format overrides the whitelevel set in adobe_coeff(), but not when using dng format. The white level for this cameras in adobe_coeff is from old times, where the data was not in 14 bit range internally, so it's better to set it to 0, which means the white level from dng file will be used if there is no camconst.json entry for the camera.

[Beep6581]

Perhaps related:
I was examining SONY ILCE-7M3 files today and found that some files (taken in compressed mode) show BitsPerSample=14 in their Exif while the max white level is only 12-bit. The files have a raw curve which is supposed to scale the data to 14-bit.

The ARW file linked above shows:

BitsPerSample=12
SonyRawFileType=Sony Compressed RAW
WhiteLevel=15360 15360 15360

Max white level is 3218 without using the raw curve.

The DNG:

BitsPerSample=16
WhiteLevel=16300

[heckflosse]

@Beep6581 The issue is related to this line
https://github.com/Beep6581/RawTherapee/blob/dev/rtengine/dcraw.cc#L3278
As we don't scale down to 12 bits, we also have to use a white level which matches 14 bit precision.
This is guaranteed for arw files in code, but not for dng files produced from arw files.

[cuniek]

I remember that A580 is processing with 14 bit precision internally, but saves only 12 bit raws (with the curve). Supprting the curve makes a BIG difference in quality - easily visible on real life photos.

BTW
Current white level for A580 is wrong, and highlights are pinkish. It is gone when I set White Point Correction to 1.03.

[Beep6581]

Supprting the curve makes a BIG difference in quality - easily visible on real life photos.

@cuniek how do you test that?

Current white level for A580 is wrong

Could you upload some white-frames?
Also ping @iliasg

[agriggio]

Shouldn't we kill adobe_coeff entirely and move the data to camconst instead?

[iliasg]

@agriggio

Shouldn't we kill adobe_coeff entirely and move the data to camconst instead?

Alberto, we cannot do that at the moment because some times the DNG data are different (different raw frame, different BL/WL) .. sometimes dramatically so (see MagicLantern video DNGs)
We need to expand camconst features to cover multiple frames and multiple versions (nativeRAW vs AdobeDNG vs 3rt party DNG ..) but even then we cannot know how a 3rd_party DNG conversion could have manipulated the data ...

[iliasg]

@heckflosse Ingo, the DNG tags are fine (BL=512, WL=16300) .. and I don't see "adobe_coeff" for a580 .. how came RT to decide not to use the DNG exif ?.

[agriggio]

@iliasg there was a recent modification to the logic, due to #4129.
Basically, the idea was to make the DNG and the original RAW give the same output. However, from your comment above I understand that it might not always be possible, so I agree that this should be revised at some point...

[iliasg]

@agriggio Alberto, I thought that #4129 only disabled the inclusion of the DNG calibration matrix in calculations .. this would be enough to match DNG and "any_native_raw" renderings

[agriggio]

@iliasg let me double check

[agriggio]

I thought that #4129 only disabled the inclusion of the DNG calibration matrix in calculations

@iliasg yes, that is correct. Then it must be something else -- sorry for the noise!

[heckflosse]

@iliasg

and I don't see "adobe_coeff" for a580 ..

It's here

[iliasg]

@heckflosse
Ingo, wrong phrasing from me .. I mean that I didn't find in dcraw.cc the line in which RT turns from DNG exif to adobe_coeff for "Sony A-580" DNGs
Although I think it's in Alberto's #4129 commit ..

[agriggio]

@iliasg this line. And you're right, before my commit the behaviour was different. But that's exactly what the commit was supposed to do, no? I.e. reading the matrix from adobe_coeff in both cases (ARW and DNG) makes sure that the matrices are the same. So I think the problem is the wrong white level, as Ingo found out above. Do you agree?

[heckflosse]

@iliasg it's this line
raw_color defaults to 1 and is not set to zero here, because the dng is from adobe dng converter, which is checked here. So it's still 1 and adobe_coeff() is called.

Edit: Alberto was faster

[iliasg]

@heckflosse @agriggio
Guys sorry for the late responce,
The 0xfeb (4075 dec) is not a wrong WL it's a correct WL for 12bit data .. which for ARW's after the bitshift removal (i.e 14bit data) it gets a hardcoded 4x value (16300) https://github.com/Beep6581/RawTherapee/blob/aef02c0c6175f62cbeefeaae293645f2307b9e87/rtengine/dcraw.cc#L3286
The DNGs also have this correct WL=16300 in exif.

What exactly means "the adobe_coeff() is called ? that all adobe_coeff() data (color matrix, BL, WL) are used instead of DNGs exif ?.
I think the intention of #4129 should be

• when no camconst data exist .. only use the color_matrix from Dcraw.cc (for consistency) because most times DNG's BL/WL are more reliable than the (single for all ISOs) Dcraw.cc BL/WL .. a slight difference in brightness is preferable than the pink highlights
• when camconst data exist, in most cases the BL/WL data are more reliable than DNG's exif (see Pentax in camera DNG's which report WL after BL subtraction) and should be used in preference .. but I think this is not always safe .. sometimes the DNG data are different .. for example the BL value is already subtracted .. :( .. I cannot remember at the moment if this happens on adobe's DNG conversions or only 3rd party
• ideally we should have the option the set priority on camconst or DNG exif or Dcraw.cc's adobe_coeff for each one of matrix, BL/WL .. depending on each model ..

It is a mess I think .. a 4th place with same data is rawimage.cc i.e. the adobe_coeff overrides .. it's the first than needs cleanup since most models are already in camconst.json

[heckflosse]

@iliasg Ilias,
Currently it's this way for dng:

If the dng is from Adobe dng converter: white levels and black levels from adobe_coeff() will be used if:
1) there are not zero
2) there are no camonst values (camconst have priority over adobe_coeff())

[agriggio]

@iliasg no objection to improve the logic from me, but I think we should add a hot fix for 5.4 and postpone more complex / principled solutions until after the release

[heckflosse]

@agriggio @iliasg I already pushed the hot fix for the Sony arw2 cams

[Beep6581]

ideally we should have the option the set priority on camconst or DNG exif or Dcraw.cc's adobe_coeff for each one of matrix, BL/WL .. depending on each model

Factor in that dcraw appears to be abandoned, no reply from Dave Coffin, and we may need to switch to rawspeed or libraw.