DCamProf - a digital camera profiling tool

Table of contents

News

More flexible and more robust CGATS parsing.

More flexible tone curve parser.

When ICC profile is made to apply white balance the forward matrix is now normalized so the sum of Y is kept at 1.0.

The 1931 observer was by mistake mapped to Judd Vos 1978, now fixed.

The si-render command now supports specifying band range for indexed files using the new -b parameter.

Version 1.0.6 is now released which is a maintenance release. It includes mainly bug fixes made within the commercial Lumariver Profile Designer project. No major new features backported at this time.

2017-05-22

During the past year I've worked with a graphical user interface to DCamProf, which now is available: Lumariver Profile Designer. It's commercial software (not open-source and costs money). DCamProf will still continue to be open-source, but the main effort regarding support and features will be concentrated on paying customers.

2017-01-17

Version 1.0.5 is now released which is just a hot-fix release. I've become aware that the exclude patches and glare parameters for the make-profile command became broken (=had no effect) in the 1.0.1 release, and I've fixed that in this release.

2016-10-10

Version 1.0.4

Extended matrix optimization control to make-profile with the new parameters -v and -V . Now it's much easier than before to steer the optimizer in a custom direction if desired.

and . Now it's much easier than before to steer the optimizer in a custom direction if desired. Now presenting hue errors with direction, just as lightness an chroma. Hue is ordered magenta-red-yellow-green-cyan-blue, so if a red patch has a positive hue error it means that it's more yellow than it should be, and if it's negative hue error it's more magenta than it should be.

Slight behavior change of -l parameter to make-profile: now unnamed patches keep their default automatic relax ranges rather than get stuck at zero, plus it's now possible to provide a negative-to-positive range also for hue.

parameter to make-profile: now unnamed patches keep their default automatic relax ranges rather than get stuck at zero, plus it's now possible to provide a negative-to-positive range also for hue. Now possible to address individual patches with -l and -w to make-profile, so you don't need to make patch classes if you don't need to group together patches.

and to make-profile, so you don't need to make patch classes if you don't need to group together patches. Fixed some rounding errors in DE matching reports.

Large updates to the make-profile command documentation to cover the new matrix optimization feature.

Changed back the behavior of the -L to make-dcp so it skips both HueSatMap and LookTable.

to make-dcp so it skips both HueSatMap and LookTable. Clearer error messages for conditions when gamut compression cannot be applied.

2016-09-29

Version 1.0.3 is now released. Fixed fatal bug in curve parsing introduced in v1.0.2.

2016-09-27

Version 1.0.2 is now released.

Added an extra (optional) HSV-based compression step to gamut compression. Makes it feasible to achieve much stronger compression effects than previously, useful if you want to mimic the strong compressions found in many commercial bundled profiles. Two new presets added, "srgb-strong", "adobergb-strong", that uses the new pre-processing step that makes gamut compression much stronger. I expect "adobergb-strong" to be the most popular choice. If you have generated profiles with the previous "adobergb" preset, you may want to regenerate them with "adobergb-strong" preset to get more compression which makes it easier to work with high saturation subjects such as flowers.

Allow gamut compression even with a linear curve.

Now possible to provide "CurveMax" to a "Curve" look operator object if you want to specify the curve range in some other range than zero to one (usually zero to 255).

Various code cleanups without functional change (maintenance).

Added a new section in the documentation about how to relate to white balance presets.

2016-08-17

Version 1.0.1 is now released, and with it ready-to-run binary builds for Windows (64 bit) and Mac OS X. It's so easy to build in Linux so there you have to build from source. There's very little code changes from the last release, only some minor bug fixes so if you already have 1.0.0 installed there's no immediate need to update.

2016-05-20

Version 1.0.0 is now released. This is just a "rebranded" version of the previous 0.10.5, no new functionality has been added. The documentation on this page has got a much needed cleanup though.

DCamProf was originally pre-released in the end of April 2015, and an intensive period of adding new features and fixing bugs followed until November the same year. Since that six months have passed with more user testing, and I now think the software is stable enough to be promoted to version 1.0.0, which means that it's ready to be used by a broader audience.

Don't forget to check out the companion tutorial, Making a camera profile with DCamProf, which also has got a cleanup for this 1.0 release. The size of all this documentation may look a bit frightening — if you just want to make a good profile with the least possible effort, then go to the tutorial document and jump straight to the "easy way out" sections.

News archive

To keep down the size of this page the old news has been moved to a separate news archive page.

What is DCamProf?

DCamProf is a free and open-source command line tool for making camera profiles, and performing tasks related to camera profiles and profiling.

To make a camera profile you need either the camera spectral sensitivity functions (SSFs) or a measured target. DCamProf has no measurement functionality, but you can use the free and open-source Argyll CMS to get a .ti3 file with measurement data which DCamProf can read.

Here's a feature list:

Generate camera profiles from test target measurements or camera spectral sensitivity functions (SSFs).

Import (and export) measurement data from Argyll.

Detailed control of matrix and LUT optimizers to hand-tune the trade-off between accuracy and smoothness.

Test profile color matching performance, with free choice of illuminant.

Save reports and data files for plotting (using gnuplot for example).

Simulate reflective spectra all the way to the locus.

Built-in spectral database with Munsell, Macbeth CC24, spectra from nature and common illuminants.

Import spectral data to be used in targets or as illuminants.

Analyze camera color separation performance under different illuminants using SSFs.

Native camera profile format, can be converted to DNG profiles (DCP) and ICC profiles.

Support for ICC raw converters that apply pre-processing curves, such as Capture One.

Apply a subjective film curve while keeping neutral realistic colors.

Optionally design and embed a subjective look in your profile.

Decode and hand-edit ICC/DCP profiles, and re-encode them again.

Generate own test charts.

Correct uneven lighting in test chart photos (flatfield correction).

Note that many features are related to camera SSFs, and indeed you get most out of DCamProf if you have that available. You don't need them to make great profiles though, having them is more about flexibility and convenience than quality. You can then also learn many things of how cameras work by testing various things, such as the efficiency of a specific target design, or how a profile performs under a different illuminant and more.

The reason I started the project to make this software was that 1) Argyll can't do DNG profiles, and 2) I was not pleased with the commercially available alternatives for making own camera profiles — too much hidden under the hood, too little control, and many indications that the quality of the finalized profiles was not that good. I added the SSF ability later in the project and then the software grew to something more than just a profile maker, now you can say it's a camera color rendering simulator as well.

The software is quite technical, but if you can use Argyll you can use DCamProf. You can also find a separate tutorial of how to make profiles using DCamProf. It's supposed to complement the reference documentation found on this page.

Downloading DCamProf

Lumariver Profile Designer, a profile designer based on DCamProf technology. An alternative if you prefer to use a graphical user interface rather than the command line.

Here are the DCamProf downloads:

I have developed DCamProf on Linux and it should be straightforward to build there so I don't provide any Linux binary for download, just get the source and compile.

To build on Windows I recommend MinGW, and on OS X Clang should work, although you need one with OpenMP support. It's a bit more tricky to build on those operating systems, so therefore I've provided separate packages for them that includes just a ready-to-run executable and the documentation. Read the "readme" file first that is in the package.

Graphical user interface

DCamProf is command line software. If you prefer using a graphical user interface I have made a commercial alternative which is built on "DCamProf technology". It's called Lumariver Profile Designer and can be downloaded from www.lumariver.com. It's closed-source and costs money. The sales will indirectly contribute to the DCamProf project which will stay open-source and share core technology with the commercial GUI version.

How DCamProf models cameras

DCamProf looks on the perfect camera as a colorimetric camera, that is the SSFs matches the color matching functions for the CIE XYZ color space. No real camera is colorimetric so the goal of profiling is to make it perform as close as possible to one (and then possibly apply a tone reproduction operator and custom subjective look on top).

DCamProf assumes that the camera is linear, that is if you for example double the intensity of a certain spectrum the raw values will also double and there will be no change in their relation. This is indeed true for any normal digital camera today, with the possible exception of extreme under-exposure and very close to clipping where there can be non-linear effects.

The linearity assumption leads to that the correction lookup table (LUT) only needs to be indexed on chromaticity (that is saturation and hue, but not lightness), but the output still needs correction factors for all three dimensions as some colors can be rendered too dark or too light with a fixed factor throughout the full lightness range. That is DCamProf works with a LUT with 2D input and 3D output, commonly referred to as a 2.5D LUT.

