Whenever I open dng files on RT, it recognizes it and applies the dcp profile properly.
But after opening the same file next time (without any modification to file), it does not recognize embedded dcp and colors look awkward. It happens on all dng files from my phone.
The dng files always work properly on adobe lightroom classic.
OS: Arch Linux
dng source: MIUI camera app
RT version: 5.8
Please provide an example DNG.
It looks like it doesn’t open it properly all the time. Sorry for confusing desription. Both lightroom and darktable have the same issue.
edit: Both darktable and rawtherapee have same problem. works fine in lightroom.
The lens shading map is probably not the issue, it would have some effect on color but it wouldn’t be too significant.
I have been experimenting with a workaround that applies the GainMap to a dng file before editing, so that the editor doesn’t need to support GainMap. If you post the dng I can run it on that file and you can see if it looks any better than the original in Darktable. I would assume that Lightroom already has support for the GainMap.
Yup. We can only guess what the problem is without an example DNG. I agree with you that the GainMap is probably not the issue at least based on what the OP is describing. But I’ve never seen the issue myself even with mobile DNGs from a Pixel 4 XL.
The only other explanation I can think of is that the embedded color profile IS being recognized, but is broken, so as soon as RT switches from displaying the embedded JPEG preview to something dervied from the raw data and color profile, the thumbnail changes and looks wrong. This I HAVE seen with both Mi Sphere DNGs and “Day Zero” Pixel 4 DNGs, both of which are examples where the embedded color profile is just plain wrong. It’s not a RawTherapee bug, it’s a camera bug.
Again, we need an example DNG to diagnose/analyze this issue.
IMG_20210512_120109.7z (10.1 MB)
It works fine on lightroom, snapseed & google photos but not on dt and rt.
Color profile seems to look fine, although since the picture is mostly white some of the more obvious negative impacts of a bad DCP aren’t readily apparent.
Definitely needs flatfield correction/lens shading correction.
Actually in this case - the GainMap IS a contributor here.
I’m not seeing any difference between the first opening and later ones, but if you are referring to the color shifting between center and edge as the issue - that’s lens shading.
It looks like the lens shading really is the issue here. The effect is stronger for your phone’s camera then it is for my Pixel 4a.
This copy of the dng has had the lens shading correction applied, and should work in dt or rt. I made it with the script described in this post. IMG_20210512_120109_pp.dng (22.0 MB)
Currently the only open source raw processor that can apply the lens shading correction internally is ART. It has to be enabled manually - in the Raw tab enable Flat-Field and select “Embedded in metadata”.
This plot shows what the lens shading map for each color looks like for your image:
The plot in the lower right shows the gain for the R G and B channels along a diagonal line drawn from one corner of the image to the other. In the center R = G = B, but at the edges R > G and R > B, which explains why the image has a blue-green color cast when the correction is not applied.
In the Raw tab enable Flat-Field and select “Embedded in metadata”.
Thanks. It works.
Andy sounds like you have a pixel phone. It was confirmed when I asked on another thread about dng files saved when the shot is taken with zoom. This is a digital crop for the jpg but the dng saved should be full frame. Currently my pixel 3aXL is now saving these tiny low res DNG files that seem to match the jpg crop determined by the zoom when the shot was taken. This did not seem to be the case in the past…any experience on your end??
For as long as I can remember (and the difference may be that the 4XL launched with multiframe superresolution support), it seems like the DNGs are created using the old tiled align-and-merge pipeline and not the new MFSR one.
Some previous articles on DPReview claimed that Google was remosaicing the results of MFSR for compatibility - but if they were actually doing that, we wouldn’t be getting a crippled crop.
Sadly, DNG output from the Pixel 4 is substandard compared to the JPEGs thanks to this crippling. 
It’s one case where Apple did a MUCH better job. Rather than say “Well some software can’t handle demosaiced DNGs, let’s cripple our implementation for compatibility” they said “This feature is important enough that any software which lacks support just needs to be updated.”
Honestly, I’m aware of almost nothing that doesn’t actually support demosaiced “linear DNG” files. (Which, as I think I’ve mentioned elsewhere, aren’t always actually linear! But nonlinear DNGs are quite rare)
Thanks for your feedback. I guess if they are crappy they are crappy I just can’t understand why they are cropped. To me its pointless to even save a raw file at all from a pixel if using zoom leads to a “mini” dng……
Maybe in the future Motioncam will be a solution to some of these issues. It’s an open source app which shoots a burst of raw images, aligns and stacks them, similarly to Google Camera.
As of today it does not support zooming at all and I don’t know if it’s intended to ever support zooming. Like Google Camera it outputs a mosaiced dng. But since it is capturing and aligning a stack of images, maybe it could be modified to either run a MFSR algorithm internally, or just save the entire stack of images to be processed later on a PC with MFSR.
