DNG profiles, Calibration tab vs. HLS

thedigitaldog wrote:

 

The question is, what are the practical implications of “calibrating” via a target that affects HSL sliders instead of producing a DNG profile, or at the very least, altering the calibration sliders? Eric you out there bud?

I'm not Eric (not sure he would want to respond to this question) but I'll take a stab...first off, let me state that I haven't personally tested either the  SyderCHECKR PRO color target or the software. I've only watched the video and read the user manual. But I do have some issues regarding usability and the "practical implications" of using the HSL Sliders vs a DNG profile.

There is one major implication–the SpyderCheckr produces a preset using the HSL adjustments rather than a DNG profile. I have no understanding (and haven't heard the rational) why Datacolor chose a Lightroom or Camera Raw preset instead of a DNG profile. But the first problem with creating "presets" is Lightroom and Camera Raw don't share "presets". So, unlike a DNG profile which will work in both Lightroom AND Camera Raw, the Spyder solution is application specific. The other major issue is that presets are not easily transportable compared to DNG profiles which actually get imbedded in a raw file. I have no reason to suspect that the HSL adjustments of Lightroom and Camera Raw CAN'T handle the color corrections needed for calibration, but the fact that the calibration depends on a "presets" limits its usefulness.

What is also not mentioned in the videos nor the manual is what the user is supposed to do regarding the starting DNG profile. Does Datacolor suggest using Adobe Standard or some other DNG profile? I ask because the HSL calibration applied as a preset depends upon the DNG profile used to create the color sample file and adding a calibration on top of an existing DNG profile seems to complicate the whole calibration process. When using DNG profiles, it's pretty straightforward what the DNG profile creation is actually doing. Adding an HSL adjustment on top of an existing DNG profile adds complexity to the process and reduces the portability of the camera calibration.

The documentation seems to imply that both DNG Profile Editor and X-Rite's Passport solution somehow limits the end user's ability to make further adjustments. I think this is false...while you can't currently edit the resulting Passport generated DNG profile in X-Rite's software, you can indeed edit the resulting Passport generated DNG profile in Adobe's free DNG Profile Editor. You can edit the preset that SpyderCheckr creates in either Lightroom or Camera Raw, but you are editing an absolute preset that applies HSL adjustments requiring the saving out of a new subset of HSL adjustments-and again presets are not interchangeable between Lightroom and Camera Raw. I see this as a very limiting factor.

In principal, I encourage the development of more and better solutions for both Lightroom and Camera Raw. Whether or not the HSL calibration approach is superior to the DNG profile calibration approach, I really wonder whether or not HSL is a better solution than the DNG profile approach. It seems to me that Adobe (and Thomas Knoll and Eric Chan) have spent a lot of time and effort to develop an open solution to camera calibration that the SpyderCHECKR approach is ignoring. Personally, I would have encouraged the option to create either a DNG profile _OR_ an HSL calibration preset. I think it's a mistake to ignore the DNG profile approach.

thedigitaldog wrote:

 

...but am I correct that the DNG profile spec is open, the reason one would choose not to use it wouldn't be due to licensing or costs? Its a design option and I'm wondering why the two companies (X-Rite and DataColor) took differing approaches here.

Correct...the DNG profile spec, like the rest of the DNG spec is fully documented and while it requires adhering to to the offered specifications, it doesn't require any licensing fees. So, I have no idea why Datacolor chose the approach they did. I don't think Datacolor's approach is necessarily optimal.

Jeff Schewe wrote:

The other major issue is that presets are not easily transportable compared to DNG profiles which actually get imbedded in a raw file.

It has been my understanding that in LR this only happens if you "Update DNG Preview & Metadata" for the images.  Ctrl-S doesn't do it.  I have tested this in 2.5 but not yet in 3.2.  The benefit is if you create a special lighting DNG profile for a shoot, you can "Update DNG Preview & Metadata" for the whole shoot and then delete the special profile since it will only clutter up the UI.  If you forget to do this, which I did, and delete the profile first, those images are then assumed to use Adobe's default DNG profile.

Maybe this has changed but I think it is still the case.

Jeff

thedigitaldog wrote:

 

I didn't think about the disconnect between ACR and LR in terms of presets which would be a hassle for those moving from LR to a Smart Object.

Actually, I think the smart object created from LR will be fine.  I think Jeff's comments about ACR were when using ACR outside of LR, such as in Bridge or Photoshop, the LR presets would not show up for your use.  I wouldn't be surprised if these presets find there way into ACR functionality from all angles - but it could take a while.

I too wonder if the HSL process is just as good at the image end; i.e., do these color adjustments happen in the same order as the DNG profile color adjustments?  For me, using HSL removes the dependency on a file that can be somehow deleted (the DNG profile) so it might be a better/safer approach; however, it probably isn't as sophisticated allowing for dual-illuminant profiles, etc.  DNG profiles can be embedded into the image as well if using DNG format and you hit "Update DNG Previews & Metadata" so that may solve the safety issue.

Interesting nevertheless.

Jeff

Andrew, the approach to use HSL controls to perform color adjustments based on a measured target is fine, but has some limitations. For example, if you have your own HSL presets that you prefer to use (for creative effect), then it's hard to use those along with this approach (since this approach relies on setting the HSL sliders to certain values). There are also fewer degrees of freedom using the HSL controls. That is, there are some things that the DNG color profile model can accomplish via its lookup tables that cannot be accomplished by the HSL controls -- e.g., saturation-dependent effects, such as making less-saturated reds a little warmer, and making more-saturated reds a little cooler.

Never heard of Smith, but pragmatically, here's the actual code that the DNG SDK uses. In C, but should be fairly clear.

Regards,

Sandy

inline void DNG_RGBtoHSV (real32 r,
                          real32 g,
                          real32 b,
                          real32 &h,
                          real32 &s,
                          real32 &v)
    {
    v = Max_real32 (r, Max_real32 (g, b));

   real32 gap = v - Min_real32 (r, Min_real32 (g, b));
    if (gap > 0.0f)
        {

                  if (r == v)

            {
            h = (g - b) / gap;
           
            if (h < 0.0f)
                {
                h += 6.0f;
                }
            }
        else if (g == v)
            {
            h = 2.0f + (b - r) / gap;
            }
        else
            {
            h = 4.0f + (r - g) / gap;
            }
        s = gap / v;
        }
    else
        {
        h = 0.0f;
        s = 0.0f;
        }
   
   

Hi Andrew,

The processing order is roughly as follows. DNG color profiles contain at least a color matrix, and (optionally) one or more lookup tables, and (optionally) a tone curve. So at the minimum, there is a color matrix applied during image processing. This is applied very early in the imaging pipeline, while the image data is known to be in a linear, scene-referred space. The optional lookup tables and tone curve follow, and can be used to correct problem colors and residual issues, and apply a desired scene-to-output mapping.

Regarding white balance: It is applied along with the color matrix, i.e., very early. You can think of it as scaling the camera-native RGB coordinates till the desired values are neutral (i.e., R = G = B). This scaling, along with the color matrix in the profile, are effectively responsible for transforming from the camera-native RGB color coordinates -- which vary from model to model -- to a colorimetrically-defined system: CIE XYZ with a D50 white point, in the case of the DNG and ICC models. The user's chosen white balance is applied during this matrix step.

In the case of a dual-illuminant DNG profile, the user's chosen WB also has a second role, which is to determine how the matrices are used. As you know, Adobe's supplied "Adobe Standard" profiles are built using standard illuminants A and D65 as the calibration illuminants. So they contain separate matrices for each illuminant. The user's chosen WB determines which of the two matrices is used (more generally, how the two matrices are blended together) at image processing time. For example, if your chosen WB is Temp = 7500 K and you're using an Adobe Standard profile, then the DNG profile model calls for using the D65 color matrix. On the other hand, if your chosen WB for an image is Temp = 5200 K, then you'll be using a blend of the A and D65 matrices, with the latter more heavily weighted (since it's closer to D65 than to A). The DNG spec goes into more details on how this is done.

So to answer the question of WB and it's relevance to building & using DNG profiles: in principle, the applicability of a profile with a given WB has to do with how close the spectrum of the scene illuminant (used to photograph your real image) is to the spectrum of the illuminant used to build the profile. The closer they are, the better the results. Many flavors of natural daylight are spectrally similar (weighted differently), so this is why a daylight profile tends to work well in many flavors of daylight regardless of the actual CCT (e.g., 4700 K thru 7500 K). So even if you built your own profile under real daylight that ended up being around 6200 K, you should not hesitate to use such a profile under other similar daylight conditions, even if the CCT values vary a lot. But if you end up using a very different type of light (e.g., a fluorescent tube) then you should effect quite different, possibly unpleasant results, even if the CCT measures the same (e.g., a 6000 K office fluorescent tube).

Regarding the user's question of RGB & HSV, yes it is the same as the original definition proposed by Alvy Ray Smith. As Sandy notes there is an implementation in the DNG SDK for interested developers to use.

Hi Andrew, yes, conceptually you can think of all of these stages as following the demosaic step. So, after the demosaic step, one has a RGB linear scene-referred image, in native camera coordinates. The various color transform steps described in the DNG model (matrix, optional lookup tables, optional tone curve) can then be subsequently applied. There is a full implementation of the color model in the DNG SDK so that developers can step through and see all the color transform steps.

Eric,

Matrix after demosaic? Really?

Your demosaic algorythm can work in camera space?

Regards,

Sandy

MadManChan2000 wrote:

 

Hi Andrew, yes, conceptually you can think of all of these stages as following the demosaic step. So, after the demosaic step, one has a RGB linear scene-referred image, in native camera coordinates. The various color transform steps described in the DNG model (matrix, optional lookup tables, optional tone curve) can then be subsequently applied. There is a full implementation of the color model in the DNG SDK so that developers can step through and see all the color transform steps.

Yes, Sandy. It is not the only valid approach, of course.

Eric,

Thanks, I'd wondered how Adobe handled the "color temperature based matrix" in context of needing to update a screen real-time. But if you can do that post demosaic, it's not a problem. Does make me even more curious about what's inside the demosaic algorithm.....

Sandy