DCamProf does allow you to apply a subjective look on top of the accurate colorimetric 2.5D profile. It will then use a full 3D LUT so you can make lightness-dependent adjustments, but the colorimetric part always stays 2.5D (well, except for some gamut compression of extreme colors, but that doesn't turn up in normal images).

2.5D vs 3D LUT

With a 2.5D LUT we assume that the same color in a darker shade will have the same shape of its spectrum, only scaled down. This is true if you render colors darker by reducing the camera exposure in a fixed condition. However, if we compare a dark and light color of the same hue and saturation in a printed media the spectrum shapes can differ because a typical print technology will alter the colorant mix (eg inks) depending on lightness. In some cases lightness is controlled by adding a spectrally flat white or black colorant, and in those cases spectrum shapes are retained, but that is not always the case.

This means that our linearity assumption breaks as the relative mix of camera raw values may differ slightly between dark and light colors and in this case a full 3D LUT could make a more exact correction. However, this only makes sense in highly controlled conditions when copying known media (such as printed photographs), that is when you're using the camera just like a flatbed scanner. The light source must be fixed, the camera exposure must be fixed, and the camera profile must be designed using a target made with the same materials as the objects you shoot.

As a 3D LUT only makes sense in this very narrow use case DCamProf supports only 2.5D for the colorimetric part (so far). If you really need a 3D LUT you can use Argyll, but you're then limited to ICC profiles. For strict reproduction work that may be a better approach.

Note that commercial raw converters often use 3D LUTs, not to achieve better colorimetric accuracy though but to make subjective "look" adjustments, which you also can do with DCamProf with its "look operator" functionality.

Basic workflow for making a DNG profile using a test target

Get or make a physical test target. The classic Macbeth/X-Rite 24 patch color checker is a fine choice. Get or make a reference file for the test target, preferably containing reflectance spectra. If you're using that 24 patch color checker like most will be doing, the reference file with reflectance spectra assembled by BabelColor is the second best choice if you can't measure it yourself. This data should be valid for the nowadays more popular "ColorChecker Passport" product too.

The above BabelColor CGATS text file example needs some conversion to be used with Argyll. To save you some time I've done it for you, look for cc24_ref.cie in the DCamProf distribution.

in the DCamProf distribution. Note that X-Rite changed their formula slightly in ColorCheckers produced November 2014 and later. The bundled cc24_ref.cie is for targets produced before November 2014, and cc24_ref-new.cie is for targets produced November 2014 and later. Shoot your test target under the desired light source. Store in raw format. Convert the raw file to a 16 bit linear TIFF without white balancing. You can use a recent version of RawTherapee (export for profiling, with disabled white balance), or DCRaw dcraw -v -r 1 1 1 1 -o 0 -H 0 -T -6 -W -g 1 1 <rawfile>

If you have an odd camera format and you want to use the profile in Adobe's products it may be safer to convert to DNG first using Adobe's DNG converter, as raw decoding of proprietary formats may differ a little concerning application of black levels, white levels and calibration data.

Crop so only the target is visible, and rotate if needed. Argyll is very sensitive to target orientation. If you use some image editor to do this make sure that the full 16 bit range is kept, that is don't use 8 bit Gimp for example. If you use RawTherapee you can crop and rotate in there. Use Argyll scanin command to generate a .ti3 file. It needs the target reference file, test target layout file and raw image as 16 bit TIFF as input.

scanin -v -p -dipn rawfile.tif ColorChecker.cht cc24_ref.cie

Passport version: scanin -v -p -dipn rawfile.tif ColorCheckerPassport.cht cc24_ref.cie

The scanin command will generate a diag.tif which shows patch matching (look at it to see that it matched) and a rawfile.ti3 file which contains the raw values read from rawfile.tif together with reference data from the cc24_ref.cie file. Use DCamProf to make a profile from Argyll's rawfile.ti3 target file. dcamprof make-profile -g cc24-layout.json rawfile.ti3 profile.json

The above command doesn't specify any illuminants, which means that the profile will be made for D50 and the rawfile.ti3 must contain reflectance spectra (it will if the example cc24_ref.cie is used) or have it's XYZ values related to D50. To change calibration illuminant use the -i parameter, and if the .ti3 lacks reflectance spectra specify its XYZ illuminant using -I .

must contain reflectance spectra (it will if the example is used) or have it's XYZ values related to D50. To change calibration illuminant use the parameter, and if the lacks reflectance spectra specify its XYZ illuminant using . Per default DCamProf will automatically relax the LUT a bit, that is prioritize smoothness over accuracy. How this is done can be precisely manually controlled if you desire, see the documentation for the make-profile command for an in-depth explanation.

The target layout is provided in a JSON file cc24-layout.json . If the target contains both black and white patches glare will be modeled and reduced, and if the target contains several white patches (not the CC24, but for example a ColorChecker SG) it will be flatfield corrected. Convert the native format profile to a DNG profile (DCP). dcamprof make-dcp -n "Camera manufacturer and model" -d "My Profile" profile.json profile.dcp

For many raw converters the camera manufacturer and model must exactly match what the raw converter is expecting. For example if using Adobe Lightroom the name must match the name Lightroom is using for it's own DCPs.

match what the raw converter is expecting. For example if using Adobe Lightroom the name must match the name Lightroom is using for it's own DCPs. The description tag (set by -d , "My Profile" in this example) will be the one shown in the profile select box in for example Adobe Lightroom.

, "My Profile" in this example) will be the one shown in the profile select box in for example Adobe Lightroom. The above example makes a colorimetric profile without a curve. If you want to embed a tone-curve and make use of DCamProf's neutral tone reproduction (which really makes more sense for a general purpose profile ), you can do like this: dcamprof make-dcp -n "Camera manufacturer and model" -d "My Profile" -t acr profile.json profile.dcp

), you can do like this: The DNG profile is now ready to use in your raw converter.

Basic workflow for making an ICC profile using a test target

Making an ICC profile is almost the same as a DNG profile. Actually you can follow the exact same workflow and run the make-icc command at the end instead of the make-dcp, as the native profile format can be converted to both types. However, some raw converters using ICC profiles apply some sort of pre-processing such as a curve before the ICC profile is applied which much be taken into account. Capture One is one such raw converter.

The steps that are the same as in the DNG profile case are only briefly described here, so look there if you need further details.

Get a physical target with reference file, and shoot a raw file in desired light. Export to a tiff for profiling in the raw converter you will be using. How you do it varies depending on raw converter, look in its documentation or search on the 'net. Capture One: Select ICC profile: "Phase One Effects: No Color Correction", Select Curve: "Linear Response" (or similar), rotate/crop to show only the target. Then Export variants, "16 bit TIFF", "Embed camera profile". Note: you probably don't want to use "Linear Scientific" as it is a special mode which disables highlight reconstruction. Of course there should be no clipping in the profiling TIFF, but as the profile should be used with the same curve when finished the "Linear Response" is better for all-around use.

White balance setting does not matter, unless you intend to let the profile correct a camera preset (not a common use case, see make-icc reference documentation for more information).

If you can choose a curve, choose linear. DCamProf must somehow be able to calculate the linear data. If the exported TIFF contains a transfer function tag, like from Capture One, the curve choice doesn't really matter as it can be linearized anyway. I still recommend using a linear curve during profiling, to maximize precision. If the exported TIFF doesn't contain a transfer function tag, you should export with a linear curve, unless if you can find out the transfer function in some other way. Note that "linear" doesn't necessarily mean exactly linear in many raw converters so you may need to find out the transfer function anyway.

Use Argyll scanin command to generate a .ti3 file (using the matching .cht file). scanin -p -v -dipn target.tif ColorChecker.cht cc24_ref.cie

Passport version: scanin -p -v -dipn target.tif ColorCheckerPassport.cht cc24_ref.cie If the raw converter applies a pre-processing curve (like Capture One), re-process the .ti3 file to get linear RGB data. dcamprof make-target -X -f target.tif -p target.ti3 new-target.ti3

DCamProf gets the pre-process curve from the transfer function tag in the profiling tiff. You can also extract it separately with the tiff-tf command, but as the make-target command can handle the tiff directly it's generally not needed.

If pre-processing curve cannot be had from the tiff, you need to supply it in a JSON file (still -f parameter), see the bundled data example for formatting. Use DCamProf to make a native profile from the linear .ti3 file. dcamprof make-profile -g cc24-layout.json new-target.ti3 profile.json Convert the native format profile to an ICC profile. If pre-processing curve was used it must be given: dcamprof make-icc -n "Camera manufacturer and model" -f target.tif profile.json profile.icc

...otherwise the -f parameter is skipped: dcamprof make-icc -n "Camera manufacturer and model" profile.json profile.icc

parameter is skipped: If you want to embed a tone curve and make use DCamProf's neutral tone reproduction you do like this (both with and without pre-processing shown): dcamprof make-icc -n "Camera manufacturer and model" -f target.tif -t acr profile.json profile.icc dcamprof make-icc -n "Camera manufacturer and model" -t acr profile.json profile.icc The -t acr parameter will apply Adobe's standard film curve, you can also design your own, or import via the tiff-tf command. The curve will be applied to the profile's LUT. If you're using Capture One, read the section about Capture One and curves.

The ICC profile is now ready to use in your raw converter.

Note that some ICC raw converters do additional processing than just a curve and white-balance, they may for example do some sort of pre-matrixing. If the stripped profiling tiff looks much more saturated than a corresponding tiff from a DCRaw or a DNG profiling workflow it's likely that some pre-matrixing has been applied. As you profile based on the raw converter's own profiling TIFF this doesn't matter, except that the native format profile generated in the process will not be compatible with any other raw converter.

There are also ICC raw converters that do no specific pre-processing, that is provide the ICC profile with "pure" raw input just like to a DNG profile, meaning that you can use the same native profile produced in a DNG workflow and make an ICC profile too. DxO Optics is one such raw converter.

Capture One and curves

Some raw converters allows choosing the curve separately, and Capture One is one of them. This is actually against the design principles used in DCamProf. With DCamProf the profile itself applies the curve partly or entirely via a LUT, and if you want different curves you simply render different profiles, one for each curve. This is because tone curves can fundamentally affect color rendition, as described in the tone curves and camera profiles section.

That Capture One doesn't change ICC profile when the curve is switched you could say is broken color science, however due to the mild shape of their curves and that they are applied before the ICC profile the color appearance is not affected that much. Actually they have a mixed approach, some of the curve is applied separately before the ICC and some is applied by the profile's LUT. This mixed approach makes the color appearance more stable between the different curves than it otherwise would have been, but it also makes the result with "Linear Response" far from actual linear.

In any case you can assume that their bundled profiles have been optimized for the default curve and the others will provide somewhat sub-optimal color, or at least less designed color.

