Embedding profiles into DNGs

DavidB

40

« on: 08 / September / 2010, 05:13:33 »

Advertisements

I've developed a set of patches for CHDK which provide a major upgrade from the current simple color matrix support which is used by RAW processing software to guide how the RAW file is mapped into real-world colors. I'm hoping for some discussion with both CHDK developers, and users of RAW processing as to a couple of options.

Background: DNG v1.0 introduced color matrices, while DNG v1.2 introduced the concept of a "DNG profile" (which can be a "dual-illuminant" profile valid for a huge range of lighting). The current DNG standard is 1.3.
DNG profiles can be installed onto your computer and used by Adobe software (I must admit I'm not aware of profile support in other software) with the DNG v1.1 files currently produced by CHDK. Quite a few people have been doing this already (and I've recently created a Wiki page to allow people to share profiles.

When working on a file in Lightroom/CameraRaw, the user can currently select from "Embedded" (essentially the color matrix embedded by CHDK) or any other profiles for this camera on their system. In this example I have a profile on my machine called "D10 generic":

My code works by taking a .dcp file (the binary format of a DNG Profile file) and translating it into C code that is #included into core/dng.c. Thus when we build CHDK for a given camera we can compile a profile into the binary, and this profile will become embedded (merged) into the DNG files produced by the camera. In this case the color matrix currently hard-coded in include/camera.h is ignored, and new matrices are derived automatically from the profile. Then when working on the files in Lightroom/CameraRaw, the psuedo-profile "Embedded" becomes something fancier:

In this case I've called the profile "D10 embedded 20100901". In fact this name is something I'd like some feedback on:

We could just call it "<camera> embedded", but if/when a better embedded profile was created and installed into CHDK, users would have no information about WHICH "<camera> embedded" profile a given image was using. So I believe we should have some form of version number in there.
We could have "<camera> embedded <CHDK-build-version>" but then that would use a lot of different names for the same profile. Not a recipe for simplicity on the user's end.
When the profile is updated, SOME version id should be put into the name. For example "D10 embedded v1". But "v1"? Thus I used a datestamp in my current embedded profile names, but it's a bit long-winded.
Old ACR profile names generally included the ACR revision they were introduced/revised in (e.g. "ACR 2.4", "ACR 4.4") but do we have an appropriate number to put in there seeing as there's no official CHDK "release cycle" as yet?
Maybe "<camera> CHDK <stamp>" (e.g. "D10 CHDK 201009")? Subversion revision numbers (e.g. 938) are a fast-moving target, and might conceivably be reset in a future repository?)

Thoughts?

So that's the first question. The second is regarding where to put these profiles in the CHDK source tree.
During my development I've had them in one "dng_profiles/" folder at the top level, and if dng_profiles/$(PLATFORM).dcp is found it is used. From one point of view it might be good to keep them in one place so we can ensure sensible profile names (including having a README in there) and to facilitate distributing a profiles.zip.
But maybe it would be better to have the profiles somewhere like platform/$(PLATFORM)/profile.dcp ?

Thoughts?

Note that wherever we put the .dcp files, if no matching profile is found during the compile the code reverts to the old(current) behaviour of just taking the color matrix from include/camera.h.

« Last Edit: 08 / September / 2010, 05:19:26 by DavidB »

Logged

DavidB

40

Re: Embedding profiles into DNGs

« Reply #1 on: 08 / September / 2010, 07:19:15 »

Just to be clear, with these new DNG files (which are v1.3 but are backwards-compatible with the v1.1 standard). DNG processing software that doesn't know about profiles will use the matrices as per the current behaviour (although in fact there are two matrices in there, which could result in better rendering depending on what white balance you're using than with the old files - v1.1 does support dual matrices).

Newer software that knows about DNG profiles will use them, older software should still be OK.
I'm still doing integration testing, but I haven't found any issues yet.

Logged

reyalp

14080

Re: Embedding profiles into DNGs

« Reply #2 on: 08 / September / 2010, 12:09:23 »

Quote

My code works by taking a .dcp file (the binary format of a DNG Profile file) and translating it into C code that is #included into core/dng.c

How large is this ? If it's more than a 1KB or so, I would say it should work as follows

- data is stored as a file on in the CHDK directory. The build process and put the profile for only that specific camera in there, or they can all be there. If they are all there, you could use something like <platformid>.dcp or whatever.
- IF the user has DNG enabled, then it is loaded into malloc'd RAM, and written each time the DNG is saved.

Another advantage of doing it this way is that users could update their own profiles, so it might be worth doing even if smaller.

Logged

Don't forget what the H stands for.

DavidB

40

Re: Embedding profiles into DNGs

« Reply #3 on: 08 / September / 2010, 20:24:07 »

The current incarnation adds no complexity to dng.c, but does add 5 or so const int [] arrays at the top of the file via an #include (including two 324-element arrays, but the others are tiny) along with a few more lines into IFD0[].

On the host side it handles all the complexity of byte-swapping the profile contents as required (the byte-order of the profile needs to be converted to that of the DNG) and inserting/replacing tags in IFD0 (maintaining appropriate tag order). If a profile has been copied from a similar camera (which normally requires changing the camera model string inside the file) it will take care of merging just the useful bits: we just have to rename the .dcp file (not the contents) appropriately.

I am interested in having .dcp files on the card and allowing the user to select the appropriate one, but this struck me as a simple but effective start.

All of this still leaves open the questions of:

Do we put all the .dcp files in one folder or scattered throughout platforms/?
How should default profiles be named?

Thanks

Logged

DavidB

40

Re: Embedding profiles into DNGs

« Reply #4 on: 08 / September / 2010, 21:08:38 »

I should add just in case there's confusion:

Even currently, users can build up a collection of different profiles for their camera (similar to the way Canon has Picture Styles in their DSLRs) and have them all installed on their computer so they can choose the one they want when processing. Adobe provides a range of profiles for each camera they natively support, and users can add heaps more.

When we embed a profile into a DNG in-camera, it provides a default profile which is available in addition to all the other profiles installed on their computer. It is most useful in the case where users have not installed any profiles onto their computer.

We DO have the option to embed a "stash" of profiles into the DNGs, and thus give users a selection of profiles without having to install them on each of their computers, but I've stayed away from that so far. One built-in default dual-illuminant profile is in general a whole lot better than one built-in single-illuminant matrix.

Logged

vit40

276

Re: Embedding profiles into DNGs

« Reply #5 on: 09 / September / 2010, 01:59:24 »

It may be interesting to know that profiles, provided by Adobe, are in fact not dual illuminant

They have a set of two color matrices, set of two forward matrices and one lookup table.
Color matrix 1 differs from Color Matrix 2, but if forward matrices are present in the profile, color matrices are used only to calculate RGB multipliers, used for whitebalancing data from sensor, from a color temperature and tint, set in ACR. If you left WB at As Shot, they are not used at all, as RGB multipliers are provided in raw file

After whitebalancing of raw data, Forward matrix 1 and 2 are used to convert from sensor color space to PCS color space. Those two matrices have the same values in most profiles (with only a few exceptions last year - and those are only Adobe standard)

After that, data are converted from PCS to PhotoPro color space and modified using one lookup table. At the end, resulting values are converted to selected output color spaces (sRBB, Adobe RGB ...)

Logged