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.