If you like your DCamProf profile to work the same way, you do this way:

Make a profile with the linear response, that is everything in the standard workflow until you've run the make-profile command. Export a profiling TIFF one with the "Linear Response" (let's call it linear.tif ) and the other with the desired curve, usually "Auto" or "Film Standard" (let's call it curve.tif ). Extract the actual shape of the curve from the TIFF files, using the tiff-tf command: dcamprof tiff-tf -f linear.tif curve.tif tone-curve.json

It may warn that the curves don't end at 1.0, don't worry about that. Capture One does that, probably related to having some margin for highlight reconstruction or white balance adjustments. The tiff-tf command will automatically compensate. Make a preliminary ICC profile adapted for the curve's pre-processing, and also apply the tone curve. dcamprof make-icc -n "Camera manufacturer and model" -f curve.tif -t tone-curve.json profile.json preliminary-profile.icc

As the pre-processing curve and tone curve are the same, they will cancel out and the resulting profile is linear in terms of contrast, but the neutral tone reproduction operator will have done its work with the appropriate curve, so the profile becomes optimized for that. Load the preliminary profile and compare with the bundled. Probably the DCamProf profile has lower contrast because the native profile applies some extra contrast in the LUT. Use the curve tool inside Capture One to manually match the contrast. An exact match is not necessary, what you find most pleasing is the best for you. Transfer the coordinates from the curve tool to a JSON file DCamProf can read, let's call it modifier-curve.json . Find an example below. Re-run make-icc with the extra curve cascaded. dcamprof make-icc -n "Camera manufacturer and model" -f curve.tif -t tone-curve.json -t modifier-curve.json profile.json profile.icc The profile is now ready to use. The look will be optimized for the chosen curve, but it will look okay too for "Linear Response", just like Capture One's bundled profiles. Of course, there will be the residual curve left (the modifier-curve) when you use the profile in "Linear Response" mode, in the same way as native profiles.

The modifier curve is suitably designed with the curve tool inside Capture One. Load the preliminary profile generated in the workflow above, and then edit a curve to your liking. Then copy the handle values into a text file with the JSON tone curve format, like this:

{ "CurveType": "Spline", "CurveHandles": [ [ 0,0 ], [ 14,8 ], [ 27,20 ], [ 115, 118 ], [ 229, 233 ], [ 255, 255 ] ], "CurveMax": 255, "CurveGamma": 1.8 }

Capture One uses 0 – 255 as their range in the curve, and the curve works with gamma 1.8.

Basic workflow for making a profile from camera SSFs

If you have the camera's spectral sensitivity functions you can skip the target shooting process.

Format your camera's SSF data into a JSON file that DCamProf can read. Use the distributed examples as a guide for how the JSON file should be formatted.

If you don't have the equipment or knowledge to measure your camera's SSFs, you can look in the SSF links section and see if you're lucky and can find your camera in one of the sources. Generate a "virtual" target with your desired spectral data. You can use DCamProf's built-in spectral database or use its ability to generate spectra, or import from some other spectral source (see provided import_spectra.txt for formatting, it's the Argyll .ti3 format, but you can use a subset).

for formatting, it's the Argyll format, but you can use a subset). Here's a basic example where we just generate a color checker from the built-in spectral database target: dcamprof make-target -c ssf.json -p cc24 target.ti3

The resulting target.ti3 contains reflectance spectra for all patches, plus XYZ reference values and RGB values for the camera rendered using the SSFs found in ssf.json . Make the profile dcamprof make-profile -c ssf.json target.ti3 profile.json

We don't really need to provide the camera's SSF again ( ssf.json ) as the target file already contains rendered RGB and XYZ values, but it's a good habit since then the RGB (and XYZ) values will be regenerated from spectra each time which is convenient and reduces the risk of making mistakes.

) as the target file already contains rendered RGB and XYZ values, but it's a good habit since then the RGB (and XYZ) values will be regenerated from spectra each time which is convenient and reduces the risk of making mistakes. If the SSFs are of high quality you will typically get a considerably better match with this than if you have shot a test target. This means that there is often less need of weighting and LUT relaxation when rendering the profile. Convert the native profile to a DNG profile or an ICC profile. See the description for the basic workflow using a test target for more details.

In this example workflow we keep the illuminants at default, D50. As we let the spectral information follow through in the workflow we can change calibration illuminant late in the process, when making the profile:

dcamprof make-profile -c ssf.json -i StdA target.ti3 profile.json

Note that as SSFs are generally measured from real raw data without pre-processing, profiles generated from SSFs won't work for ICC raw converters that does pre-processing before applying the ICC, such as Capture One.

Choosing test target

Due to natural limitations of camera profiling precision it's quite hard to improve on the classic 24 patch Macbeth color checker when it comes to making profiles for all-around use. It's more important to have a good reference measurement of the test target than to have many patches. If you don't believe me please feel free to make your own experiments with DCamProf; by using camera SSFs you can simulate profiling with both few and many patches and compare target matching between them.

DCamProf allows you to use any target you like though, you can even print your own and use a spectrometer and Argyll to get reference values. Although darker repeats of colors does not hurt there's not much gain from it as the LUT is 2.5D, so an IT-8 style target layout (many patches are just repeats in darker shades) does not make that much sense.

Dark patches are problematic as they are more sensitive to glare and noise (both in camera and spectrometer measurement), so an ideal target has as light colors as possible for a given chromaticity.

The profiling process requires at least one white (or neutral gray) patch, but it tolerates if it's slightly off-white. The target should preferably also contain one black patch which should be the darkest patch in the target. This black patch is used to monitor glare. If feasible the "black" should be made as light as possible while darker than the darkest colored patch. If the black patch is significantly darker than the darkest colored patch DCamProf may detect a glare issue than in actuality only affects the black patch.

The white (and black) patches should preferably have a very flat spectral reflectance, as it makes glare monitoring more accurate.

Most targets have a gray scale step wedge which can be used for linearization. Digital cameras have linear sensors, but the linearity can be hurt by glare (and flare). Normally it's much better to reduce glare to a minimum during shooting than trying to linearize afterwards, as glare distortion is a more complex process than just affecting linearity.

In addition to compensate glare effects DCamProf also has support for flatfield correction which means that uneven lighting can be compensated for. In order to do so you either need a target sprinkled evenly with white patches, or you shoot a separate flat field shot of a completely white chart under the same light. You can read more about this in the testchart-ff command documentation.

(Semi-)glossy targets, such as X-Rite's ColorChecker SG, are extremely glare-prone and therefore hard to use. They cannot be shot outdoors, but must be shot indoor in a pitch-dark room with controlled light. Due to their difficulty during measurement the end result is often a worse profile than using a matte target. Thus I recommend to first get good results with a matte target before starting to experiment with a semi-glossy. Those targets often receive bad reviews simply because the users have not minimized glare when shooting them.

A note about X-Rite targets: due to regulatory and compliance reasons the colors where changed slightly in November 2014, so all targets produced in November 2014 and later has slightly different colors than those produced earlier. This means that if you don't measure your target yourself you need to make sure you have a reference file that matches the production date of your target (DCamProf comes with reference files for both the old and new versions). These things can happen also for other manufacturers and they may not always be announced.

If you have the camera's SSFs you can use the built-in spectral databases (or import your own) rather than shooting real test targets. In that case you will probably want to select spectral data that matches what you are going to shoot, for example reflectance spectra from nature if you are a landscape photographer.

The classic 24 patch Macbeth color checker, originally devised in the 1970's. Despite its age it still holds up well for designing profiles, thanks to relatively saturated colors with a relatively large spread. As seen in the u'v' chromaticity diagram (with locus, AdobeRGB and Pointer's gamut) there's still space to fill though, and some patches are occupying almost the same chromaticity coordinate which is not that useful when making 2.5D LUTs.

Making your own target

Using the make-testchart command you can make your own target. Here's an example workflow, showing how to make a target for an A4 sheet and using a Colormunki Photo spectrometer for scanning the patches:

Generate test patches in Argyll's .ti1 format: dcamprof make-testchart -l 15 -d 14.5,12.3 -O -p 210 target.ti1

In the above example we specify the chart layout with -l , -d and -O parameters, so that white patches can be placed optimally for flatfield correction later on. The layout must match what Argyll's printtarg is going to generate. Generate a .tif for printing, a .cht file for chart recognition and .ti2 file for scanning using Argyll's printtarg command: printtarg -v -S -iCM -h -r -T300 -p A4 target

It's important that we use the -r flag, otherwise Argyll will randomize the patch positions which can break flatfield correction.

flag, otherwise Argyll will randomize the patch positions which can break flatfield correction. In the above command we choose A4 sheet and Colormunki half-size patches, it will make 210 patches in one sheet, like we have generated. Even if you don't have a Colormunki instrument the generated patch size is suitable for a test chart for photography (printer profiling targets often have very small patches). Print the tiff file on an OBA-free paper matte or semi-gloss, with color management disabled, that is the same way you would print a test chart for printer profiling. Measure the reflectance spectra of the patches (this will make a .ti3 file): chartread -v -H -T0.4 target Convert the .ti3 to a reference .cie file to be used with Argyll's scanin later. spec2cie -v -i D50 target.ti3 target.cie Now you have the printed test chart, a target.cht chart recognition file and a target.cie reference spectra file which can be used in the profiling workflows.

The quality of your own target will depend on the spectral qualities of your printer. A modern inkjet printer with several inks will have better spectral qualities than many other print technologies, but will still not be as good as the special print techniques used when commercial test targets are made. If you are curious about target performance you can use the SSF functionality of DCamProf to make simulations. Despite spectral limitations it seems that they perform at least as good as a CC24 or sometimes even better when it comes to making profiles that matches real colors.

