Incorrect DNG loading/processing

Hello,

I’m trying to process a custom-made DNG file, that was created using pydng (GitHub - schoolpost/PyDNG: Create Adobe DNG RAW files using Python. Works with any Bayer RAW Data including native support for Raspberry Pi cameras.). The file created by this project seems to partially comply with the DNG format, which causes some issues with RawTherapee, yet surprisingly not so with other (simpler) image viewers.

For example, this is via faststone viewer:
color_faststoneviewer_rescaled

and via https://raw.pics.io/app:
color_raw-pics-io

On the other hand, RawTherapee shows this DNG very weirdly (using AMaZE demosaic):
color-AMaZE_downscaled

This is a comparison of the non-demosaiced image from RT (top), next to a correct conversion (bottom; via faststone)

Here you can see something strange: some of the pixels seem to show correct levels (look at the top-most part of the letter “S”, or the top half of the dot in the lower-left corner), whereas most pixel seem to undergo some kind of underflow, and appear to get saturated.

I’m aware that this not a fully-compliant file, yet several (simpler) applications appear to process it correctly.

What is going on?

Thanks,
Itay

attachment: DNG file: color.dng (6.1 MB)

RT uses this white levels for your file:

white levels: R:902 G1:902 B:902 G2:902 (provided by dcraw)

What range are the raw values in?

Hi Ingo,
I can’t say for sure, as I don’t have any way to directly read the file (any utility recommendations?).
I would guess that it’s only 8 bit, as the DNG was created from a jpg source (specifically: https://github.com/schoolpost/pydng/blob/master/color.jpg).

Hi guys,
I’m wondering if anyone has any idea.

Apart from checking that the raw pixel values are indeed in an 8 bit range only (unsigned), I’ve also noticed that in RT most of the ‘problematic’ pixels are indeed underflowing, with values of 65530, for example.

My wild guess would be that this is due to some mistuned metadata (such as color matrix, white/black points, etc.), as that could explain why the “simple” DNG viewers (FastStone, FastRawViewer, etc.) are able to process it correctly, by probably disregarding a certain parameter in the processing stage.

Thanks. (-:

image

Thanks.