Camera Profiling - DNG, ICC and alternative methods

[solarj]

Writing this in response to solarj. DNG profiles can contain the following tables, but not profile building/editing software fill all table values.

1. CameraMatrix1
2. CameraMatrix1
3. ForwardMatrix1
4. ForwardMatrix2

If the raw converter follows the DNG spec in the way it handles DNG profiles, it will use the ForwardMatrix table values instead of the CameraMatrix table values. If the Forwardmatrix is not included (table values =0) then a rather convoluted method is used to map colors.

Some of my test result:
1. remove all the matrices --- dcp won't show up in the profile list
2. keep only CM1 --- dcp works
3. keep only FM1 --- dcp won't show up in the profile list

X-rite software generated profile contains CM1 and a LUT, by removing LUT and use ACR RGB primaries adjustment, I can achieve enough accuracy with a linear tone curve that you recommended, so currently I'm satisfied with this non-LUT approach for daylight shootings ranging from 5000K to 8000K

But I am still confused by a quesion: Do you need different matrices for different lighting? How is that calculated?

Take 3000K flourescent light for example, the light emission is very different than daylight. Under such a lighting, I can imagine that the color checker spectrum response will be very different, so standard D50 Lab value will not match. But since we do not have reference values for color checker under such a lighting, how could we calibrate it? Is there some hidden reference value inside profile making software when it make dual-illuminant profile? How could it tell it is a flourescent light or a incandescent light?

[digitaldog]

Andrew, thank you very much for doing the comparisons in CTP. They are very helpful in visualizing the color differences.

Should we make anything out of the dE values in terms of the lowest being a custom DNG profile?
2nd place appears to be a custom ICC profile? If so, can you comment on the ease of building both sets and if they are easily transportable to other raw converters that support them?

In the data I sent you, I did a version whereby I blurred the Macbeth's and the results are about the same in, obviously the dE values are different (less) but the order presented here is the same.

[Hening Bettermann]

Is it OK to go on discussing ColorPerfect in this thread?

@ Samueljohnchia

> I also disagree wholly with the results I am getting from ColorPerfect's "scientifically correct" method of saturating images, and I find Joseph Holmes's color variants to be far superior in many ways, not just the visible results.

I don't understand what you mean by this. In my current workflow, I never touch the saturation sliders. Is there any need for it as long as you go for a "natural" saturation? How would you define a "natural" saturation after the color profile, white balance and tone values are in place?

In Davids texts, I could not find a place where he writes about saturation, so I assume, your objection is based on visual results rather than theoretical grounds.


@ solarj

> But I am still confused by a quesion: Do you need different matrices for different lighting? How is that calculated?

I think the ColorPerfect theory has an answer to this:
The camera is constant, it can be profiled in constant light with a gray scale alone. The illumination is changing from image to image - this is a job for the white balance, not the camera profile.

There is also another problem: Now you have profiled your camera, the image of the CC looks fine. But on a real world image, the next steps would be multiple (tone) edits done in ProPhoto or Lab. How accurate are colors after these edits? CP promises, via the "Alpha Feature", to restore "color integrity" after tone edits done in the carrier application (Photoshop or PhotoLine). I have not tested this yet though.

[samueljohnchia]

Some of my test result:
1. remove all the matrices --- dcp won't show up in the profile list
2. keep only CM1 --- dcp works
3. keep only FM1 --- dcp won't show up in the profile list

If you remove the CameraMatrix, it would no longer be a valid DCP profile...

But I am still confused by a quesion: Do you need different matrices for different lighting? How is that calculated?

Take 3000K flourescent light for example, the light emission is very different than daylight. Under such a lighting, I can imagine that the color checker spectrum response will be very different, so standard D50 Lab value will not match. But since we do not have reference values for color checker under such a lighting, how could we calibrate it? Is there some hidden reference value inside profile making software when it make dual-illuminant profile? How could it tell it is a flourescent light or a incandescent light?

The camera colors will be chromatically adapted to D50. The DNG PE and QPcalibration uses Bradford. I believe X-rite should too, but I have not been able to confirm. It "tells" by doing a white balance from the second lightest neutral patch and getting a CCT value. It will not know the lighting. If you choose "2850 K only" in the DNG PE, it will assume Std Illuminant A. If you choose "6500 K only", it will assume D65. The profile has the illuminant tags. QPcalibration uses only D50 should be tagged accordingly. I helped the engineer discover an illuminant tag error - it should be 23 (D50), not 21 (D65) in the profile. Not sure if they have updated QPcal yet.