Semi-gloss targets will get very high saturation patches, but those are difficult for the camera to match and it's hard to shoot those targets without glare issues. They may also be harder to measure accurately with the spectrometer if it has limited range (some consumer spectrometers start at 420nm) or issues with glare. Making a matte target may be better in practice, although you can't get deep violet colors in those.

Test target reference files

The foundation of profiling using test targets is that the profiling software knows what CIE XYZ coordinate each color patch corresponds to, or even better which reflectance spectrum each color patch has so the software can calculate the XYZ values itself.

Higher end test targets may be individually measured so you get a CGATS text file with reference values, and Argyll's scanin tool can use them directly. If you get a standard 24 patch Macbeth color checker you probably don't have an individual reference file and then a generic file like the one provided with DCamProf will have to do ( cc24_ref.cie for targets produced before November 2014, cc24_ref-new.cie for newer). Having the reflectance spectra is strongly preferred over pre-calculated XYZ values, so do get that if you can.

The problem with pre-calculated values and no spectra is that when changing illuminants the software cannot re-calculate XYZ from scratch using spectral data, but must rely on a chromatic adaptation transform which is less exact. It's also a higher risk for the user to mess up by forgetting to inform DCamProf of which illuminant the XYZ values are related to. If there's spectral data the reference values are always re-generated from scratch to fit the currently used illuminant, which is both exact and convenient.

If you have a spectrometer (usually designed for printer profiling) you can measure your target and generate your own reference file with spectra. Using Argyll you do like this:

Create or find an Argyll .ti2 text file which contains the test target layout needed for the spectrometer scan. Note that Argyll is distributed with .ti2 files for many of the popular commercial test targets, the file is called ColorChecker.ti2 for the CC24. Scan the target with Argyll's chartread (exclude the .ti2 suffix, for most Argyll commands the suffix should be excluded): chartread -v -H target

Note that some targets may have too small patches to be read successfully with your instrument. For example an X-Rite ColorChecker Passport cannot be read by an X-Rite Colormunki spectrometer. Convert the resulting .ti3 file (which contains complete spectra for each patch) to a new .ti3 file with reference CIE XYZ values with your desired illuminant. spec2cie -v -i D65 target.ti3 reference.cie

In the above example "D65" was chosen, but you can also choose "A" or "D50", or any other supported by the spec2cie tool.

tool. As the spectral data will be kept in the file it actually doesn't matter what illuminant (or observer) you use, you can change that again when generating the profile with DCamProf. The described method is however also compatible with a standard Argyll workflow. The resulting reference.cie can now be used together with Argyll's scanin tool. If you don't have a usable .cht file for the chart layout (a more detailed layout information than needed for the spectrometer scan), you need to generate one. If you have generated your own chart using Argyll's printtarg you can add the -s (or -S ) parameter to it to get the .cht file. If you haven't used printtarg it's unfortunately a bit of a headache to make your own .cht. You can use the scanin tool as a help for that (using the -g parameter), but it's quite messy with lots of manual edits. At the time of writing I have not tried doing it myself and as long as you're using a reasonable popular target there will be a .cht file distributed with Argyll, and if you make your own using Argyll you can make the .cht when calling printtarg .

It's probably better to measure your own target and get full spectral information than getting a typical pre-generated reference file with only XYZ values for some pre-defined illuminant. If it really is better depends on the precision of your instrument, the sample-to-sample variation of test targets and the quality of the provided reference file. It's not possible to really know what will be best, you can try both and see what you like the most. If there's some serious problem with the reference file it's usually noticed when making the profile, such as that the LUT must make extreme stretches to match the target or other types of matching issues.

In some cases you may get the reference spectra in some format that Argyll can't read directly. Argyll is delivered with a few conversion tools to handle other common text formats, cb2ti3 , kodak2ti3 and txt2ti3 . You may also be helped by making a dummy conversion using DCamProf, like this: dcamprof make-target -p input.txt -a "name" output.ti3 , and sometimes you must also make some manual edits in a text editor to get it into a format Argyll accepts.

Shooting test targets

To consider:

Even light from the desired illuminant, or prepare for flatfield correction.

Avoid reflections and glare on the target (which is difficult with glossy and semi-glossy targets).

Avoid colored reflections from nearby surfaces.

Minimize vignetting.

Minimize perspective distortion.

Avoid over- or under-exposure.

If you are simulating daylight using an artificial light source it's better to use a high temperature halogen lamp, such as a Solux lamp on overdrive, than a fluorescent. Or just shoot outside in real daylight, but that only works with matte targets otherwise glare issues generally becomes too large to deal with.

Avoid reflections from nearby colored surfaces that may distort the color of the light source. If shooting outdoor, shooting in an open space with someone holding up the test target in front away from the body is a good alternative.

I recommend to defocus very slightly so you won't capture any structure of the target patches surface and instead get fields of pure color. If your camera lacks anti-alias filter this also makes sure you get no color aliasing issues. Shoot at a typical quite small aperture, say f/8 if using a 135 full-frame camera.

Argyll's scanin is sensitive to perspective distortion, so try to shoot as straight on as possible, and correct any residual rotation/perspective distortions in the raw conversion. It can compensate itself using the -p parameter, but it's still wise not trying to push it.

If you know what you are doing you can push the exposure a little extra to get optimal "expose to the right" (ETTR) and thus as low noise as possible. But be careful, clipped colors will be a disaster in terms of results. I use to exposure bracket a few shots and check the levels in the linear raw conversion to see that there is no clipping. Note that if you're making an ICC profile and use a raw converter that pre-process the raw data with a curve that compress highlights, like Capture One, ETTR is not optimal as that will put highlights in the compressed range. If so expose a bit lower (for Capture One putting the white at about 240 is suitable).

Uneven lighting is a common problem in camera profiling. The typical recommendation is to make sure you have even lighting (at least two lights if not shooting outdoors) and shoot the target small in the center (to minimize vignetting). However, if you employ DCamProf's flatfield correction (the testchart-ff command) you can relax the requirement on even lighting quite a bit. Flatfield correction evens out the light with high accuracy, so you need only make sure all parts of the target has sufficient light to avoid noisy patches. Note that some halogen lights may have an outer rim of light of a different light temperature, and this is not well corrected with flatfield correction. So make sure the target is at least lit with the same light spectrum all over.

Using fewer lights (maybe only one) and compensate with flatfield correction can be a smart strategy when shooting glossy targets, as it's easier to keep the rest of the room dark. Room darkness is very important to reduce glare which is a real issue with (semi-)glossy targets.

Glossy and semi-glossy targets allow for higher saturation colors on the patches, but are also more difficult to shoot as they produce glare. Glare is minimized by being in pitch-dark room and having the light(s) outside the "family of angles". If the target is replaced with a mirror you should only barely see the dark room and camera in it, certainly not any lights. Having a long lens narrows down the family of angles, and a projecting light source (like a halogen spotlight) and dark/black cloth around the target makes sure as little stray light as possible bounces around in the room.

This may look as a perfect target shot, even diffuse outdoor light, no visible reflections. However as the target is semi-glossy the surrounding diffuse light coming from all directions add up the direct reflection component (glare) so the contrast of the target is lowered and the photograph will not match reflectance spectra measurements. Semi-glossy targets must be shoot in indoor lab setups with dark surroundings and projecting light(s) outside the family of angles.

(Semi-)glossy targets are virtually impossible to shot accurately outdoor as you cannot shoot from a dark position, that is if you put a mirror where the target is you will likely clearly see the camera and yourself, which means you will have glare. If you still shoot it in that light it will be affected by glare and produce a lower contrast result, the dynamic range easily drops from 7 stops (typical range in a semi-glossy target) to about half. This won't be visible until you make side-by-side comparison or note poor profiling results (typically an over-saturated profile with some bad non-linearities).

Veiling glare is a lens limitation of how large dynamic range it can capture. It's typically between 0.3% to 0.5% for high quality lenses; the fewer lens elements and better quality coating the lower veiling glare. I mention it here as you may have heard of it, but compared to other forms of glare this is negligible so you don't need to worry about it. Do avoid lens flare though, so the lens front element must be shadowed. Use a lens hood and make sure you have no light sources towards the camera. If you use an SLR camera also make sure the viewfinder is closed tight so no light comes in that way.

If you shoot a glossy target be prepared that you can have issues with dark patches, as those are affected most by glare. Removing those from the measurement (using an exclude list to the make-profile command for example) can be a better way to solve the problem than trying to correct the measurement error in other ways. Due to the many difficulties with semi-glossy targets I recommend to simultaneously make a profile from a matte target so you have a profile to sanity-check against.

In theory a gray scale step wedge in the target could be used to correct glare. With DCamProf you can enable "glare matching" in the testchart-ff command, or directly in make-profile to compensate glare-induced non-linearity. However, glare distorts more than just linearity and in unpredictable ways meaning that any linearization or glare matching will only help to some extent, so don't rely on it. You can indeed improve results this way, but for a glossy target it often ends up worse than just excluding the darkest patches (those that are most affected by glare). So my recommendation is to reduce glare to a minimum when shooting, and keep an extra eye on the performance of dark patches, and exclude them if they seem problematic.

If you shoot a matte target you won't have the same issues with glare so there you can typically include the darkest patches, but it's still often a good idea to enable glare matching to improve the result, especially if you shoot outdoors where the light is less controlled.

White balance and camera profiles

The white balance setting in your raw converter and your camera profile interacts so before making profiles it's good to have some insight into that.

