Would it be possible to implement an option for a target gamut? White (blue + coating) LED based displays come with far too saturated blue, which I would like to calibrate away via software LUT. My 8 bit Dell U2713HM does not come with saturation controls and while using the built in sRGB profile works it decreases the gamut volume from 99.5% sRGB to only 95.6%. This nails the blue-point quite well, but unfortunately also decreases green and yellow saturation slightly.
An option to calibrate for a target gamut with desaturation of the blue channel via software LUT would be useful for displays like mine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-02-28
White LED based displays come with far too saturated blue...
If a screen has a tendency towards a certain hue, due to it's backlight, it's an issues that can not be fixed with a LUT. I don't know about saturation but removing a blue hue is not 100% possible. If the software tries to remove it, then it will only mess up the LUT. This are not my words but Steve Shaws words from Light Illusion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If a screen has a tendency towards a certain hue, due to it's backlight, it's an issues that can not be fixed with a LUT. I don't know about saturation but removing a blue hue is not 100% possible.
Definitely incorrect, you can correct whitepoint and grayscale hue via 3D LUTs or 1D per channel device curves.
What you can't change of course is the spectral distribution of the backlight itself.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Or instead of a target gamut allow for manual primaries and maybe secondaries even. This would allow to change the primary blue to within the visible range (or at least to within ProPhotoRGB or even just sRGB/AdobeRGB) while keeping magenta and green (and secondaries) at native points. In my case I would tame the blues from oversaturation and keep all the other primaries and secondaries to their natively slightly larger than sRGB gamut (benefits visibly editing greens and reds in photos before converting to target color-space).
The NVidia driver does not offer saturation/vibrance controls for single color channels, so having an option to desaturate (=decrease gamut) via (software) calibration would be nice indeed.
Currently I am switching between native gamut and the built in sRGB profile/gamut. The former is useful for editing except for the oversaturated blues. The latter is useful for targeting web images without having to use softproofing (anything that looks good with the sRGB profile should turn out ok on any other non wide-gamut display).
I do wonder, though, how much the profiling or rather probes (Spyder3, Colormunki) can be trusted with the blue primary? Is it realistic that white LEDs (blue + coating) have a blue-point (slightly) outside of even ProPhotoRGB?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
White (blue + coating) LED based displays come with far too saturated blue, which I would like to calibrate away via software LUT.
Well, you already said it: The way to solve this is to calibrate to a different (neutral) whitepoint.
An option to calibrate for a target gamut with desaturation of the blue channel via software LUT would be useful for displays like mine.
Video card gamma table calibration is an 1D process (for each of the three device channels, R, G and B), so it cannot correct a single channel without affecting whitepoint/grayscale hue. To have gamut correction, create an ICC profile and use applications that actually use it.
I do wonder, though, how much the profiling or rather probes (Spyder3, Colormunki) can be trusted with the blue primary?
Usually to increase trust level you use a spectrometer to create a correction matrix for the particular display/colorimeter combination. If you don't have a spectrometer, you could use one of the generic corrections that are available for several display types (dispcalGUI allows import from iColor Display for example, which has a quite extensive selection of corrections, or in case of ColorMUnki Display/i1 Display Pro and Spyder 4 you can import the spectral corrections from i1 Profiler).
Is it realistic that white LEDs (blue + coating) have a blue-point (slightly) outside of even ProPhotoRGB?
Definitely not, as the ProPhoto blue primary is not a real color (it is outside of the CIE diagram).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to clarify: I don't mean white-point and hue, but gamut in general and blue primary specifically.
To have gamut correction, create an ICC profile and use applications that actually use it.
Of course this is the best way to ensure everything works to full potential and I do have access to several of these (including PS and LR). But the myriads of applications that don't offer a color management workflow would benefit from calibrating the display (or GPU LUT) directly to the intended target gamut.
My U2713HM doesn't offer saturation controls. The NVidia driver offers a general control that affects all RGB channels at once, but no way to desaturate single channels. The U2713HM does offer a sRGB profile that indeed does decrease the native gamut volume down to within sRGB boundaries. But unfortunately it desaturates a bit too much, thus decreasing sRGB coverage down from over 99% to less than 96%.
So my hope was that it should be possible to calibrate a display to a target gamut (sRGB) by desaturating the primaries and secondaries via software LUT. As in mapping the oversaturated blue down to within sRGB/AdobeRGB boundaries, just like color management software does (maybe even with a choice of rendering intend). This would allow to get calibrated results with all applications.
I don't know if ArgyllCMS would allow for such things and how much work it would be to implement them. So maybe another solution would be to at least offer a dialog for those displays that do offer saturation controls (like some less expensive Eizo displays that come with 6-axis controls, but no hardware calibration). Something like the white-point dialog that helps the user to set up his displays controls to restrict a wide(r) gamut display to within sRGB gamut by adjusting primaries and secondaries. Those 6-axis controls are nearly useless otherwise, because you have to try them blindly then profile to see the results and then try to change them blindly again.
Video card gamma table calibration is an 1D process (for each of the three device channels, R, G and B), so it cannot correct a single channel without affecting whitepoint/grayscale hue.
I don't know exactly how software LUT calibration works, but the "LUT" part made me assume that this is a 3D process that can/does affect gamut/saturation as well?! Again, not meaning white-point and gamma, but colors in general and primaries/secondaries specifically?!
My current solution is to use the sRGB profile of the U2713HM in order to bombard my eyes with oversaturated blues in daily work and games. I then just switch to custom RGB settings with native display gamut for color sensitive work. It's not like 95% vs 99% is such a huge difference, but still it would be nice to make full use of the display's possibilities in daily operation.
If you don't have a spectrometer, you could use one of the generic corrections that are available for several display types (dispcalGUI allows import from iColor Display for example, which has a quite extensive selection of corrections, or in case of ColorMUnki Display/i1 Display Pro and Spyder 4 you can import the spectral corrections from i1 Profiler).
For the Colormunki I already imported those corrections from the setup file (used Auto import and pointed to the setup file). But that doesn't tell me whether to trust the Colormunki more than the Spyder3 or the other way around. ;)
Both report the blue primary to be well oversaturated. And both report the same brightness using Dispcalgui, while the Colormunki reports a different brightness using the X-Rite software (as in I have to increase display brightness several steps to meet the same 120 cd/m2 according to X-Rite's Colormunki software). Have to try the Datacolor software again to see if the Spyder3 also measures different brightness between Dispcalgui and Datacolor. Seeing how Dispcalgui/Argyll offers visibly better results with the Spyder3 compared to three commercial software packages I trust Dispcalgui/Argyll more than the vendor software, though.
Definitely not, as the ProPhoto blue primary is not a real color (it is outside of the CIE diagram).
I should clarify this. The blue primary of my display is not measured to be outside the blue primary of ProPhoto (which in turn is outside CIE). It is rather outside the gamut of ProPhoto, but compared to ProPhoto would rather be in between the blue and magenta axis of ProPhoto. Here is a screenshot that should give you an idea.
But the myriads of applications that don't offer a color management workflow would benefit from calibrating the display (or GPU LUT) directly to the intended target gamut.
Well, but if the applications lack any form of colormanagement support, then they lack the mechanism to do this. There's no way around that. GPU LUTs (video card gamma table or videLUT) are 1D per device-channel curves, so they cannot be used for this.
The only OS that offers full desktop color correction (using ICC profiles) is Mac OS X (and Linux if specific components are installed and configured correctly). In all other cases you would have to use an external 3D LUT box, or a display with that capability.
I don't know exactly how software LUT calibration works, but the "LUT" part made me assume that this is a 3D process that can/does affect gamut/saturation as well?!
Se above.
I should clarify this. The blue primary of my display is not measured to be outside the blue primary of ProPhoto (which in turn is outside CIE). It is rather outside the gamut of ProPhoto, but compared to ProPhoto would rather be in between the blue and magenta axis of ProPhoto. Here is a screenshot that should give you an idea.
Ok, this doesn't look to crazy :) Ultimately the only thing that will tell you if the colorimeters report the correct color coordinates, is to use a spectrometer to check though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GPU LUTs (video card gamma table or videLUT) are 1D per device-channel curves, so they cannot be used for this.
So you can only map B255 to B250, but not something like R0G0B255 to R10G10B250? Too bad, I always assumed that every single color of the 24 bit spectrum could be remapped. I will play around some with the manual per channel gamma and general saturation (digital vibrance) controls of the NVidia driver to get a feel for how it may help. Too bad that there is no per channel saturation control in the driver (need to check ATI drivers for that again).
Ok, this doesn't look to crazy :) Ultimately the only thing that will tell you if the colorimeters report the correct color coordinates, is to use a spectrometer to check though.
Good to know that this is within expected boundaries. The Colormunki is a spectrophotometer. ;)
I bought the Munki as a "refurbished" (fully functional) unit, though, and judging from the broken zipper I am not confident that it really is refurbished. I ordered a new one now and will compare the two Munkis to get an idea of the differences of all three units (1 Spyder3, 2 Monkis). As luck has it the prices have just fallen considerably yesterday. :D
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh, my bad - somehow I assumed ColorMunki Display, not Photo/Design :) In that case, the colorimeter corrections don't apply to it obviously, and I'd generally trust it more, refurbished or not, than a colorimeter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Definitely incorrect, you can correct whitepoint and grayscale hue via 3D LUTs or 1D per channel device curves.
What you can't change of course is the spectral distribution of the backlight itself.
I was referring to the hue caused by LEDs bad CRI... This can't be helped?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
CRI mostly plays a role when you use a light source to shine it onto something to illuminate it. Displays are usually not used in that way. A backlight with bad spectral distribution could make it difficult to achieve a certain whitepoint without bad side-effects though, e.g. in vcgt calibration this then shows in one or two channels being drastically reduced, which then leads to banding. I've never run into a case where it was impossible to achieve a certain whitepoint though, and I think this is due to the range of whitepoints that are commonly used as calibration targets being limited to the 5000-6500K range, which is usually within the gamut of the display and can be achieved by adjusting the RGB gains (either via display controls or vcgt or both).
A low-quality backlight can definitely limit the gamut though.
Last edit: Florian Hoech 2014-03-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would it be possible to implement an option for a target gamut? White (blue + coating) LED based displays come with far too saturated blue, which I would like to calibrate away via software LUT. My 8 bit Dell U2713HM does not come with saturation controls and while using the built in sRGB profile works it decreases the gamut volume from 99.5% sRGB to only 95.6%. This nails the blue-point quite well, but unfortunately also decreases green and yellow saturation slightly.
An option to calibrate for a target gamut with desaturation of the blue channel via software LUT would be useful for displays like mine.
If a screen has a tendency towards a certain hue, due to it's backlight, it's an issues that can not be fixed with a LUT. I don't know about saturation but removing a blue hue is not 100% possible. If the software tries to remove it, then it will only mess up the LUT. This are not my words but Steve Shaws words from Light Illusion.
Definitely incorrect, you can correct whitepoint and grayscale hue via 3D LUTs or 1D per channel device curves.
What you can't change of course is the spectral distribution of the backlight itself.
Or instead of a target gamut allow for manual primaries and maybe secondaries even. This would allow to change the primary blue to within the visible range (or at least to within ProPhotoRGB or even just sRGB/AdobeRGB) while keeping magenta and green (and secondaries) at native points. In my case I would tame the blues from oversaturation and keep all the other primaries and secondaries to their natively slightly larger than sRGB gamut (benefits visibly editing greens and reds in photos before converting to target color-space).
The NVidia driver does not offer saturation/vibrance controls for single color channels, so having an option to desaturate (=decrease gamut) via (software) calibration would be nice indeed.
Currently I am switching between native gamut and the built in sRGB profile/gamut. The former is useful for editing except for the oversaturated blues. The latter is useful for targeting web images without having to use softproofing (anything that looks good with the sRGB profile should turn out ok on any other non wide-gamut display).
I do wonder, though, how much the profiling or rather probes (Spyder3, Colormunki) can be trusted with the blue primary? Is it realistic that white LEDs (blue + coating) have a blue-point (slightly) outside of even ProPhotoRGB?
Well, you already said it: The way to solve this is to calibrate to a different (neutral) whitepoint.
Video card gamma table calibration is an 1D process (for each of the three device channels, R, G and B), so it cannot correct a single channel without affecting whitepoint/grayscale hue. To have gamut correction, create an ICC profile and use applications that actually use it.
Usually to increase trust level you use a spectrometer to create a correction matrix for the particular display/colorimeter combination. If you don't have a spectrometer, you could use one of the generic corrections that are available for several display types (dispcalGUI allows import from iColor Display for example, which has a quite extensive selection of corrections, or in case of ColorMUnki Display/i1 Display Pro and Spyder 4 you can import the spectral corrections from i1 Profiler).
Definitely not, as the ProPhoto blue primary is not a real color (it is outside of the CIE diagram).
Just to clarify: I don't mean white-point and hue, but gamut in general and blue primary specifically.
Of course this is the best way to ensure everything works to full potential and I do have access to several of these (including PS and LR). But the myriads of applications that don't offer a color management workflow would benefit from calibrating the display (or GPU LUT) directly to the intended target gamut.
My U2713HM doesn't offer saturation controls. The NVidia driver offers a general control that affects all RGB channels at once, but no way to desaturate single channels. The U2713HM does offer a sRGB profile that indeed does decrease the native gamut volume down to within sRGB boundaries. But unfortunately it desaturates a bit too much, thus decreasing sRGB coverage down from over 99% to less than 96%.
So my hope was that it should be possible to calibrate a display to a target gamut (sRGB) by desaturating the primaries and secondaries via software LUT. As in mapping the oversaturated blue down to within sRGB/AdobeRGB boundaries, just like color management software does (maybe even with a choice of rendering intend). This would allow to get calibrated results with all applications.
I don't know if ArgyllCMS would allow for such things and how much work it would be to implement them. So maybe another solution would be to at least offer a dialog for those displays that do offer saturation controls (like some less expensive Eizo displays that come with 6-axis controls, but no hardware calibration). Something like the white-point dialog that helps the user to set up his displays controls to restrict a wide(r) gamut display to within sRGB gamut by adjusting primaries and secondaries. Those 6-axis controls are nearly useless otherwise, because you have to try them blindly then profile to see the results and then try to change them blindly again.
I don't know exactly how software LUT calibration works, but the "LUT" part made me assume that this is a 3D process that can/does affect gamut/saturation as well?! Again, not meaning white-point and gamma, but colors in general and primaries/secondaries specifically?!
My current solution is to use the sRGB profile of the U2713HM in order to bombard my eyes with oversaturated blues in daily work and games. I then just switch to custom RGB settings with native display gamut for color sensitive work. It's not like 95% vs 99% is such a huge difference, but still it would be nice to make full use of the display's possibilities in daily operation.
For the Colormunki I already imported those corrections from the setup file (used Auto import and pointed to the setup file). But that doesn't tell me whether to trust the Colormunki more than the Spyder3 or the other way around. ;)
Both report the blue primary to be well oversaturated. And both report the same brightness using Dispcalgui, while the Colormunki reports a different brightness using the X-Rite software (as in I have to increase display brightness several steps to meet the same 120 cd/m2 according to X-Rite's Colormunki software). Have to try the Datacolor software again to see if the Spyder3 also measures different brightness between Dispcalgui and Datacolor. Seeing how Dispcalgui/Argyll offers visibly better results with the Spyder3 compared to three commercial software packages I trust Dispcalgui/Argyll more than the vendor software, though.
I should clarify this. The blue primary of my display is not measured to be outside the blue primary of ProPhoto (which in turn is outside CIE). It is rather outside the gamut of ProPhoto, but compared to ProPhoto would rather be in between the blue and magenta axis of ProPhoto. Here is a screenshot that should give you an idea.
Well, but if the applications lack any form of colormanagement support, then they lack the mechanism to do this. There's no way around that. GPU LUTs (video card gamma table or videLUT) are 1D per device-channel curves, so they cannot be used for this.
The only OS that offers full desktop color correction (using ICC profiles) is Mac OS X (and Linux if specific components are installed and configured correctly). In all other cases you would have to use an external 3D LUT box, or a display with that capability.
Se above.
Ok, this doesn't look to crazy :) Ultimately the only thing that will tell you if the colorimeters report the correct color coordinates, is to use a spectrometer to check though.
So you can only map B255 to B250, but not something like R0G0B255 to R10G10B250? Too bad, I always assumed that every single color of the 24 bit spectrum could be remapped. I will play around some with the manual per channel gamma and general saturation (digital vibrance) controls of the NVidia driver to get a feel for how it may help. Too bad that there is no per channel saturation control in the driver (need to check ATI drivers for that again).
Good to know that this is within expected boundaries. The Colormunki is a spectrophotometer. ;)
I bought the Munki as a "refurbished" (fully functional) unit, though, and judging from the broken zipper I am not confident that it really is refurbished. I ordered a new one now and will compare the two Munkis to get an idea of the differences of all three units (1 Spyder3, 2 Monkis). As luck has it the prices have just fallen considerably yesterday. :D
Oh, my bad - somehow I assumed ColorMunki Display, not Photo/Design :) In that case, the colorimeter corrections don't apply to it obviously, and I'd generally trust it more, refurbished or not, than a colorimeter.
Blame X-Rite for the confusing product naming schemes. ;)
I was referring to the hue caused by LEDs bad CRI... This can't be helped?
CRI mostly plays a role when you use a light source to shine it onto something to illuminate it. Displays are usually not used in that way. A backlight with bad spectral distribution could make it difficult to achieve a certain whitepoint without bad side-effects though, e.g. in vcgt calibration this then shows in one or two channels being drastically reduced, which then leads to banding. I've never run into a case where it was impossible to achieve a certain whitepoint though, and I think this is due to the range of whitepoints that are commonly used as calibration targets being limited to the 5000-6500K range, which is usually within the gamut of the display and can be achieved by adjusting the RGB gains (either via display controls or vcgt or both).
A low-quality backlight can definitely limit the gamut though.
Last edit: Florian Hoech 2014-03-03