The complex LUT's that you dislike will help deal with weird spectral behaviour that the matrices alone cannot tame on their own.

I also realised the wonderful advantages of the DNG PE using the same base matrices for all the profiles it produces, or "edits", if you prefer. It allows one to use the same white balance settings in ACR/Lightroom and switch between different profiles, and all the neutrals will remain neutral. A huge benefit! If the matrices were to change, then a great deal of conscious effort has to be made to ensure that a new proper WB is set, for every single profile change. This is a BIG issue. If unaware, a user might think that a particular profile has a color cast, when actually it is just a different CCT in the profile input reference.

[samueljohnchia]

Should we make anything out of the dE values in terms of the lowest being a custom DNG profile?
2nd place appears to be a custom ICC profile? If so, can you comment on the ease of building both sets and if they are easily transportable to other raw converters that support them?

In the data I sent you, I did a version whereby I blurred the Macbeth's and the results are about the same in, obviously the dE values are different (less) but the order presented here is the same.

Andrew, I'm not sure if I can adequately comment fairly on this matter.

The DNG profile that you ranked tops has not just the camera matrices but also a relatively high resolution LUT. The ICC profile is only a simple matrix profile, with a linear gamma tone curve. I would actually say that the ICC profile is better than a DNG profile with its LUT stripped off!

I'm not sure how a LUT ICC profile will behave. A few respected experts have warned to stay away from that if using a small patch target. It might be better, but it quite likely might be worse.

Creating a great ICC profile can be as easy as a DNG profile, if you have taken the time to set up your workflow with Argyll. I already posted the code that I used so anyone can just take it and punch it into a command line interface program, after downloading Argyll. You will also need another line of code to get Argyll to sample from the photo of the target and create a measurement file to build the profile from. The wonderful thing is that you can know what reference values Argyll uses, and modify that reference file to your own custom values. This is great if you have a good spectrophotometer and you use only one CC target for all your profiling. Otherwise averaged reference values like Danny Pascale's ones are fine. You can also create your own reference for a new target that Argyll does not have the reference file for. Unlimited control! If one is hindered by dealing with code, Raw Photo Processor has a GUI for camera profiling with Argyll. I haven't tested the consistency of Argyll's profile building process. The patch detection is automatic and so far my tests of other auto-detecting camera profiling software has shown it to be very consistent. That is, the profiles tend to end up almost exactly the same.

The DNG PE however, requires some manual user interaction by placing the control points on the corresponding color patches. It is very very sensitive. I have gotten errors like: "Non-neutral gray patches. The gray patch in row 4, column 3, has a significant color cast. Please re-shoot the chart carefully to avoid color casts and try again." Then a small shift of the control points and a perfect profile is produced, no errors. It is quite a weird one. It is always this particular gray patch that it thinks is different. Tried two different colorcheckers. Tried different kinds of lighting. When a non-neutral warning appears, always this patch is the problem. I've also gotten overexposure warnings when the actual values in the white patch are not clipped. Again slight tweak of the controls and perfect profile again.

One of the problems with ICC profiles in the beginning is that the white point of the profile would be too low, because the white patch in the target isn't exposed as pure white, and it shouldn't. Unnecessary loss of highlight headroom was one of Adobe's arguments for DNG profiles. No longer is that an issue with scaling the white point for an ICC profile. I've yet to test how well ID handles highlights with DNG vs ICC profiles, but I think it should be quite similar now.

I haven't seen a single illuminant DNG profile that can adequately map a CC's values when the CCT of the light, assuming it has smooth spectral transmission, is different by 3000k or more. That's why I made warm daylight profiles for sunrise and sunset. Regarding the ability of DNG profiles to be able to describe a wide variety of lighting, a dual illluminant profile has greater success, for the average untrained eye. If the temperature slider in ACR/Lightroom is set between 6500K and 2850K, as it often is required for pleasant rendering of white balance across a wide variety of scenes, the profile would be subtly wrong, because it must interpolate from both illuminant tables. A 5000K daylight shot of a CC ends up being slightly less accurate than a well made single illuminant profile. Likewise for a 3850K warm daylight CC photo.

I've had great success bringing over an ICC profile I made for ID into RT. It renders the CC values quite well - the evidence is in the second tif file I posted. Surprisingly, the DNG profile in RT was a disaster because I suspect that RT is not supporting the latest DNG spec properly. Nothing to do with the flexibility of the format here, or the fact that it was built from scene rendered data, not raw converted output data. Raw converter software engineers will have to keep up with the changing DNG specs.

[samueljohnchia]