Both DCPs and ICCs make corrections on white balanced data, that is the raw converter pipeline feeds the profile with a white balanced image. For DCPs it might seem that it doesn't as the "ColorMatrix" work on unbalanced image data (more on that later) but the actual color rendering is decided by the "ForwardMatrix" and the LUT, which both work on the white balanced image.

Naturally this means that in order for the profile to make the "correct" adjustments it must be used with the exact same white balance as used during profile design. Which is that? Per default DCamProf will re-balance the target such that the whitest patch in the target is considered 100% neutral (real targets usually differ 1-2 DE from perfect), which means that white balance picker on the most neutral patch is the best balance. Note that the "most neutral" patch may not necessarily be the lightest patch; if the target contains a grayscale one of the gray patches could be more neutral, for a CC24 the second patch in the grayscale row is actually more neutral that the lightest. If you want to you can manually point out which patch to use as reference using the -b parameter to make-profile. You would then typically point out the lightest neutral patch that most would use their white balance picker on in a raw converter.

You can also disable using an actual patch from the target as reference ( -B to make-profile). Then DCamProf calculates the optimal white balance automatically, which is when camera white (raw R=G=B) matches the calibration illuminant reflected by a 100% perfect white patch (flat spectrum), which is usually slightly different from the whitest patch in the target.

In any case the reference will be a picked or calculated white balance, not the "As Shot" camera preset balance (there is an ICC special case though where you can design a profile for a camera white balance preset).

A well-behaved profile, that is one with only small and wide area stretches in the LUT, will be robust against slightly different white balances so it won't matter if you set it a little bit off to get a warmer or cooler look for example. A profile which has strong and very localized stretches (not a good profile!) may make sudden strange color changes when you shift white balance. This is because when you change white balance you apply a cast on all colors, which means that the colors move to other start positions in the LUT, and will get corrections that was intended for other neighboring colors, and if there are strong localized corrections the results can become quite distorted.

Wouldn't it be better if the ideal profile white balance was applied first, then the profile, and then your own user-selected white-balance? Yes, if the illuminant would always be the same as the one used when shooting the target, but if you shoot outdoors that's not the case. And in any case that's not how raw converters work so you can't have it that way even if you'd like it.

The take-away message is that for an ideal profile result you should set the white balance to represent white as good as possible, and if you want to make a creative cast, for example a bluer colder look, you should ideally apply that look on top with other color tools rather than the white balance setting. However, many (most?) raw converters don't make it easy to apply a cool/warm look in a different way than using the white balance setting, so that's what we usually end up doing anyway. If you've made a well-behaved profile (which you should) that should not be any real problem. Yes, profile corrections will not be as exact as when used at its designed white balance, but if you're creating a look that won't matter anyway.

The most robust profile concerning white balance changes is a pure matrix-only profile (no LUT), as it's 100% linear. It doesn't mean that it makes as accurate color at other white balances than it was designed for, but it won't suffer from sudden color changes due to localized LUT effects.

DCP-specific white balance properties

DCPs are a bit special when it comes to white balance, they have a more immediate connection to it than ICC profiles.

The embedded "ColorMatrix" is not used for any color corrections, but to figure out the connection between a camera raw RGB balance (internal white balance multipliers which you usually can find in the EXIF data) and illuminant temperature and tint. When you use the camera's "As Shot" white balance, the raw converter will display the corresponding temperature and tint as calculated via the ColorMatrix. This means that if you change profile to one with a different ColorMatrix the "As Shot" temperature/tint will change even if the multipliers are exactly the same. Ideally the temperature/tint should of course show the "truth", the actual correlated color temperature of the illuminant for that white balance, but it's an approximation that may differ quite much between profiles. For a temperature around 5000K a variation of several hundreds of degrees between two high quality profiles is normal, simply because three distinct RGB channels cannot really say much about the shape of a light spectrum. Naturally a profile is best at estimating temperatures close to the one that was used when the profile was made.

If you instead of using the "As Shot" white balance selects a different one with temperature and tint, the ColorMatrix is used to calculate the corresponding white balance multipliers, at least when it comes to Adobe Lightroom (other raw converters may use a hard-coded white-balance model rather than using the profile-provided ColorMatrix). This means that if you change profile to one with a different ColorMatrix the temp/tint will in this case stay the same but the actual multipliers will change and thus the actual visual appearance, that is you get a shift in white balance.

A DNG profile contains the calibration illuminant as an EXIF lightsource tag, meaning that there is a limited set of pre-defined light sources to choose from. For a single illuminant DNG profile this tag is not used though, so it can be set to any value. If you provide DCamProf with a custom illuminant spectrum during profiling the resulting DCP will contain "Other" as lightsource tag, that is no information of what temperature the profile was designed for, but as it's not used it's not a problem.

However if you don't provide the spectrum and instead provide the completely wrong illuminant, say you shoot the target under Tungsten but say to DCamProf that it's D50, the calculated color matrix will be made against incorrect XYZ reference values and the resulting profile will be bad at estimating light temperatures. For single illuminant profiles that still won't affect the color correction though.

Dual-illuminant profiles is an exception. In that case you have two matrices, usually one for StdA and one for D65. Both these are then used to calculate the temperature and tint, and the derived temperature is then used to mix the two ForwardMatrices, that is if it's exactly between the 6500K of D65 and 2850K of StdA then 50% of each is used. This means that the temperature derivation has some effect on the forward matrix and thus some effect on the color correction. So if you intend to make a dual-illuminant profile it's required to provide a proper EXIF lightsource for each, and for the profile to make accurate temperature estimations the actual lights used during profiling should match the EXIF lightsource temperatures as well as possible. It doesn't have to be exact though as any reasonable camera should have similar matrices over a quite wide temperature range.

Note that a DCP profile cannot be made to "correct" white balance, that is change your "As Shot" white balance multipliers to something else. In some reproduction setups you may want to do that, and for this you need to use an ICC profile instead.

