Converting plain RAW from imback to DNG

I would say that it is, yes. Not having correct WB makes editing much harder, and presumably most shoot raw because they want to edit.

1 Like

One more question that would definitively get me going n the end is this : in the end, will users of other raw processors be able to make use of the results by embedding into the DNG or would there be a not so small remainder of programmes where only a rebuild or reconfiguration of the programme itself will make the thing fully usable?

Thanks :pray: to all of the community here for the answers so far! I should have been gone to ask here earlier.

1 Like

The whole point of DNG (with all the proper tags) is that no special support or processing is needed in a raw editor.

2 Likes

Wellllll, not from Adobe’s point of view. The DNG specification promotes a whole 'nuther processing approach, from the dual-illuminant colormatrix tags to the ā€œlookā€ LUTs. Yeah, you can open DNGs with most raw processors and get close to the original raw data, but the software sometimes has to do DNG-specific things to get the data it needs to do it’s ā€œconventionalā€ processing. I see this in rawproc, which opens DNGs nicely thanks to libraw, but I still haven’t mitigated all the gotchas to make using the data seamless.

1 Like

While it’s true some of the more ā€œadvancedā€ DNG features can have spotty support across multiple processors, many of those features really only apply to fixed-lens cameras or ILCs that support DNG (rare - Pentax used to support DNG but not sure about now?) and embed lens correction metadata in their DNG.

The basic color metadata is widely supported by most software, including 2.5D LUTs as generated by dcamprof. If Adobe Lightroom/ACR compatibility is desired, embedding a tone curve may be a good idea. On the other hand a tone curve and LookTable (such as dcamprof’s NTRO) increases file size significantly - DCP profile size inflated with redundant data Ā· Issue #6467 Ā· Beep6581/RawTherapee Ā· GitHub

1 Like

okay, thanks. I could have an options for that in the converter so that who needs it can get it and who doesn’t can save the space. My target would be to get it really complete if at all.

Can’t you just use one of the Lightroom built-in curves? Or does embedding a custom curve do something other than giving the user the desired camera brand ā€œlookā€?

So my experience with Lightroom is mostly limited to what other people have described (I don’t use it, and I’m most definitely not paying for it), but it sounds like LR always uses the embedded tone curve of a DCP and makes it nearly impossible to replace it (or even know it’s there/what it is) - any additional curves in LR sound like they are on top of the tone curve in the DCP.

This behavior is the source of all of the rants about ā€œbad Sony colorsā€, etc. over on DPReview - it’s always bad profiles bundled with Lightroom that attempt to match camera behavior.

Of course if you have LR you can definitely do some experiments here that would be useful! I have made a profile that was usable in LR before with the assistance of another user (for the Xiaomi Mi Sphere 360 which has a completely broken profile in its data), but as I said, I can’t really experiment myself and I’m definitely not paying for it.

Edit: This only applies to DCP profiles, but LR can be picky about some of the metadata when it comes to matching a DCP to the appropriate camera. I forget the details - RT only cares about the filename. BTW that’s another possible solution for your users’ use case - have a ā€œsemi-compactā€ embedded profile (color matrices, 2.5D HueSatMap) in the DNG, and offer a DCP profile with tone curve/NTRO/etc.

1 Like

So, to complete this topic… I got an IT8.7 Wolf Faust CF target and did as written in numerous places, and now everything should be inside the DNG and at least darktable seems to make use of it, I am happy. What do you think, any comments ?
2023_05_18-07_58_19.dng (15.7 MB)

colours seem credible now:

i really love the quality of the lens here, how the image disappears with depth and at the edges of the image really gives you a sense of the scene in 3D. the sensor seems to be a bit noisy though.

how did you get the HueSatMap and the more esoteric metadata into the dng? did you verify it makes sense? the image above only uses the matrix, when i attempt to use both matrices and the luts in the dng i get completely broken results (but it might be me).

1 Like

@hanatos Thanks for your feedback! I created the DCP using argyll-scanin/dcamprof … (even found a tungsten lamp deep in the stack), and it contains exactly the tags as documented for the DNG format (but in a slightly different container), so they are simply copied into the DNG. I can not exactly verify it except with darktable and rawtherapee and have not found a way to ā€œbreakā€ it, could you describe how you did it?

BTW the original profile is also here for download.

do you know how close is your tungsten lamp to illuminant A? i was trying to estimate a spectral input device transform from your data (via vkdt mkssf, but it seems the A ColorMatrix is causing the optimiser some headache. i mean compare this output for Nikon D7000 (using the adobe neutral dcp)

to this for the imback dcp you linked:

this also persists when i disable the HueSatMap and only use the two matrices as base. the D65 matrix alone looks ā€œgoodā€ (see image above).

this is what it looks like when i ignore the A matrix during optimisation:

1 Like

Hmmm, not really, I was glad I had found one at all, 40 Watt, old but clear. Exposure was 10 seconds, and I did flatfield correction with a plain white (back of the target) sample because it obviously was not evenly illuminated but no glare. Plus, I gave the argyll-scanin the corner coordinates to make localization easier (the IT8.7 targets are a bit harder with this) and on profile creation choose GS7 or something around that as neutral patch (one of the not so bright ones of the grayscale neutral wedge below). I am out of ideas about what could have gone wrong…

I think I understand what you mean. Though it seems not so easy to get the vkdt running here, the debug report output from dcamprof indicates similar things, so I think I have a place where I can look at to see if it improves. I might take all the calibrations shots once more to optimize… Thank you @hanatos