The illumination is changing from image to image - this is a job for the white balance, not the camera profile.

Hening, white balance alone will not help in metamerism issues for illuminants with a spiky spectral output. The camera profile can have a role to play here. I do not yet have enough color science knowledge to understand or prove how a camera profile destroys "color integrity". I have seen evidence of bad color mapping, non-smooth profiles etc. I also have seen when camera profiles are fantastically wonderful for getting color relationships to where they should be.

Is it OK to go on discussing ColorPerfect in this thread?

@ Samueljohnchia

> I also disagree wholly with the results I am getting from ColorPerfect's "scientifically correct" method of saturating images, and I find Joseph Holmes's color variants to be far superior in many ways, not just the visible results.

I don't understand what you mean by this. In my current workflow, I never touch the saturation sliders. Is there any need for it as long as you go for a "natural" saturation? How would you define a "natural" saturation after the color profile, white balance and tone values are in place?

In Davids texts, I could not find a place where he writes about saturation, so I assume, your objection is based on visual results rather than theoretical grounds.

David's website is as convoluted as CP's UI. It is not surprising that you cannot find it. I spent considerable time reading his literature and getting lost in the site before this caught my attention. Here you go.

"This may be the first saturation adjustment to have a sound basis in physics and physiology and we believe the difference in purity of color will be obvious to most people."

I have no further comment except that I greatly dislike the way ColorPerfect saturates colors. Yellows are significantly saturated more than the other hues, the very same problem that the saturation slider in ACR/Lightroom or Photoshop has and I want to stay away from! Vibrancy has the exact problem with the opposite hue, blue. In contrast, Joe's color variants are simply brilliant. And most importantly, easily reversible. This is a major issue with ColorPerfect's workflow. This is personal preference, and since you don't touch that slider anyway, no problem!

I have the need to increase or decrease saturation quite often for my work. Increasing the gradient of the tone curve in ACR/LR by more than 1 results in a saturation increase. I might want to tune it down. I get robbed of saturation when I reduce the curve's gradient to less than one. Almost all the time you have both issues in a single curve, because steepening one end flattens another. Dealing with that is not so easy.

I don't know how I would define "natural saturation". Its like asking what is natural sharpness? We all will have a different tolerance for that. Show me two examples, I can pick one. Defining is just much harder. Editing to your mind's visualization in the end is far more important than attempting an exact match. I never expected or demanded exact color reproduction when I started making custom camera profiles. I wanted better relationship of colors to each other. I am convinced that I have that, more-or-less, with my carefully made profiles.

[Vladimirovich]

Creating a great ICC profile can be as easy as a DNG profile, if you have taken the time to set up your workflow with Argyll.

RawDigger 0.9.15 (RC1) can generate CGATS that you can  feed to Argyll and it now can correct uneven target illumination