When you make your own profile with DCamProf and use it in Adobe Lightroom for example it's as discussed highly likely that you will get a white balance shift compared to the bundled profile. This doesn't mean that there is something wrong with your profile, but simply that your calibration setup and matrix optimizations did not exactly match Adobe's. If you want to apply your profile that previously used the bundled one with a custom white balance settings this white balance shift can be problematic though. Fortunately it's simple to avoid: just copy the color matrix from the bundled profile, which you can do directly in the make-dcp command. It only removes the white balance shift; as the actual color correction sits in the forward matrix and LUTs, the color matrix change will not affect the color rendition (except for the slight effect caused by the dual-illuminant mixing described separately, but you can safely assume that effect is negligible to the profile's performance).

ICC-specific white balance properties

ICC profiles have unlike DCPs no connection to the raw converter's white balance setting. When DCamProf makes its native profiles it makes both a ColorMatrix and ForwardMatrix, but if you convert to a ICC profile only the ForwardMatrix will be used as it has no element to identify illuminant color temperature as DCPs have.

Raw converters that use ICC profiles have some other method than using the profile to figure out a suitable temperature/tint to show in the user interface. Maybe by using hard-coded color matrices or hard-coded preset values, or some other proprietary model.

Normally ICC profiles are designed to not affect the user white balance, so when you change profile to an entirely different one the overall tint will still not change (except for tiny changes related to correction of neutrals). However ICC profiles can change the white balance if designed for that. One application could be to make an ICC profile that changes the camera's "As Shot" white balance to match a specific light source used in a reproduction setup. DCamProf can make such a profile if you instruct it to, as described in the make-icc reference documentation. This feature is unique to ICC, you can't make it with DCP as the DCP design prohibits white balance alterations by the profile.

Color for extreme white balances

Raw converters are designed such that "white" should be white (neutral on the screen, R=G=B), but for extreme color temperatures (candle light, Nordic winter dusk etc) this is not how the eye/brain experiences the scene, white objects will have a tint. To render such cases realistically you will have to adjust the look creatively to taste, as the available color models do not support profiling those situations in any accurate way.

Landscape photography in the snow makes this issue very clear. While the snow is "white", you must often tint it to taste to replicate the eye's experience at the scene.

White balance presets

Cameras have white balance presets such as "daylight", "shade", "flash" etc. These are not standardized in any way so it differs between brands and models exactly which light these presets are calibrated for. That is a white patch that becomes 100% neutral (R=G=B) in a specific light for camera A's daylight white balance setting will have a slight tint for camera B's daylight setting.

If you design two profiles for two different cameras with the exact same target under the exact same light, and you use the white balance picker to set a custom white balance on the white patch, it will be very difficult to tell the two cameras apart, they will look almost exactly the same. However if you usually use a preset on the camera, say the "daylight" preset which is common in landscape photography, it's highly likely that the cameras will have a visible difference in look. For example that one camera will render slightly warmer tones than the other, and this is simply because the white balances are different. In other words profiles can only make two cameras look the same if white balance is tuned for the same white.

Ideally it would exist a profile standard so you could load profiles directly into the camera and re-program the white balance presets. Or even better, profiles would store the SSFs so the raw converter could have its own preset light source spectra and accurately calculate corresponding white balance multipliers for any camera. But this does not exist. So how to relate to what we have got?

First let's consider what the problems are. The main problem is that if you use white balance presets the look will change if you change camera, for example if you make a switch in the middle of a shoot, or if you upgrade to a new camera later. If you always set the white balance with a white balance picker you don't have a problem, the cameras will then produce the same look (assuming both have been profiled in the same conditions).

There's another theoretical problem which is that the profile's LUT expects that white is perfectly neutral as that is the reference point for the non-linear corrections, and if the white is tinted the corrections will be skewed. I say it's theoretical though, as any well-behaving profile makes broad smooth corrections and the error introduced with a white balance offset is considerably smaller than the overall inaccuracies in camera profiling.

However, for completeness let us look at this theoretical problem first. Say if we want to use an in-camera preset and want the profile to be perfectly calibrated for that, then there are two ways. Either you match the illuminant in the target setup with the in-camera preset so the white patch becomes 100% neutral (almost impossible without a programmable spectrum lamp), or you create a new in-camera preset (most cameras allow custom presets) that matches your target setup light. Instead of making a in-camera custom preset you could make a white balance preset in the raw converter.

You could do this, but for general-purpose photography it's way overkill, and often does not make any sense as the actual light used when shooting is probably varying (if you shoot outdoor). The only thing this matching will provide is that if the light you shoot in happen to render neutrals 100% neutral with your preset, then you know that the profile's LUT corrections will be applied as correctly as possible. But even then, it's not certain as you cannot really know if the shape of the illuminant spectrum is matching what you used when shooting the target, and of course the variability of spectral reflectance of different colors come into play too. In short, I hope it's clear that it's not worthwhile to think about that aspect.

Next let's look at the "real" problem, which is matching two different cameras when using white balance presets. The common "solution" is simply not care, let cameras differ and use a white balance picker in cases it's important to match them. Most users are pleased with this approach, and I recommend to do so unless you do have a specific need to match camera presets. However, even if you don't worry about matching cameras you may not like the tint of the built-in presets, maybe they're generating a too warm or too cool look for your typical shooting conditions. In that case you need to make your own custom preset, either in-camera or in the raw converter.

Most raw converters have their own built-in white balance presets, but it differs between them how they are applied. A camera manufacturer's own raw converter probably has the presets matched with the camera so they are the same. Third-party raw converters, like Lightroom, usually have their own fixed presets which don't match the camera's own. Using Lightroom as an example, its "daylight" setting is fixed at 5500/+10 (which by DNG/Adobe definition matches D55) and it uses the profile's matrices to figure out which actual RGB multipliers (raw white balance) that temperature/tint setting corresponds to. Will camera A and B match if using those presets? Maybe. If you profiled both cameras in the same setup and the target illuminant was (said to be) D55, then they should match for that setting, but if you change preset to say Shade (7500/+10, D75) the color matrix calculations will most likely be too inexact to make a match. To be fair, to match cameras over several presets you really need to profile each illuminant separately (or measure the SSFs), getting a match at the profiled illuminant is the best we can expect.

So for Lightroom you could profile both cameras under the same light, and tell DCamProf that it is D55 (it doesn't really need to be exactly that), then you can use Lightroom's built-in "daylight" preset and the cameras will match, but only for that preset (and light). The same method may or may not work for other raw converters using DNG profiles, depending on how the white balance handling is implemented there.

The "fool-proof" way is to make a custom preset for each camera based on white-balance picking in a fixed setup. It doesn't need to be your target setup, it can be any situation only if both cameras was shot in the same occasion. It's of course an advantage to use a fixed setup with artifical light as it can then be recreated later when getting additional cameras. A problem here is that you may not have access to a light which gives you a suitable preset, maybe you want the preset to make a warm tone in daylight, and then you need a cooler light to profile for. The solution to this is to use a target which has off-white patches (warm and cool) so you can pick and choose a tint. X-Rite's ColorChecker Passport has such patches.

You can of course also tune your presets "by eye"; pull the sliders until you are satisfied and save it as a preset. If you make the preset in-camera or in the raw converter is a matter of taste (and a matter of how well the camera supports custom presets).

With an ICC profile you can shift the neutral, so instead of making a custom preset in your camera or raw converter you can shift the neutral so the in-camera preset matches your custom white balance. DCamProf can make such profiles. It should be said it's an unusual way to approach the problem though and I don't recommend it for general-purpose profiles. DNG profiles can't shift the neutral axis so it's not possible to use them with this method.

My recommended approach to white balance presets (assuming you like to use them rather than using auto-white balance or picking white balance each time), is to either not care, letting cameras tint the way the manufacturer likes, or make manual presets by tuning by eye to taste. If you intend to leave it alone, still check if you like the tints the camera presets give you, and make custom ones if you don't like them. If you have a real need to match presets of several cameras, the best way is to use a fixed setup with an artificial light as close as possible to your desired light (so you can recall it later when getting additional cameras), and then create custom presets by white balance picking on a target. You could use a target with tinted off-white patches for greater flexibility on choosing if it should render warmer or cooler than the used illuminant.

Tone curves and camera profiles

An example image rendered with a linear tone curve using an accurate colorimetric profile. The exposure has been increased to make the image easier to compare with the others that have tone curves (as the tone curve has a strong brightening component). This image should be used as reference when evaluating accuracy of colors. However, it does look flatter than the eye experienced in the brighter real scene, which is a normal appearance phenomenon. This means that we need to apply some sort of curve even when we want a neutral realistic look. Same profile, but now with the DNG default curve, which is a modified RGB curve. Note the garish colors. Light colors are also desaturated, not so easily seen in this picture although the white shirt has lost much of its original slight blue cast. Desaturation issues can more clearly be seen in light blue skies for example. DNG uses a hue-stabilized RGB curve (constant HSL hue) so it's better at retaining hue than a standard RGB curve (which most ICC-based raw converters use). Same profile, with the tone curve applied on the luminance channel, while hue and saturation are kept constant. As luminance channel the J of CIECAM02 Jab is used here, similar to the more well-known Lab. Intuitively one may expect this to be truest to the original, but as seen it looks desaturated. This is because in human vision color appearance is tightly connected to scene contrast, so if you increase contrast also saturation must be increased to maintain the original appearance. Same profile, here with DCamProf's built-in neutral tone reproduction operator. Color appearance is now very close to the original linear curve, but we have increased the global contrast so the photo displayed on a screen appears truer to the real scene. Adobe Camera Raw's profile with the intended tone curve (same as in the others). Looks pretty natural, but some issues with saturated colors; too saturated reds and too little saturation on the purple and bright yellow-green. Additionally, skin-tones are slightly over-saturated and yellowish, and again the slight blue tint of the white shirt has been lost. While some errors can be side effects of the curve, they're mainly deliberate subjective adjustments by Adobe's profile designers with the purpose to achieve a designed "look", like film have in analog photography. DCamProf's tone-curve operator is instead designed to stay true to the color appearance of the original scene and leave subjective adjustments to the photographer. Adobe Camera Raw's profile with linear tone curve. Here we can clearly see that it's not a "scene-referred" profile. The profile has been adapted for the S-shaped DNG tone curve and is therefore desaturated. Note that comparing all these pictures may be hard directly on this web page as color shifts slightly with viewing angle. To critically compare, first download the files and then look straight at them while flipping through them in an image viewer. The images were made during development so the result from the current may differ a little, but you should from these images get an idea what the typical differences are and how large they are.

As soon as you apply a tone curve you significantly alter the look of the colors.

The well-known raw converters' tone curves don't work well with linear "accurate" profiles, but will produce garish colors.

Ignoring the effect of tone curves is what makes many self-made profiles fail for all-around use.

There is no established standard tone curve that produces neutral results as the standard color appearance models like CIECAM02 don't embrace the tone curve concept.

Applying the curve on the L channel in Lab or V channel in HSV or L in HSL all have problems. For a high end result a custom tone reproduction operator is required.

The tone curve is perhaps the most under-estimated factor in camera color reproduction. Here's why I think it deserves much attention:Per default a profile is designed to produce accurate colors with a linear tone curve. This makes sense as cameras match colors better if there is a linear conversion, especially when making a matrix-only profile which by nature is linear. In other words, a linear profile strives to make the camera into a colorimetric measurement device.

A linear tone curve is the right thing for reproduction work, for example when we shoot a painted artwork and print on corresponding media. In this case the input "scene" and output media have the same dynamic range and will be displayed in similar conditions. However in general-purpose photography the actual scene has typically considerably higher dynamic range than the output media, that is the distance between the darkest shadow and the brightest highlight is higher than we can reproduce on screen or paper.

The solution to this problem since the early days of photography is to apply an S-shaped tone curve. In analog film the curve compresses highlights and shadows about equal (a sigmoid curve), while in digital photography there's been a shift to compress highlights more than shadows, which also brightens the image about a stop or so as a side effect. This suits digital cameras better as it retains more highlight detail. The principle is the same though, that is increased slope at the midtones with compressed shadows and highlights.

The need to compress highlights and shadows is obvious (otherwise we would not fit the scene's original range on the lower dynamic range available on screen), but do we really need to increase midtone contrast? The usual explanation is that the output media has lower contrast than the real scene and thus we need to compensate to restore original contrast. While this can be said to be true for matte paper, a calibrated screen will produce appropriate contrast for midtones. It surely cannot shine as bright as the sun and (probably) not make shadows as dark as in real life, but midtone contrast is accurate. In typical workflows we adapt the image first for the screen and then make further adaptations for prints (screen to print matching is a separate and well-documented subject), so when it comes to camera profiles comparing with screen output makes most sense which we will do here.

If we increase the midtone contrast with our tone curve, we will exaggerate. For a typical curve type this is mainly seen as increased saturation, as increased contrast separates the color channels more which leads to more saturation. Okay, so this is wrong then? Well, it's not that simple. Let's say we display a shot of a sunny outdoor scene. Although midtone contrast on the screen can be rendered correctly, the overall luminance is much lower. This makes the Stevens and Hunt color appearance phenomena come into play, that is the brighter a scene is the more colorful (=saturated) and contrasty it appears. That is to make the displayed photo appear closer to the real scene we need to increase both lightness contrast and colorfulness, which an S-shaped tone curve does for us.

So then all is good with the tone curves applied by typical raw converters? No. In fact if we're into a neutral and realistic starting point it's not good at all. Most converters apply a pure RGB curve which has little to do with perceptual accuracy. Lightroom and many DNG raw converters apply a slightly different RGB curve that reduces hue shift problems (HSV hue is kept constant), but it's still in most situations almost identical in look to a pure RGB curve. It varies between converters in which RGB space this curve is applied, which also affects the result. In Lightroom/DNG it's always applied in the huge linear ProPhoto color space, while in many ICC raw converters it's applied in a smaller color space.

Let's start with the RGB tone curve problems. It will increase saturation more than is reasonable to compensate for Stevens and Hunt effects, so you get a saturated look. You might like that, but it's not realistic. Another problem is that for highly saturated colors one or more channels may reach into the compressed sections in highlights or shadows and that leads to a non-linear change of color, that is you get a hue shift. Typically the desired lightening and desaturation effect (transition into clipping) masks the hue shift so it's not a huge problem, but it's there.

Then there is the color space problem. If the RGB tone curve is applied in a large color space such as one with ProPhoto primaries (like in the DNG case) one or more channels can be pushed outside the output color space (typically sRGB or AdobeRGB) so we get clipping and thus a quite large hue shift. Some raw converters partially repair this through gamut mapping (Lightroom does), but still there may be a residual hue shift.

To battle the various RGB tone curve issues bundled profiles typically have various subjective adjustments to counter curve issues. For example the profile may desaturate high saturation reds to avoid color space clipping. Naturally this means that the same profile used with a linear curve will produce too little saturation in the reds. That is a profile must be specifically designed for the intended curve.

I think this is bad design. In fact one could argue that staying with RGB curves (and similar) has inhibited the development of good profiling tools and makes it unnecessarily hard to get natural colors in our photos.

It doesn't have to be this way, the RGB tone curve is legacy from the 1990s when its low computational cost was one of the reasons to use it. It can also be seen as a nostalgic connection to film photography. In the film days the film had to produce the subjective look too, so exaggerated contrast and saturation were desirable properties. This thinking has been kept in most raw converters today despite that we have all possibilities to start from a neutral look and design our own on top rather than relying on bundled looks. The RGB tone curve produces a saturated look that many like to have in their end result, but as said it still doesn't work well for profiles that aren't specifically adapted for it.

Using a DCamProf neutral linear profile and applying and RGB tone curve will produce a garish look. As we will see, the solution to this problem is to use DCamProf's built-in neutral tone reproduction operator.

Tone reproduction operators

In the research world the problem of mapping colorimetric values from a real scene to the limited dynamic range on a screen or print is well-known and is the subject for many scientific papers. The scientific term for the "tone curve" that compresses the dynamic range to fit is "tone reproduction operator", and can instead of a simple global tone curve be scene-dependent and spatially varying, what we in the photography world call "tone mapping".

In science the goal is generally to make an as exact appearance match as possible, for example if we have shot a scene in very low luminance level (at night) also the eye's night vision with its limited ability to register color is modeled. Modeling all aspects of human vision at the scene and at reproduction is a complex problem and is still a very active area of research.

Current raw converters are not designed for this type of advanced appearance modeling and it's generally not what a creative photographer is interested in. For example, in night photography we typically want to make use of the camera's ability to "see" more saturated colors than our eye can.

There is a middle way though. While we do want to increase contrast and don't really mind that it will be more than realistic for scenes not shot in bright sunlight, RGB tone curve color shifts are not beneficial. That is the tone reproduction operator we want for general-purpose photography is a basic S-shaped tone curve just like in traditional photography but without color shifts. This middle way has not got much attention in the research world though. Once computers got powerful enough researchers moved away from the "simple" tone curve models into tone mapping.

While tone mapping is useful in many cases, it's better handled separately in practical photography. It doesn't replace the need of a tone curve-based operator, it's just a complement. Due to the lack of research there is no established operator with the desired properties though, so I had to come up with an own for DCamProf.

DCamProf's neutral tone reproduction operator

With DCamProf I've chosen the approach to render accurate neutral linear profiles (scene-referred), and then develop a new spatially uniform tone reproduction operator that doesn't have the hue shift and over-saturation problems of the commonly used RGB curve. This means that the profile can be developed just like a "reproduction profile" and no subjective tuning is required to adapt for the RGB curve's issues.

This operator can be applied when generating a DCP or ICC profile so you can achieve the intended look in your raw converter.

It has the following properties:

Luminance is the same as a DCP tone curve applied in linear ProPhoto space This means that the contrast and brightening will be the same as a standard DCP/RGB curve, so you can use the same curve shape. Exception: for high saturation colors (flowers etc) a pure luminance curve is blended in, as it has better tonality.

The contrast (the curve shape) is a subjective choice made when generating the profile. Typically one chooses a contrast that looks realistic for bright sunny outdoor scenes, and thus exaggerates contrast for other scenes, which generally is desirable in terms of subjective look. If we'd want a realistic contrast curve for all types of scenes the curve would have to be scene-specific, and then the raw converter would have to work with linear profiles and apply curve itself. However, most raw converters are designed for profiles that have a fixed curve applied.

Hue is kept constant. Small exceptions to this rule close to clipping in some color ranges to improve smoothness of gradients.

The contrast of the curve is measured and the saturation is adapted accordingly so the perceptual impression is that saturation is kept constant. Higher contrast needs higher saturation, otherwise the image would look desaturated.

Highlights are desaturated (less so than in an RGB tone curve though) to make a nice transition into clipping.

Non-linear elements are used where it adds perceptual accuracy, but the algorithm has been kept as simple as possible.

Compared to an RGB tone curve this operator increases saturation less and minimizes hue shifts.

ntro_conf.json

Many of the parameters (weights) in the operator can be tuned. Most will be satisfied with the defaults weights, but if you like you can change them by providing a configuration file. See thefile in the data-examples directory for a documented example (the file contains the default weights).

The operator makes no local adjustments, and as it's just a part of a camera profile it can't do that anyway. This means that only the curve is analyzed for contrast, and as an image can vary in contrast locally (for example a large flat blue sky has low contrast even if the curve is a steep S-curve) also the eye's perception of color vary a little over the image surface, and thus some areas may receive a bit too much saturation or too little. This is not a large problem, but something to be aware of when evaluating results.

DNG profile implementation notes

When making a DNG profile the operator is implemented through the LookTable and curve. So if you strip away the LookTable and curve you have the pure colorimetric profile left.

The DNG profile LUTs are not as flexible as ICC LUTs, most notable is that you cannot alter grays, not increase saturation or change lightness (value). As the LUT works with multipliers on saturation it's logical that you cannot increase saturation from zero. However, it's not logical that value cannot be scaled. Some DNG profile implementations support scaling grays (as the LUT itself does support), but the public DNG reference code as well as Adobe's products ignore the value multipliers for gray and instead set them to 1.0, that is no change.

This means that you cannot implement a curve directly in the LUT, as grays cannot be darkened or brightened (which a curve requires). The workaround is to embed a DNG tone curve (which can scale grays), predict the result of that curve and reverse the undesired effects to get the intended result. This is how DCamProf does it. There is one potential problem though: it's not specified in the DNG specification how the tone curve should work, so there may be raw converters out there that does not use Adobe's hue-stabilized RGB curve variant and if so you will not get the desired output.

If you come across such a raw converter (unlikely) and want to use this tone reproduction operator, please let me know.

(So how does actually Adobe's tone curve work? It's an RGB curve where the tone curve is applied on the largest and smallest value, and then the middle value is adapted to keep a constant hue as defined by RGB-HSL/HSV. In terms of look and saturation increase it's very similar to a pure RGB curve, more so than a HSL-L curve or HSV-V curve, but some color shift problems are avoided.)

The LookTable will in DCamProf's profiles per default be gamma-encoded for the value divisions, this will make perceptually better use of the range (that is higher density in the shadows) meaning that the default 15 value divisions should be enough for most curves. Some older or simpler raw converters may not support the gamma encoding tag though, and if so you can disable it.

In any case will DCamProf's DNG profiles with the neutral tone reproduction operator applied be quite large in size. There is no way around that as the DNG profile format is not designed to be space efficient for profiles that do not embrace Adobe's RGB-centric idea of camera color.

Verifying tone reproduction accuracy

Once you have applied a curve you can no longer do normal automatic delta E comparisons to check for accuracy. By definition a curve adds a lot of lightness "errors" as it applies contrast, and we also add saturation "errors" to perceptually compensate for the increased contrast. The one-to-one delta E comparisons only work for linear profiles.

There are no readily available color science models top help us out here, so the only method at hand is to verify by eye. To do this you make a linear profile that can be measured for accuracy and use that as reference. Then make two copies of each test image, one with the linear reference profile applied, and one with the curve. Then you make A/B swapping to compare these images. It's important to do swapping and let the eye adapt for a couple of seconds, if you would compare side by side the eye will be confused by the two different contrast levels displayed simultaneously.

Check that individual hues seems to be the same and look globally and see if saturation seems to match. If you look closely on one isolated color without seeing the global contrast, saturation should be a little higher for the curve profile.

A photograph with faces in it is one good reference point, as our eyes are very good at detecting subtle differences in skin tones. I also recommend testing a sunny outdoor landscape scene, where you can check if the applied contrast is suitable: look globally and get a feel if the scene looks as contrasty as in real life but without exaggeration. Check if the color of the blue sky seems right, hue shift of light tones is typical for simpler curves.

I also recommend testing a photo with various high saturation colors which you can find in flowers naturally or as artificial colors for example in toys or sports clothing. High saturation testing is a bit difficult as you can run into color space clipping. Using a wide gamut screen will certainly not hurt in this case.

As mentioned in the description of DCamProf's neutral tone reproduction operator camera profiles are limited by that they can only apply a global adjustment, and thus not make any local adjustments adapted specifically for the image content. Keep this in mind when evaluating the result.

Scene-referred versus output-referred

You have probably heard or read that "DNG profiles are scene-referred and ICC profiles are output-referred", and in the next sentence it's said that scene-referred is better. What does this mean?

A scene-referred camera profile simply means that the purpose of the profile is to correct the colors so the output represents a true linear colorimetric measurement of the original scene. In other words we want the XYZ values for the standard observer, or any reversible conversion thereof. That is what we in daily speak would call an accurate linear profile (where linear means "no tone curve", we can still employ a LUT for non-linear correction), which DCamProf makes per default.

An output-referred camera profile should instead produce output that can be directly connected to a screen or printer ICC profile and produce a pleasing output for that media. As discussed, for cameras this means in practice that there should be some sort of tone-curve applied to get a pleasing midtone contrast and compressed highlights. In other words if the camera profile converts to XYZ space, those XYZ values should already have the curve applied and also any other subjective adjustments.

It's true that the ICC standard is written such that it expects camera profiles to work this way. However, raw converters that use ICC profiles don't necessarily follows this intention. Some let the ICC profile make a scene-referred conversion, while some makes some sort of mix between scene-referred and output-referred (let it do subjective color adjustments, but not apply a curve), and only a few do it the ICC standard way and make the ICC profile fully output-referred.

While DNG profiles can be 100% scene-referred, they can also have a "LookTable" LUT and/or a tone curve which are subjective adjustments for output, effectively making the profile output-referred. Adobe's own profiles have these type of adjustments, and are thus output-referred.

Due to these variations of how the profile formats are used I think the scene-referred versus output-referred discussion is a bit confusing. DNG profiles supports both things natively and ICC profiles do it in practice depending on raw converter design.

To support all-around use of scene-referred profiles the raw converter must have a type of tone reproduction operator that can change contrast without distorting color, otherwise scene-referred will only make sense with the linear curve. None of the big name raw converters have such an operator but instead require profiles to be adapted for a curve if you want realistic color. This is why DCamProf supports applying its own tone reproduction operator directly in the profile.

Tone curves and matrix-only profiles

To compensate the negative color shift effects of an RGB tone curve the profile needs to make non-linear adjustments. This is not possible with matrix-only profiles as they by nature are 100% linear. However, a matrix profile made to match a matte target, such as the classic CC24, will most likely produce too low saturation of high saturation colors, and will thus produce a less garish look together with an RGB tone curve than a colorimetric LUT profile would (which can accurately reproduce high saturation colors as well).

It's generally not a good idea to try to get good match of high saturation colors for a matrix profile in any case, as that will reduce precision of the more important normal range of colors. That is a good matrix profile is generally a bit desaturated and therefor works okay (although not perceptually accurate) together with an RGB tone curve in most circumstances.

DCamProf does not provide any functionality to adapt matrix-only profiles for tone curves, so if you intend to use your matrix profile with an RGB-like curve make sure you design it with not too high saturation colors.

The look of over-exposure

Digital cameras clip the raw channels straight off when over-exposed which may not result in a pleasing look, even together with a roll-off in the profile's tone curve. To handle this some raw converters renders over-exposed shots differently, to mimic how over-exposed analog film looks, meaning that further lightening and desaturation is applied.

This special rendering mode of over-exposed images is not standardized and cannot be controlled by the camera profile. There should be no need to do so either, but it's good to be aware of this if you compare output of the same camera profile in two different raw converters. If the shot is over-exposed the raw converter itself may affect the look. Naturally if you lower exposure of a clipped image the raw converter's highlight reconstruction algorithm will affect the look, which also is outside the control of a camera profile.

Chromatic adaptation transforms in camera profiling

If the light of a scene changes from say a blueish daylight (D65) to a reddish tungsten (StdA) and we give some time for our eyes to adapt the colors will still look approximately the same. This is the eye's chromatic adaptation, and the phenomenon that colors appears the same when viewed under different lights is called "color constancy".

However, the eye is only approximately color constant, that is some colors will appear slightly different under the new light. In color science the chromatic adaptation behavior of the eye/brain has been tested with various psychophysical experiments where test persons match colors under different lights, in order to find "corresponding color sets". The corresponding color under a different light can be a different sample, which is an example of "color inconstancy".

These experiments have then served as basis when developing chromatic adaptation transforms, CATs, mathematical models of the human vision's chromatic adaptation behavior. A CAT thus models both the color constant and the inconstant parts of adaptation.

A CAT does the following: provided a CIE XYZ tristimulus value under a source illuminant, predict what the XYZ tristimulus value should be under a destination illuminant that provides the same color appearance. The illuminants are given as whitepoints (white as tristimulus values), so the CAT does not need any spectral data.

In camera profiling a chromatic adaptation transform is needed when the calibration illuminant is different from D50. The reason for this is that the profile connection space is always D50 (for both ICC and DNG profiles), that is the color rendering pipeline in raw converters need the profile to output colors relative to D50, which then can be converted further to colors for your screen or printer.

If the profile is made for say tungsten light (StdA, 2850K) we then need to convert those XYZ coordinates to corresponding colors under D50. This can be made with a CAT, and the current best for these tasks is the CAT coming with the CIECAM02: CAT02. However, the CAT is still far from perfect. There are challenges concerning the accuracy of the experimental data they are based on, and the experiments cover only a limited illuminant range (usually StdA to D65) and limited range of colors. In addition are the CATs designed with various trade-offs to make them easier to use mathematically. And finally, these transforms work on tristimulus values only, of both colors and illuminants. Any knowledge of spectral information won't contribute.

"Relighting" transform

There's also another type of chromatic transform which sometimes is needed in camera profiling. Let's say we have the XYZ value under D50 for a test target patch, and we want to predict which XYZ signal we will get from the same patch lit under StdA. That is we're relighting the patch. If we have the reflectance spectrum of the patch and the destination illuminant it's straight-forward: we just calculate the new XYZ values the normal way with spectral integration.

However some reference files provided with commercial test targets only have XYZ coordinates, and if we don't have a spectrometer to measure the target ourselves then we need to make a transform without having any spectra at hand.

This transform is not the same as a CAT. A CAT finds a corresponding color and models the color inconstancy aspects of human vision. However, as human vision is approximately color constant many software applications use a CAT anyway when a relighting transform is called for, and there's not much else to do as the established color appearance models don't provide any other transform. There is no standardized name for the "relighting transform" which means that CAT is sometimes used in the literature also for this which causes some confusion. In this documentation the term "relighting transform" will be used.

With DCamProf there is a better alternative for relighting than using a CAT. If the reflectance spectrum is missing DCamProf can generate a virtual spectrum which matches the given XYZ coordinate, and that spectrum can then be lit by any illuminant. Of course the rendered spectrum will not exactly match the unknown real spectrum, but tests made on various sets show that for most colors this method outperforms both Bradford CAT and CAT02. Rendering virtual spectra often gets you within 1 DE from the correct answer, while the CAT is often in the range 2-4 DE.

Performance of CATs

The performance of a relighting transform is easy to verify as long as you have spectral data, and there are plenty of databases with various spectra to run tests against.

With a CAT the only data to verify against is the correlated color experiments made, and CAT02 generally wins when it comes to the established models. However, as discussed all of these models are rather approximate, and the question arises that maybe they introduce more errors than they fix? A CAT02 conversion from StdA to D65 will have about 3-4 DE on average compared to the correlated color set experiments. Performance is probably not so good outside the StdA to D65 range as the reference experiments don't cover a wider range than that.

It would be most interesting to compare CAT with simple spectral relighting, as the latter is usually available when profiling. When using the relighting transform as a CAT we assume perfect color constancy, which indeed is wrong, but on the other hand the error will be no larger than the range of color inconstancy, which presumably is quite small. Unfortunately the correlated color experiments don't have spectral data so there is no way to make this comparison. What we can see though is that relighting is about 3 DE on average from CAT02, with up to 6-7 in saturated reds and yellow-greens.

From these results a fair guess is that a CAT is indeed better at predicting the color inconstancy aspects of human vision than just keeping perfect color constancy (that is do relighting from spectra), but also that relighting may be more robust and may have smaller appearance errors in some ranges.

When are CATs and relighting used?

If you make a D50 profile and have D50 XYZ target reference values no CAT or relighting is required. If you like you can make a D50 profile even if the actual light used when shooting the target is not D50. What then will happen is that the color appearance will be as if lit by D50, but the profile will only work as intended in the light used at shooting time (if you make a DCP it's light temperature estimation will be off too, but that does not hurt performance in any way).

DCamProf needs target reference values as illuminated by the calibration illuminant (= the light the target was shot under). Why? There are two reasons, one is to calculate the color matrix which is used in DNG profiles to estimate light temperatures, and the other is to know the color appearance under that light so we can using a CAT get corresponding colors for D50, used in the profile connection space where color correction takes place.

The reference file tristimulus values are often calculated for D50 and as soon as our calibration illuminant is different from that a relighting is required. If spectra is available in the target file this is done by spectral calculation which yields accurate results. If spectra is missing a relighting transform ha