dcraw: add Panasonic DC-G9M2

[sgotti]

dcraw: add Panasonic DC-G9M2 to adobe_coeff

Depends on v8 decoder provided by #7018

Tested images

• Tested normal images.
• Tested in-camera pixelshift high resolution images

[Naastek]

hi boss~ i want to know when this will release? when i use g9m2 raw on 5.10, it's all black and i don't know how to make dmg from zero XD

[Lawrence37]

@Naastek This will probably be included in 5.11. There is no set release date, but I'm going to guess early in the second half of this year. Until then, you can have a look at Adobe DNG Converter or a FOSS DNG converter (I think it was https://github.com/dnglab/dnglab). You could also try the pre-dev build for this if you are on Windows or Linux. See https://discuss.pixls.us/t/rawtherapee-pre-dev/35595. Once this gets merged into the development version, you can start using the development builds.

[Naastek]

@Lawrence37 thanks for your info. unfortunately i work with macOS can't get access to pre-dev. maybe i will wait for the dev builds.

[Lawrence37]

We should see why the decoder does not have the white level for this camera.

[sgotti]

The issue is in dcraw.cc DCraw::adobe_coeff. There's an entry for a Panasonic DC-G9 camera and this function uses a prefix so it matches also Panasonic DC-G9M2.

RawTherapee/rtengine/dcraw.cc

Lines 8892 to 8893 in 5a25619

	{ "Panasonic DC-G9", 15, 0xfff,
	{ 7685,-2375,-634,-3687,11700,2249,-748,1546,5111 } },

But this camera has more detailed information provided in camconst so this entry could just be removed from dcraw:adobe_coeffs since it's overridden by camconst entries. This will also fix this issue.

@Lawrence37 Is it ok for you? Should I create a new PR or a new commit in this PR to remove this entry from DCraw::adobe_coeff?

[Lawrence37]

I prefer to keep the dcraw value there because the decoder should provide a reasonable white level in the absence of a camconst entry. We should add the DC-G9M2 values from Libraw:
https://github.com/LibRaw/LibRaw/blob/158e635e5e80a95dfa402b0a79a7167922c1d4ec/src/tables/colordata.cpp#L1367-L1371

Edit: It also provides the color matrix, so a camconst entry would not be needed at all.

[sgotti]

@Lawrence37 I you think it'll be better I'll do this but I'm quite confused why adobe_coeffs is better than camconst in this scenario. I thought camconst was the new rawtherapee way to handle camera properties and adobe_coeffs the old dcraw way before camconst were introduced (I also thought that adobe_coeffs table could be removed and migrated to camconst but I may have lost something).

[kmilos]

I guess if RT is to switch over to LibRaw, it'll have its own adobe_coeff table as well, so indeed no need to duplicate in camconst...

[Lawrence37]

One is not necessarily better than the other. They serve different purposes. adobe_coeff provides constants straight out of the decoder. camconst.json is for overriding, fine-tuning, or supplementing the decoder's values. It's like coding style. There's no difference for the user, but it improves maintainability for developers.

[sgotti]

@Lawrence37 Updated the PR to update the dcraw adobe_coeffs table instead of a camconst entry.

I prefer to keep the dcraw value there because the decoder should provide a reasonable white level in the absence of a camconst entry.

FWIW The white level is not provided by adobe_coeffs (the entry is 0 so ignored) but calculated from tiff_bps (16 in this case):

RawTherapee/rtengine/dcraw.cc

Line 10720 in 5a25619

maximum = ((uint64_t)1 << tiff_bps) - 1; // use uint64_t to avoid overflow if tiff_bps == 32