it is not yet public on rawdigger.com, but you can get it from the developer (code) blog (http://blog.lexa.ru/)

[Hening Bettermann]

Hi

I asked Brian about the option 'Use embedded curves' in ID, and his answer evolved into a detailed article on the color processing pipeline in ID for ICC and DNG profiles respectively. He has authorized me to post it here. The zip is a digest of the e-mail exchange.

The item that caught my attention was that the zero point of the Shadow Fine Tune slider on the 'In' panel changes its meaning in case you use Adobe DNG Camera Profiles AND the embedded (or default Adobe DNG SDK) camera curve. In this case, you have to set the slider to +100 instead of 0 to get a linear curve.

Best regards - Hening.

[Vladimirovich]

He has authorized me to post it here. The zip is a digest of the e-mail exchange.

may be still post as a text to make it available for a search, even if that will 2-3 postings ? $0.02

[Hening Bettermann]

I ask the moderators to hear their view.

[Christopher Sanderson]

I see no problem if the authors' permission was obtained.

[Hening Bettermann]

but

"The message exceeds the maximum allowed length (20000 characters)."

[Vladimirovich]

but

"The message exceeds the maximum allowed length (20000 characters)."

that is why I suggested to split in 2-3 postings, based on the logical flow of the conversation there... not in one

[samueljohnchia]

Is it OK to go on discussing ColorPerfect in this thread?

Hening, I realised that I didn't explicitly say that I'm happy to discuss further about ColorPerfect in this thread. My statement that I have "no further comment" was not intended to shut off discussion, but rather because I didn't want to head into a massive war about which saturation tool is the best. We can certainly look further into CP and discuss about the way it preserves "color integrity"!

The item that caught my attention was that the zero point of the Shadow Fine Tune slider on the 'In' panel changes its meaning in case you use Adobe DNG Camera Profiles AND the embedded (or default Adobe DNG SDK) camera curve. In this case, you have to set the slider to +100 instead of 0 to get a linear curve.

Thank you for sharing this valuable information, and thanks to Brian who took the time and effort to craft his detailed reply. It certainly helps in the discovery of the behavior of sliders in these raw converters. With all due respect to Brian, his suggestions of how the shadows slider works do not agree with my usage. Leaving the shadows slider at 0, matches the Blacks slider of ACR/LR PV 2010 at 0. Not at +100.

I re-did some tests in ID again, with a custom white balance temperature of 5405, tint 13, (In Tab) TC Shadow - None, Highlight - None, and all other sliders zeroed and the Camera Curve linear (remove all points). I had Exposure set to +0.36 or -0.06, to get as close a match to the white patch's brightness as I could.

I tested my DNG profile with and without the embedded tone curve of the DNG profile, with Shadow Fine Tune at 0 and 100, and also one more where I tweaked the Camera Curve using an input of 199 to an output of 255, without the embeded tone curve. Take a look at the results and compare to the ACR version:

ACR Exp +0.06, all settings including blacks zeroed, tone curve linear


1. Exp +0.36, Shadow Fine Tune "0", Use Embedded Curve Unchecked


2. Exp +0.36, Shadow Fine Tune "100", Use Embedded Curve Unchecked


3. Exp -0.06, Shadow Fine Tune "0", Use Embedded Curve Checked


4. Exp -0.06, Shadow Fine Tune "100", Use Embedded Curve Checked


5. Exp 0, Shadow Fine Tune "0", Use Embedded Curve Unchecked, Camera Curve Input:199 Output: 255 This should be identical to 1.


My recommendations at this point would be to uncheck Use Camera Curve for DNG profiles, and to leave the Shadow Fine Tune slider at 0. Using exposure or the camera curve to set the white point for the target is essentially the same, except for when there is clipping, so we don't have to worry about that for color target photos - because you won't use one with clipped patches!

[samueljohnchia]

Here is a crop of a dark shadow region, showing the issue more clearly:

[Hening Bettermann]

Vladimirovich,
I feel that splitting the text on multiple posts would be circumnavigating a forum rule which I find well motivated. So I think I'll leave it with the zip. Thanks for your consideration of the searchability though.
Kind regards - Hening

[Iliah]

RawDigger 0.9.15 (RC1) can generate CGATS that you can  feed to Argyll and it now can correct uneven target illumination

it is not yet public on rawdigger.com, but you can get it from the developer (code) blog (http://blog.lexa.ru/)

You are jumping the gun a little here There is a couple of unfinished things in that code, no robust mean yet, and the operations for setting max and flat field normalization are better swapped.

[l_d_allan]

This is why we need testing. I want to see the proof in all this. Who is right? Is what I am seeing all an illusion?

I've been trying to get Roger Cicala interested in quantitative measurements of sensor variability (as reflected in HSL adjustments for camera profiles from .dng's of test targets like the CCSG. He's the founder of LensRentals with 100's ... 1000's? ...  of camera bodies ... writes blogs full of numbers and charts.

He seems interested to the extent of willing to work with someone with experience and expertise in this arcane specialty (which ain't me).

[samueljohnchia]

I've been trying to get Roger Cicala interested in quantitative measurements of sensor variability (as reflected in HSL adjustments for camera profiles from .dng's of test targets like the CCSG. He's the founder of LensRentals with 100's ... 1000's? ...  of camera bodies ... writes blogs full of numbers and charts.

He seems interested to the extent of willing to work with someone with experience and expertise in this arcane specialty (which ain't me).

Allan, that's great. I've been closely following Roger and his lensrentals blog. Epic stuff. I would be interested to help, but I don't know any more about this stuff than the average guy. I don;t know how to read the source code for ArgyllCMS and tell you how Graeme Gill has chosen to build an input ICC profile for a given argument, and how or why other vendors do it differently and the potential issues of certain methods of dealing with the complex way color mapping is calculated. The Adobe method is secret, but X-rite and QPcard have found brilliant engineers to figure the math out.

Quantitative measurements of sensor variability is not hard with the right tools like a monochromator. This guy may have the expertise and tools to help.

I'm wondering what are we going to do then after proving that the spectral response of cameras do differ unit to unit.

[samueljohnchia]

Hening, what do you think of the results of my test with the various settings in Irident Developer? Have I misinterpreted Brian's comments on how settings work?