I wonder if others would find a "Native" gamma tone curve target for calibration useful?! I would indeed, as I am quite happy with the gamma of my display and need color temperature correction throughout the whole range of gray only. Using LUT based software calibration a "Native" gamma calibration should lead to less (if any) banding and possibly speed up the calibration process.
My Dell U2713HM uses an 8-bit panel without FRC and comes with a native gamma average of about 2.15, very close to 2.2 except for ever so slightly brighter mids.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am quite happy with the gamma of my display and need color temperature correction throughout the whole range of gray only.
For whitepoint and grayscale adjustment, the amounts of RGB need to be changed. So you need to choose a calibration target so that dispcal knows what to aim for. You can't "calibrate without calibrating" :)
The only exception to this rule is if the monitor lets you change the whitepoint with its conntrols, and also alters the whole grayscale in doing so. Some displays do, your U2713HM may be one of them, but you have to try it to find out. Afterwards, simply check the grayscale visually and run a measurement report with a good amount of gray patches to see if the grayscale is good enough for your needs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the answer (and for providing such great software)!
Yes, changing the white-point of the U2713HM via RGB controls does change the whole scale, especially since this is only an 8 bit panel that has to throw away tones when the white-point is changed. My reading with a Spyder3 vs. ColorMunki are somewhat inconsistent, but the pure white-point of my U2713HM seems to be somewhat cooler than the rest of the grayscale (especially shadows and mids).
Of course I understand that a calibration target is needed, but why all software out there only offers a native white-point (if at all), but no native gamma is somewhat beyond me. Why not just change the gray-patches to match the selected white-point (aka keep at least one RGB channel unchanged) or maybe first profile the native gamma and then take that as a target?
This should allow minimal (if any) banding of grayscales, since at least one RGB channel of specific gray-patches will stay unchanged and in some cases maybe two or even all three.
All that being said, Argyll + Dispcalgui + Spyder3 are mostly able to acquire neutral gray tones throughout the scale (as in no visible tint) with reasonable amount of banding. It takes well over two hours with the Spyder3, compared to less than 15 minutes with the Colormunki, because shadows and dark mids take forever being measured. But I tried three different commercial applications (including my former favorite Quato IColor Display) and all of them lead to very visible green and red tints throughout the tonal range. So thumbs up for providing the real deal and making it accessible via a GUI! ;)
Last edit: Timur Born 2014-02-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why not just change the gray-patches to match the selected white-point (aka keep at least one RGB channel unchanged) or maybe first profile the native gamma and then take that as a target?
You can measure the average gamma and take that as a target (menu options, "report on uncalibrated display"). The reason that it's not possible to follow the true native response throughout the grayscale is that this choice is not available in Argyll CMS. Also, usually you also want calibration to fix nonlinearities that may exist in the native response, which may not be possible when following the native response slavishly.
This should allow minimal (if any) banding of grayscales, since at least one RGB channel of specific gray-patches will stay unchanged and in some cases maybe two or even all three.
The strength of banding not necessarily correlates to how many channels had to be changed by calibration, but more to how neutral (or not) the native response was and/or how far from the desired response curve shape. There are cases where all three channels changed equally throughout the range may produce less banding than a calibration where only one or two channels were changed.
Ultimately when we finally arrive at full 30 bit (10 bit for each channel) or higher precision for the digital signal from the videocard to the display (and when this functionality will actually be used by the respective OS!) most if not all of the banding issues will disappear. We'll get there eventually :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello everyone!
I wonder if others would find a "Native" gamma tone curve target for calibration useful?! I would indeed, as I am quite happy with the gamma of my display and need color temperature correction throughout the whole range of gray only. Using LUT based software calibration a "Native" gamma calibration should lead to less (if any) banding and possibly speed up the calibration process.
My Dell U2713HM uses an 8-bit panel without FRC and comes with a native gamma average of about 2.15, very close to 2.2 except for ever so slightly brighter mids.
For whitepoint and grayscale adjustment, the amounts of RGB need to be changed. So you need to choose a calibration target so that dispcal knows what to aim for. You can't "calibrate without calibrating" :)
The only exception to this rule is if the monitor lets you change the whitepoint with its conntrols, and also alters the whole grayscale in doing so. Some displays do, your U2713HM may be one of them, but you have to try it to find out. Afterwards, simply check the grayscale visually and run a measurement report with a good amount of gray patches to see if the grayscale is good enough for your needs.
Thanks for the answer (and for providing such great software)!
Yes, changing the white-point of the U2713HM via RGB controls does change the whole scale, especially since this is only an 8 bit panel that has to throw away tones when the white-point is changed. My reading with a Spyder3 vs. ColorMunki are somewhat inconsistent, but the pure white-point of my U2713HM seems to be somewhat cooler than the rest of the grayscale (especially shadows and mids).
Of course I understand that a calibration target is needed, but why all software out there only offers a native white-point (if at all), but no native gamma is somewhat beyond me. Why not just change the gray-patches to match the selected white-point (aka keep at least one RGB channel unchanged) or maybe first profile the native gamma and then take that as a target?
This should allow minimal (if any) banding of grayscales, since at least one RGB channel of specific gray-patches will stay unchanged and in some cases maybe two or even all three.
All that being said, Argyll + Dispcalgui + Spyder3 are mostly able to acquire neutral gray tones throughout the scale (as in no visible tint) with reasonable amount of banding. It takes well over two hours with the Spyder3, compared to less than 15 minutes with the Colormunki, because shadows and dark mids take forever being measured. But I tried three different commercial applications (including my former favorite Quato IColor Display) and all of them lead to very visible green and red tints throughout the tonal range. So thumbs up for providing the real deal and making it accessible via a GUI! ;)
Last edit: Timur Born 2014-02-27
You can measure the average gamma and take that as a target (menu options, "report on uncalibrated display"). The reason that it's not possible to follow the true native response throughout the grayscale is that this choice is not available in Argyll CMS. Also, usually you also want calibration to fix nonlinearities that may exist in the native response, which may not be possible when following the native response slavishly.
The strength of banding not necessarily correlates to how many channels had to be changed by calibration, but more to how neutral (or not) the native response was and/or how far from the desired response curve shape. There are cases where all three channels changed equally throughout the range may produce less banding than a calibration where only one or two channels were changed.
Ultimately when we finally arrive at full 30 bit (10 bit for each channel) or higher precision for the digital signal from the videocard to the display (and when this functionality will actually be used by the respective OS!) most if not all of the banding issues will disappear. We'll get there eventually :)