Display Calibration

Help
2008-03-22
2013-05-01
  • Vyacheslav Dikonov

    I attempted to use LPROF for display profiling using "Colorvision Spyder2" hardware meter and the results are far from succsessful if not a failure. I am aware that the dispaly calibration part is still not mature enough, but I hope that some work is going to be done once the new GUI became usable.  

    I have three displays of different kinds (an old CRT, PVA-LCD and TFT-LCD) and I wanted to make them all show 6500K/7200K and gamma 2.2. All of them turned out to be hard nuts for LProf for different reasons. Here is the summary of how LPROF CVS from 21 of March 2008 worked for different types of displays:

    Display 1) Samsung SyncMaster 244T (21" HD PVA panel). It has a good set of image controls and supports presets, so I could use LPROF for metering and manually adjust the display to the best possible quality approximating the intended result. I have a test grayscale image with white-black gradient, series of gray boxes with 10% and 5% lightness difference and the 2.2 gamma diagram (taken from Monica). The screen is adjusted to show almost perfectly neutral grays and gamma 2.2 without any LUT profiling. RESULT: Lprof did help to measure and adjust the display BUT all resulting profiles loaded with xcalib just gave the image unwanted red, green or brown color tints and made smooth gradients striped. As a result I just stick with uncalibrated state.

    Display 2) is an old and darkened 15" CRT screen. It turnes all 0%-30% grays and dark colors just black destroying all shadows. The point of calibration was to make it show the darker colors better (my relatives use it to edit photographs) and test Lprof with a CRT (which is claimed to be supported). I did manual configuration as good as possible and Lprof produced a profile. RESULT: The gamma has improved but it is far from good. The gray gradient becomes very flat with sudden steep drop to black below 10% of light. The formerly neutral gray with slight brownish tint becomes a gentle rainbow where different shades of gray acquire different tints in the sequence white-brownish-yellowish-cyanish-reddish-black. The overall effect of loading this CRT profile into the LUT by xcalib makes shades more visiblw but the colors lose saturation and look dull compared with Display 1.

    Display 3) is a notebook TFT-panel. Good resolution but small gamut and very view angle dependent (manual gamma adjustment is not possible). It has no controls whatsoever. Any adjustments can only be done in software. Thw notebooks video is an ATI Radeon 7500 with 3D but with little memory, so only 16-bit color is really supported. 24-bit makes 3D suffer because of video memory constraints and 32-bit is not possible. Lprof can measure this screen OK (gives gamma 1.7-1,4 and temperature of around 6600K). Shadows are too light, colors are not saturated enough. The goal of calibration is to bring gamma to 2.2 and improve color saturation. RESULT: Total failure. black and white point setting dialogs instruct the user to adjust the RGB controls, but my notebook has no such hardware controls. Gamma calibration process results in total display corruption. All colors shift randomly. Black becomes white, red or orange (depends on the X.org settings), white to 50% grey become white-to-red while 45% gray is bright blue and 40%-10% gray turnes into bright cyan shades. 5% grey became flesh tone and black is bright orange (!!!). This screen clearly needs a different calibration algorithm. Manual display calibration does not change anything.

    I can send the profiles and photographs of these screens showing the problems.

      

     
    • Hal Engel

      Hal Engel - 2008-03-22

      The video card calibration/gamma code is new and highly experimental.  I would like to have a look at your profiles since I would like to inspect the curves being created for the video card LUTs.  Please email them to me.

      #1 There has not been much testing on LCD displays so far since I don't have access to an LCD display.  The Samsung displays do have a fairly wide array of controls.  My experiments with using the controls on a Samsung 245BW were interesting in that many of the controls appear to be designed to mimic the controls on a CRT which is not how most LCD displays are setup.  I suspect that your 244T is similar in this regard. 

      I also found that these controls interacted with each in ways that the controls of CRT do not and that some of the controls did not act like those of a CRT at all.  For example setting the RGB color controls did not seem to change the display white point (on a CRT these would change the white point) and instead seemed to affect the gamma of the individual channels (IE. changed the mid tone color balance).  So using the RGB color controls to set the white point will cause all kinds of issues for the calibration software. 

      Using the various measurement screens and reports in LProf to help you adjust these controls is the correct preliminary step in the process.  But one of the challenges is that different vendors seems to have different sets of controls that act differently.  So unlike CRTs these controls are not standardized and it is difficult for us to provide guidance to users on how to use these controls.  I suspect that as we gain more experience with this that we will build up a set of recommended processes for different vendors LCD displays.

      "..all resulting profiles loaded with xcalib just gave the image unwanted red, green or brown color tints and made smooth gradients striped."

      Did you notice these same issues between the calibration and profile measurement steps when using LProf.  LProf loads the new gamma curves at the end of the calibration measurement step in preparation for measuring the display for profiling.  So I am wondering if these showed up when LProf loaded the gamma table or only when xcalib loaded the tables.

      #2 LProf will currently try to maintain a minimum contrast ratio between the displays white level and black level and on a reasonably bright CRT will actually pull the dark tones up (IE. make them brighter even those very close to black).  But if the white level is too low it will try to maintain the correct white level to black level ratio and this may exceed what the display can handle and this would push the darker tones down and make them turn black at some level well about the black point.  Since this has not been tested on a display like this (IE. one with a very low white level) I don't know how it will work under these conditions in actual practice.  I guess I could simulate this by setting a low white level on my test system to see what happens so I will do some testing.

      Have you measured the displays white level?  If you are getting something that is significantly below 80 cd/m^2 the calibration will likely not give good results.  If it is very low, say < 60 cd/m^2, then you will almost for sure not get good results with the current code base.

      One thing to try if your display white level is low is to try using a lower gamma setting.  But CRTs should have white levels in the 80 to 120 cd/m^2 range to be suitable for color critical work.  Many older CRTs will not be able to produce suitable white levels for color critical work because the phosphors wear out with use and will eventually get too dim. 

      On the flip side many LCDs are much brighter than they should be (some are capable of white levels as high as 500 cd/m^2) and getting this down below 180 cd/m^2 can be difficult on many panels (you should try to get this in the 140 to 160 cd/m^2 range if possible).

      #3 Of course LProf has no way to detect what controls your display has and this is an area where users need to use their judgment to decide how to apply the software to their hardware.  So if you don't have these controls then you can not use the software to help you set those non-existent controls.

      In addition, a system with only 16 bits/color (that is only 5 bits/channel - 32 levels per channel) is not suited for color critical work.  When you tried to calibrate this device you should have received a warning that the device did not have the correct capabilities for color critical work.  If you did not receive this warning then I need to have a look at the code to try to figure out why this didn't work.  This warning has not been tested since porting to Qt4. 

      I also find it strange that this has so little memory that you can't run X.Org in 24 bit mode.  A 1280x1024 frame buffer at 24 bits/pixel would need less than 4 megabytes of memory.  So even with double buffering to allow for frame flipping 8 megabytes of video memory should handle the frame buffers and I would expect that this generation of GPU would have at least 64 meg of video RAM.

      Looking on the net I get conflicting info about the base chipset for the ATI 7500.  But at least two sources list it as either an R200 or an RV200 (one lists it as an R100) and these are more credible than other sources (for example the man page for the X.Org radeon driver say RV200).  If this is correct then you have two options for drivers (IE. open source Radeon driver and the closed source fglrx driver).  The closed source driver uses a non-standard API for doing video card gamma table manipulations and is not supported by LProf or any other calibration software.  Which driver are you using?

       
      • Vyacheslav Dikonov

        > #1 There has not been much testing on LCD displays so far since I don't have access to an LCD display.
        Can I help by sending data? I have already sent my profiles and screen photos of some weird calibration bugs.

        > using the RGB color controls to set the white point will cause all kinds of issues for the calibration software. 
        I left all color-related controls in the default "50%" setting, because I could not understand all effects, and in extreme positions the colors just became strange.

        > unlike CRTs these controls are not standardized and it is difficult for us to provide guidance to users on how to use these controls.
        > I suspect that as we gain more experience with this that we will build up a set of recommended processes for different vendors LCD displays.
        It should be possible to verify and adapt procedures described in various color measurement devices' manuals.

        >>"..all resulting profiles loaded with xcalib just gave the image unwanted red, green or brown color tints and made smooth gradients striped."
        >Did you notice these same issues between the calibration and profile measurement steps when using LProf?
        YES

        >I am wondering if these showed up when LProf loaded the gamma table or only when xcalib loaded the tables.
        No it is not an xcalib issue at all.

        > #2 LProf will currently try to maintain a minimum contrast ratio between the displays white level and black level ...
        > Have you measured the displays white level? If you are getting something that is significantly below 80 cd/m^2 the calibration will likely not give good results.
        Yes, I did. The CRT one is quite dim, but not below 70 as far as I can remember.

        > On the flip side many LCDs are much brighter than they should be (some are capable of white levels as high as 500 cd/m^2)
        Mine is 500 Cd according to the specs and

        >you should try to get this in the 140 to 160 cd/m^2 range if possible). 
        My current settings for the good PVA-LCD (no LUT profiles applied) are:

        Display gamma = 2.14
        Black level = 0.47687 cd/m^2
        White level = 114.5 cd/m^2
        Contrast ratio = 240:1
        White chromaticity coordinates 0.3109, 0.3353
        White Correlated Color Temperature = 6553K, DE to locus = 9.30
        White Correlated Daylight Temperature = 6549K, DE to locus = 5.79
        White Visual Color Temperature = 6204K, DE to locus = 8.98
        White Visual Daylight Temperature = 6348K, DE to locus = 5.56

        >#3 Of course LProf has no way to detect what controls your display has and this is an area where users need to use their judgment to decide how to apply the software to their hardware.
        The point was to make LProf aware that sometimes the user just is not able to fulfill the recommendations like "boost the red channel to get it even with the blue". I believe, that profiles could compensate for such defects. Otherwise there is no use to profile less than high-end dispays to get better picture.

        > When you tried to calibrate this device you should have received a warning that the device did not have the correct capabilities for color critical work.
        This warning exists and is shown OK.

        >I also find it strange that this has so little memory that you can't run X.Org in 24 bit mode.
        It is possible in 2D only. I like to run 3D desktop and games :) And the notebook card's memory is not enough for true-color textures. Anyway, 24-bit exceed the physical capabilities of the TFT technology used for the panel itself, so I lose nothing at all. Measurements show almost no difference and bad effects are the same for all modes. So, I am very interested in getting profiles to work as good as possible for 16 bit.

        >Looking on the net I get conflicting info about the base chipset for the ATI 7500...
        fglrx does not work for me. It does not support 7500. The open ati driver is nice, actually. I only lack the ability to boost color saturation for better photo/movie viewing. I do not plan to do any kind of pre-press or professional image editing on TFT LCD, which cannot show 16 millions of colors.

         
    • Ian Calhaem

      Ian Calhaem - 2009-05-02

      Check your Samsung display - I believe that your model increases the effective frame rate by caching the frames so that the frames are actually displayed behind real time (a clue to whether this is the case is the presence of a synch funtion to synch video and audio on the display).
      If this is the case then colour profiling is a problem because the profiling software is outputting a frame but the instrument is measuring the frame before. Since the LUT tables are actively updated during the profiling process the profile will fail.
      You may be able to build a profile that leaves the white point set to native in which case the lut tables are not updated.

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks