Profile evaluation with absolute colorimetry

2012-03-15
2012-09-14
  • I wish to use the profile evaluation feature in an unusual way and I need
    DispcalGUI to calculate the reference color values from the profile with
    absolute colorimetric intent.

    I built a "HDTV_g2.4.icm" matrix+gamma profile using ArgyllCMS fakeread and
    colprof to describe a device with the Rec709 color space + a gamma 2.4 TRC
    (which I believe is the correct tone response for a HDTV if you watch it in a
    dark room - some may say it's 2.2 or 2.35 but it's another topic...).

    And I put together a ti3 file with the patches I think should be measure to
    evaluate an HDTV calibration.

    I would like to run the profile evaluations over and over again until I find
    the best OSD settings.

    This would basically work like CalMan or ChromaPure HDTV calibrations where
    the softwares do "gray-scale" and "color space" readings. But
    ArgyllCMS+DispcalGUI is not only free but I have much more control over how
    the software works and I can add any kind of color patches to the evaluation
    test chart (unlike with CalMan which can't just measure any mixed color I pick
    but it's limited to primary and secondary colors at one level only + 10 or 21p
    gray-scale...)

    But DispcalGUI uses relative colorimetric intent for calculating the reference
    values and I also want to set up the gray-scale controls on of the HDTV to
    produce D65.

    It's already usable this way but it would be better if I could use absolute
    colorimetry for profile evaluation.

    Which would be easier? Patch DispcalGUI to use absolute intent or patch
    ArgyllCMS to always use absolute colorimetry (no matter what the arguments
    select)?

    By the way, I never really understood why DispcalGUI assumes a white point
    instead of using the profile white point? I just didn't really care until
    now...

    (And I am not a real programmer, so it would be painful to modify the software
    for myself. I hope somebody has a working compiler environment and interested
    in making this small change for me. - Or us, because I think some people are
    also interested in HDTV calibration...)

     
  • Florian Hoech
    Florian Hoech
    2012-03-15

    I built a "HDTV_g2.4.icm" matrix+gamma profile using ArgyllCMS fakeread and
    colprof to describe a device with the Rec709 color space + a gamma 2.4 TRC

    If you want the actual Rec. 709 primaries, the fakeread/colprof way is
    probably not ideal, because it interpolates values for best overall match
    (i.e. the rXYZ/gXYZ/bXYZ tags in the profile will not match those of a 'true'
    Rec. 709 profile). The rec. 709 primaries are readily available, so it is easy
    to generate a synthetic profile from the D50-adaptated actual values, like
    this one: http://dispcalgui.hoech.net/tmp/Rec709_Gamma24.icm (this profile, among a few others, is
    also part of the reference profiles part of the upcoming dispcalGUI release)

    (which I believe is the correct tone response for a HDTV if you watch it in
    a dark room - some may say it's 2.2 or 2.35 but it's another topic...).

    It depends on the viewing conditions. The actual Rec. 709 TRC (which has an
    overall approx. gamma of roughly 1.9) is meant for bright studio, in a
    comparatively dim room a gamma of 2.2-2.4 is closer to the intended look.
    Basically, the darker the surround, the higher the gamma needs to be.

    And I put together a ti3 file with the patches I think should be measure to
    evaluate an HDTV calibration. I would like to run the profile evaluations over
    and over again until I find the best OSD settings.

    You can't use dispcalGUI's profile verification in this way though, because a
    profile will always be involved. E.g. using a ti3 as reference allows you to
    evaluate you how well the colors in that ti3 can be simulated through the
    currently selected profile, it does tell you nothing about how far or close
    the actual display response is to the reference.

    If you want to check the actual response against, say, Rec. 709 gamma 2.4,
    what you could do is set the above Rec709_Gamma24.icm as display profile,
    choose “<Current>” settings in dispcalGUI (= use display profile), and then
    use any ti1 chart for the profile verification.

    But DispcalGUI uses relative colorimetric intent for calculating the
    reference values and I also want to set up the gray-scale controls on of the
    HDTV to produce D65.

    dispcalGUI uses relative colorimetric when looking up reference values through
    the simulation profile if it is a display profile (class 'mntr'). Absolute
    colorimetric is used if it is a printer profile (class 'prtr'). The motive for
    that behavior is that absolute colorimetric is seldomly used for typical
    'mntr' profiles like sRGB or AdobeRGB (e.g. when you view an sRGB image, you
    normally don't need or want its whitepoint simulated), but pretty common when
    simulating the output of a printer (where you may want to simulate the paper
    white). There's also a peculiarity in the way absolute colorimetric is handled
    for printer class simulation profiles in dispcalGUI: As the printer profile's
    whitepoint is the color of the paper under D50 illuminant, this is what gets
    simulated, but under the display device illuminant (= display whitepoint)
    instead of D50. But as for monitor profiles (atleast in ICC v2.x) the
    whitepoint is also the illuminant, it means if you'd use absolute
    colorimetric with a display class simulation profile for a profile
    verification in dispcalGUI, the values would never match up unless the
    simulation profile whitepoint is D50 (e.g. a profile whitepoint equal to D65
    treated as 'paper white', then simulated under D65 display device illuminant
    would be 'cooler' in color appearance than D65).

    If you want to use dispcalGUI's profile verification feature to check
    whitepoint match to e.g. D65, just make sure that the measured whitepoint
    stays close to 6500K daylight.

    By the way, I never really understood why DispcalGUI assumes a white point
    instead of using the profile white point? I just didn't really care until
    now...

    An exact match to the profile whitepoint is not as critical as a match to the
    daylight or blackbody locus (because the eyes adapt, and they do so more
    easily if the whitepoint is close to the locus), which is what the measured vs
    assumed whitepoint values show (the assumed whitepoint lies directly on the
    locus). In the profile verification reports, you can also view the measured vs
    profile whitepoint values by ticking the “Show additional statistics”
    checkbox.

     
  • Ah, sorry. Yes, I created a ti1 file for the profile verification, not a ti3.

    And thanks for the reference ICM files! I could not find a software which
    allows me to create custom ICM files.

    Here is an example report: http://www.mediafire.com/download.php?f4xxdgfjiywr
    xtu

    Do you see how the 100% WP differs from the rest of the gray-scale? May be it
    would be better in this case to set the OSD WP controls to minimize the
    average gray-scale error which means I should sacrifice from the accuracy of
    the 100% WP. But I can not really do that with relative coloimetric profile
    evaluation (the grays will be always relative to 100% white, but I would
    achieve the lowest average to D65 across the gray shades).

    What do you suggest in this case?

     
  • Florian Hoech
    Florian Hoech
    2012-03-16

    I could not find a software which allows me to create custom ICM files.

    Programmatically, you could use lcms. dispcalGUI also has a library which
    allows creating simple matrix profiles from given primaries and TRC. It's a
    bit advanced and does call for some programming (i.e. writing a few lines of
    actual code), but you don't have to compile anything. If you're interested, I
    can show some example code and how to use it.

    Do you see how the 100% WP differs from the rest of the gray-scale? May be
    it would be better in this case to set the OSD WP controls to minimize the
    average gray-scale error which means I should sacrifice from the accuracy of
    the 100% WP. But I can not really do that with relative coloimetric profile
    evaluation (the grays will be always relative to 100% white, but I would
    achieve the lowest average to D65 across the gray shades).

    So, the problem is that the TV does not have the necessary grayscale controls
    to neutralize the grays more? In that case, comparing absolute colorimetric
    values won't help. E.g. the current dE*76 for patch 6 is 1.79. Using absolute
    colorimetric values, the dE 76 is still about the same (1.73)

    Also, the way the absolute colorimetric values are obtained in ICC colorimetry
    is by undoing the chromatic adaptation applied to the data stored in the ICC
    profile (rXYZ/gXYZ/bXYZ tags or lookup tables only contain relative
    colorimetric values, adapted to D50, so the absolute values are obtained by
    doing the inverse chromatic adaptation transform from D50 to the profile
    whitepoint).

     
  • This TV in the example has only 2 point gray-scale adjustments (and I didn't
    try to use those to slightly manipulate the gamma).

    If I set up the gains with the usual 80% level pattern then most of the grays
    are close to D65.

    If I set up the gains with a 100% level pattern then the white pint is close
    to D65 but the rest of the gray-scale is further.

    And it's very rare for movie scenes to have colors close to 100% luminance
    levels. So, i guess it would be better to have most of the grays close to D65
    and let the WP to go on it's way. But then everything will be relative to a
    drifted WP.

    I could decide where to place the peak error on the gray-scale if I could use
    absolute colorimetry. I could even put it to the 100% level.

    I have no problem with modifying existing C++ codes (I understand most of the
    syntax: variables, loops, functions, etc). But that's all I can do. If I need
    to start from scratch then I am boned. That's why I didn't start a small
    software using the lcms sources. (And it's a pain to get all the required
    libraries if I need to compile anything.)

    But I think the ICMs you included with the lates dispcalgui release completely
    cover my current needs. It came right in my time of need. Thank you again.

     
  • Florian Hoech
    Florian Hoech
    2012-03-16

    And it's very rare for movie scenes to have colors close to 100% luminance
    levels. So, i guess it would be better to have most of the grays close to D65
    and let the WP to go on it's way. But then everything will be relative to a
    drifted WP.

    Sounds reasonable. Also, I think matching an exact whitepoint color
    temperature for home theather is overrated. It only really matters if setting
    up several devices for direct comparison, or comparison from screen to print.
    What is more important is a close distance to the locus, not so much the color
    temperature.

    I could decide where to place the peak error on the gray-scale if I could
    use absolute colorimetry. I could even put it to the 100% level.

    Can't you do that with the relative values too? Just pick the grayscale
    value(s) you want to optimize and tweak the TV settings until the lowest
    possible dE is achieved. The difference between absolute and relative
    colorimetric values is really just the reference white.

    Or did you mean it would be easier if you had absolute colorimetric aim points
    for the actual adjustment? Then you can just take the reference values from
    the report and adapt them to D65. You can use the JavaScript functions that
    are embedded in the report to do this. E.g. in Firefox with the report open,
    pick a grayscale Lab reference value (e.g. 50.65 0 0), open the developer
    console (Ctrl + Shift + K), the following code takes the example value and
    gives you the absolute values 50.65 -1.3671 -11.1473:

    var Lab_D50 = [50.65, 0, 0];  // D50-relative L*a*b* reference values
    var XYZ_D50 = jsapi.math.color.Lab2XYZ(Lab_D50[0], Lab_D50[1], Lab_D50[2], null, 100.0);  // Go from L*a*b* to XYZ
    var XYZ_D65 = jsapi.math.color.adapt(XYZ_D50[0], XYZ_D50[1], XYZ_D50[2], "D50", "D65");  // Adapt XYZ values from D50 to D65
    jsapi.math.color.XYZ2Lab(XYZ_D65[0], XYZ_D65[1], XYZ_D65[2]);  // Go from XYZ back to L*a*b*
    
     
  • Yes, I wish to use this profile validation feature directly for caibration
    which I think would be easier with absolute gray chromaticity targets.

    I think the easiest way would be if you could send me a modified dispcalgui
    build which uses absolute colorimetric intent for profile evaluation, so I
    could test if it works better or not. (And if it does then may be you could
    add an override switch for this in the next public release...)

     
  • By the way...

    Do you know why applycal can't install a *.cal file (VGA LUT) to your icm
    profiles.

    (This for somthing else, not for HDTV calibration.)

     
  • Unknown: Error - rspl: rev_interp can't handle di = 1072662093

     
  • Florian Hoech
    Florian Hoech
    2012-03-16

    I think the easiest way would be if you could send me a modified dispcalgui
    build which uses absolute colorimetric intent for profile evaluation, so I
    could test if it works better or not. (And if it does then may be you could
    add an override switch for this in the next public release...)

    Download this: http://dispcalgui.hoech.net/tmp/report_absolute.zip

    Unpack and drop the two files contained in the zip into your dispcalGUI/report
    folder, overwriting existing files. Open dispcalGUI, choose “Update report” in
    the tools menu, select your report file. This will add a “Show absolute
    values” checkbox to the report which does as it says.

    By the way... Do you know why applycal can't install a *.cal file (VGA LUT)
    to your icm profiles. (This for somthing else, not for HDTV calibration.)

    I think you can't apply calibration to gamma profiles. Try this one (instead
    of a single gamma value, it uses an equivalent curve): http://dispcalgui.hoec
    h.net/tmp/Rec709_Gamma24_curve.icm

     
  • Thank you again.

    It works as I hoped, so I made the absolute intent to default and included my
    test pattern set (which I think is suitable for most of the current HDTVs with
    2/10/20p CMS and 6p triaxial gamut at one level) in this rar file:

    http://www.mediafire.com/?dfxtr05ozj5x4uq

    I plan to make some other small cosmetic changes to make this more suitable
    for this task but first I will test this method with some other HDTVs.

     
  • Is there any way to have the verification report in xyY coordinates for easier
    interpretation of CMS adjustments needed?

     
  • Florian Hoech
    Florian Hoech
    2012-04-06

    Yes: http://dispcalgui.hoech.net/tmp/report_XYZ_xyY.zip

    Unpack into dispcalGUI/report folder, overwriting existing files. Updated
    reports will allow you to select between Lab*, XYZ and xyY (absolute mode
    will automatically be used for the latter two).

     
  • Excellent, thank you!