Benq SW2700PT sRGB mode gamma - no linear section

[richardj21724418]

I'd been wondering why images appear to be higher contrast in sRGB mode on my Benq SW2700PT monitor than in AdobeRGB mode.  On investigaton I find it's because the monitor doesn't support the linear region in the sRGB gamma curve but applies a gamma of 2.2 across the whole range, from black to white.  If I view a black & white image in AdobeRGB and then switch the monitor to sRGB (without changing my monitor profile) I'd expect the shadows to lighten, but they stay the same.  In other words, the monitor is using the same 2.2 gamma curve for sRGB as it uses for AdobeRGB (AdobeRGB gamma doesn't have a linear section).  This means when I switch to sRGB mode and apply the sRGB profile, the shadows become too dark.

It's the same if I calibrate the monitor to sRGB primaries with Palette Master Element.  The gamma is applied across the whole range.  There is no option available for the linear section.

Is this normal behaviour for monitors?  I might expect it of budget consumer models but the SW2700PT is supposed to be aimed at the premium consumer market, even edging into professional.  I notice it's the same on my old Dell U2410 monitors, which were also higher end models in their day.

When I view in sRGB mode, is there an alternative sRGB profile I should be using, without the linear section?  Up until now I've simply been using sRGB IEC61966-2.1.

[richardj21724418]

https://forums.adobe.com/people/D+Fosse  wrote

richardj21724418   wrote

What I'm saying is, if a monitor is calibrated to sRGB, then it should conform to the sRGB profile and comply with the sRGB response curve.

Well, maybe, but again, there's no need. You'd make very complicated tables in the monitor LUT for no benefit whatsoever. All you achieve is to make life so difficult for the monitor that it starts producing artifacts.

The profiles will handle this, whatever the discrepancies. There is no reason the calibration tables should do it, when the profile achieves the same goal with much less effort.

What you're asking is to make the monitor a perfect sRGB device. That's hard work. No monitor ever was that, nor does it have to be. Color management picks up where the calibration leaves off.

When properly designed I believe internal monitor calibration tables provide superior colour space conversion than currently achieved by software profiles and limited GPU LUTs.

Why else do you suppose monitors are produced with hardware calibration?  Just marketing?  Would Eizo 'waste money' on it if it wasn't superior to PC calibration?

[D Fosse]

richardj21724418  wrote

When properly designed I believe internal monitor calibration tables provide superior colour space conversion than currently achieved by software profiles and limited GPU LUTs.

I'm beginning to suspect you seriously misunderstand how this works. There is no color space conversion performed by the calibration, whether in the monitor LUT or the video card. That is not its role. Yes, hardware calibration is better than software calibration in the video card, but for other reasons. Functionally they do the same thing.

Calibration is not part of the color management chain*. It just sets the environment for color management to operate in.

Color space conversion is performed by the application's color management engine, based on the icc profiles. The profile is a description of a color space, in this case the monitor's native color space in its calibrated state. This is a standard profile conversion, just like any other profile conversion. The numbers are remapped into the destination color space. These recalculated numbers are sent to the monitor.

(*It is very indirectly, but not for the purposes of this discussion...)

[richardj21724418]

https://forums.adobe.com/people/D+Fosse  wrote

richardj21724418   wrote

When properly designed I believe internal monitor calibration tables provide superior colour space conversion than currently achieved by software profiles and limited GPU LUTs.

I'm beginning to suspect you seriously misunderstand how this works. There is no color space conversion performed by the calibration, whether in the monitor LUT or the video card. That is not its role. Yes, hardware calibration is better than software calibration in the video card, but for other reasons. Functionally they do the same thing.

Sorry, but when the monitor is calibrated to a profile, like sRGB, surely this programs the colour space conversion to be performed inside the monitor?  If its input response is changed from native, that means the colour space has been changed?  The monitor has to convert the standard sRGB input values it receives to its native space.  If it does this properly, the correct ICC profile to use in this state is the standard sRGB profile.  There should be no need for a second level of soft calibration within the PC and the use of a non standard ICC profile to describe the monitor characteristic.  If there is, it rather negates the reason for hardware calibration of the monitor to sRGB space.

Even a 'conventional'  wide gamut monitor often has some sort of sRGB emulation mode, albeit uncalibrated.  That must also involve colour space conversion.

I don't know if we have some cultural differences but I seem to struggle to express myself in a manner which others here can comprehend.  I guess that's probably mutual!  With that in mind it's probably best if we wind down the discussion for now as I'm sure it's become a waste of energy for all of us.  Perhaps in due course someone will come along and understand what I've been trying to get at.  Until then, thanks to everyone for your replies.  I appreciate the effort you've taken to try and educate me and the frustration you must have suffered!

[TheDigitalDog]

richardj21724418  wrote

https://forums.adobe.com/people/D+Fosse   wrote

richardj21724418    wrote

When properly designed I believe internal monitor calibration tables provide superior colour space conversion than currently achieved by software profiles and limited GPU LUTs.

I'm beginning to suspect you seriously misunderstand how this works. There is no color space conversion performed by the calibration, whether in the monitor LUT or the video card. That is not its role. Yes, hardware calibration is better than software calibration in the video card, but for other reasons. Functionally they do the same thing.

Sorry, but when the monitor is calibrated to a profile, like sRGB, surely this programs the colour space conversion to be performed inside the monitor?

No, there is no such 'conversion'. Calibration is just that, a profile defines that behavior and then, again, for previews, Display Using Monitor Compensation is applied. 

[richardj21724418]

thedigitaldog  wrote

richardj21724418   wrote

Sorry, but when the monitor is calibrated to a profile, like sRGB, surely this programs the colour space conversion to be performed inside the monitor?

No, there is no such 'conversion'. Calibration is just that, a profile defines that behavior and then, again, for previews, Display Using Monitor Compensation is applied. 

Sorry, I know I should be ending this discussion but I have to ask.  What do the 3D lookup tables in hardware calibrated monitors do?  Nothing to do with colour space conversion by any chance?

[TheDigitalDog]

Again, for at least the fourth time the answer is NO!

[richardj21724418]

thedigitaldog  wrote

Again, for at least the fourth time the answer is NO!

Really?  What do the 3D LUTS do then?

[TheDigitalDog]

richardj21724418  wrote

thedigitaldog   wrote

Again, for at least the fourth time the answer is NO!

Really?  What do the 3D LUTS do then?

They load a Look Up Table! Which has absolutely nothing to do with color space conversions for (at least) the 5th time.

[richardj21724418]

thedigitaldog  wrote

richardj21724418   wrote

thedigitaldog    wrote

Again, for at least the fourth time the answer is NO!

Really?  What do the 3D LUTS do then?

They load a Look Up Table! Which has absolutely nothing to do with color space conversions for (at least) the 5th time.

And the Look Up Table does what? What does it DO?

[richardj21724418]

Perhaps you guys need helping out.

From NEC:-

"The integrated 3D LUT with color emulation preset within the SpectraView series of products, can be used to transform the color space of the monitor to emulate that of the printer, or other color workflow device. The 3D LUT is a three dimensional table that maps colors into a different color space."

From Google:-

"3D lookup tables (3D LUTs) are used to map one color space to another"

[D Fosse]

richardj21724418  wrote

Sorry, but when the monitor is calibrated to a profile, like sRGB, surely this programs the colour space conversion to be performed inside the monitor?

OK, now I'm sure. You do misunderstand how it works.

The monitor is not calibrated "to a profile". It is calibrated to a set of parameters defining its white point, black point and gamma. The rest is best left to the unit's native behavior. A thing like an "Adobe RGB setting" is nonsense. Just run at native response.

In addition, wide gamut monitors can usually be set to emulate the sRGB gamut. This is not a "color space conversion". It is just a way to limit the gamut to that of a standard gamut monitor, in case you need to work with non-color managed software. It's a way to turn your wide gamut unit into a standard one. An ordinary standard gamut monitor, BTW, is even more different from sRGB, because not only the TRC, but the primaries are a little different too.

Beyond that, there is no functional difference between hardware and video card calibration. They do exactly the same thing. But these are all adjustments to the monitor, so you obviously get better results by doing it in the monitor itself.

And now color management can enter the picture, not before. Now the monitor's response is defined. So it's time to make a profile. This profile is just a description, it doesn't do anything. It describes in detail the monitor color space, the position of the primaries (the gamut), the detailed tone response curve with all its quirks, peaks and troughs.

Then the application - not the monitor! - converts from the document profile, into the monitor profile. And these converted/recalculated RGB numbers are sent to the monitor. The profile takes everything into consideration and remaps the numbers into monitor color space, so that the file is correctly represented on screen. Document white 255/255/255 is remapped to monitor white 255/255/255 and so on.

Here's the critical part: the profile is an accurate description of the monitor's current behavior. Change that behavior in any way, and the profile is invalidated because the description is no longer accurate. Then you need to make a new profile.

I've said all this about three or four times by now. I'm not sure how many times I want to repeat myself.

[richardj21724418]

https://forums.adobe.com/people/D+Fosse  wrote

In addition, wide gamut monitors can usually be set to emulate the sRGB gamut. This is not a "color space conversion". It is just a way to limit the gamut to that of a standard gamut monitor, in case you need to work with non-color managed software. It's a way to turn your wide gamut unit into a standard one. A standard gamut monitor is even more different from sRGB, because not only the TRC, but the primaries are a little different too.

So changing the monitor's input response from, say, native AdobeRGB to sRGB isn't classed as a colour space conversion?  Really?  That's an interesting concept.  Does that mean if I change an image in Photoshop from AbobeRGB to sRGB working space I'm not performing a colour space conversion, merely limiting the gamut?

What do you suppose the 3D LUTs in the monitor do?

[richardj21724418]

I don't mean this to come across as offensive but I think you're living in the, "this is how it's done because we've always done it this way" world.

I'm living in the idealistic, "this is how it should work" world.

I think hardware calibrated monitors are still in their infancy, at least in the consumer market, and the marketing talent appears to have exceeded the engineering abilities!

In theory I see no reason why a wide gamut monitor can't be internally calibrated to respond as near as possible perfectly to sRGB.  In which case, for colour management, the monitor profile you use is the standard sRGB profile and the TRC LUTs in the PC are linear.  That's what a calibrated monitor should do IMO.  There should be no need for additional calibration on the PC side and non standard profiles when calibrated to standard colour spaces.

However, it appears that internally calibrated monitors are not what they're cracked up to be, at least at the consumer level.  I guess they have some advantage if you use them in their native gamut and use the internal TRC LUTs for calibration to your preferred white point.

[NB, colourmanagement]

Hi Richard

"In theory I see no reason why a wide gamut monitor can't be internally calibrated to respond as near as possible perfectly to sRGB.  In which case, for colour management, the monitor profile you use is the standard sRGB profile and the TRC LUTs in the PC are linear.  That's what a calibrated monitor should do IMO.  There should be no need for additional calibration on the PC side and non standard profiles when calibrated to standard colour spaces."

I agree it SHOULD be possible. For applications like video which may offer no colourmanagement, for example.

So, this whole thread is, it seems, essentially about your dissatisfaction with BenQ's Palletemaster software?

I wonder if the following may pique your interest? [spoiler alert benQ hardware is not supported]

basICColor offer 2 things that should help

1:

an ability to calibrate to the sRGB tonal response curve

"RGB IEC61966-2.1

sRGB is a working space for monitor output only. You find it mainly in the areas of Internet, multi media video and office applications. The tonal response curve cannot be described with a gamma function (although Photoshop, for example, reports a gamma value of 2.2). In the shadows, it resemble more an L* curve, in the mid tones and highlights it follows the gamma 2.2 curve. In order to exactly match sRGB data, basICColor display and SpectraView Profiler are the only monitor calibration applications that offers an sRGB calibration curve for these applications."

and -

2:

for supported hardware calibration displays, the option to "emulate" another screen using its ICC profile.

Since those guys know what they are doing I am confident it would work. Sadly you can't try it because the hardware downloadable LUT on benQ is not supported.

"Color Space Emulation

Some high-end monitor have an internal 3d Look-Up-Table (3D LUT) which allows it to manipulate the color characeristics of the display. This makes it possible to emulate the shape and size of a different color space instead of using the native color gamut of the display. This means a wide-gamut display with a color gamut of about 100% of AdobeRGB (1998) can reduces in it’s gamut to e.g. the shape and size of an sRGB-display.

When a monitor emulates a color gamut it’s not possible any more to show higher saturated colors than the colors of the emulated color gamut. Even when the monitor is able to show those colors in it’s native color gamut.

Excluded from the emulation of the color gamut is the white point and the tonal response curve of the monitor (and of course the black- and white-luminances).

Tip: If a Wide-Gamut display should emulate a color gamut as good as possible then the color temperature and the tonal response curve should be calibrated to the native settings of the color gamut which should be emulated.

To activate a Color Space Emulation on supported displays just select an ICC-profile from the list. All ICC-profiles which are installed on your system are listed"

I hope this helps [yeah, beware bias, I sell basICColor]

neil barstow, colourmanagement

[TheDigitalDog]

When working with RGB working spaces, the display is divorced from the condition of the working space thanks to Display Using Monitor Compensation architecture. By design which is what we are trying unsuccessful to explain to you. You’re going down an unnecessary rabbit hole her.

[richardj21724418]

https://forums.adobe.com/people/D+Fosse  wrote

In theory you're right. In practice the sRGB emulation is setting the primaries very accurately, but doesn't bother with the tone curve. And honestly - why should it?

Because otherwise the TRC has to be handled by the LUTs in the GPU.  Depending on the GPU this may be 10-bit output, it may be 8-bit dithered to 10-bit or it may be 8-bit.  However it's done, it's not going to be better that doing it in the monitor.  A properly calibrated monitor should have a linear TRC written into the LUT in the GPU and therefore not introduce any 'stepping'.

Surely the TRC is the easy part anyway, compared with the colour space conversion?

Please forgive my ignornance and naivety.  I'm just a common sense kind of guy and not up with you brainy theory types!  However, it seems to me you either take a non-standard device and create a custom profile to describe the character of that device, or you take a standard profile and adjust the character of that device to meet the profile.  You're doing the latter when you calibrate a monitor to sRGB.

If you have a wide gamut native monitor that encompasses all of sRGB space it means that every point in sRGB space will have an optimal associated value in native space.  It's 'simply' a matter of translating every one of those 1024x1024x1024 (10-bit component) possible sRGB input values to the native value.  Job done!  The monitor should then behave as an sRGB device and the correct monitor profile will be the standard sRGB profile.  If you need to create a non-standard profile then the monitor hasn't been calibrated correctly to sRGB.  It seems odd to calibrate the monitor to meet a standard colour space and then repeat the process to calibrate the PC to the monitor (when you already know the PC LUTs should be linear and the profile should be sRGB).

[G_Hoffmann]

It might be helpful to have a look at the table values for the Gamma=2.2 TRC and

the sRGB-TRC (if the graph in #4 should not be sufficient), calculated for normalized

values 0.0...1.0 and shown for not normalized variables 0...255. The end of the linear

slope is at 0.03928 (10 of 255).

x     y1=x^2.2     y2=for sRGB     y3=y2-y1

The second table shows the values rounded for integers 0...255.

Best regards --Gernot Hoffmann

[D Fosse]

Yeah. The whole exercise is pointless. What you want is color management without color management.

The only reason you would ever want the monitor to accurately emulate sRGB, is if you're working without color management, in applications that don't do it. Then it's useful to limit the gamut to sRGB, so you're not completely thrown off track.

If, on the other hand, you want your sRGB content to be accurate, you work with full color management. End of story

FWIW - digging into the ColorNavigator software I see there are several advanced options for profile emulation, just as there are options for almost everything else under the sun including emulating an iPad and any other display. I might need that once or twice in my life, but for now I can't imagine what those situations might be.

[richardj21724418]

I'm sorry to bore you further with this but hopefully I'm nearing the bottom of the 'rabbit hole'.

I 'calibrated' the monitor to sRGB using PME.  Remember, there's no meaningful ICC profile output file produced by PME when calibrating to a standard colour space.  I assume you're supposed to use the standard profile file. e.g. sRGB IEC61966-2.1.  You guys will tell me that's wrong, although I still don't understand why.  If the monitor is properly calibrated to sRGB, then sRGB is the right profile to use.

However, I'm sure the monitor applies a single 2.2 gamma curve, not the correct sRGB TRC.  This means the standard sRGB profile won't be correct for the calibration, which rather defeats one of the main purposes of having a calibrated sRGB monitor, namely to be able to view non-colour managed applications correctly.

My work around was to produce a version of the sRGB IEC61966-2.1 profile, but modify it with a simple 2.2 gamma curve.  This seems to work well, although it doesn't help with non colour managed applications which blast image data straight at the display.  A real pity that.

To verify this I calibrated the computer to the (calibrated) display using i1Profiler.  This uses the same hardware and is based on similar software to PME, so you'd expect similar results....except the tone curves should get corrected.  Bingo!  To my eye I can't tell the difference between this calibration and the hardware calibration using my modified sRGB IEC61966-2.1 with linear LUTs in the GPU.  I should probably reserve judgement until I've done some difference blend mode jiggery with Photoshop to closer inspect the differences, but on initial visual inspection I'm blown away by the match.  For me it's further confirmation of the sRGB tone curve issue with the BenQ.

It's a shame BenQ haven't got this quite right.  The hardware calibration is very impressive and were it not for this TRC issue I think they'd have nailed it.  Really, it's how hardware calibration should work IMO.  If a monitor is properly calibrated to a standard space, you use the profile applicable for that standard space.  You should need to mess with creating a non-standard profile.  Why would you?  The monitor is calibrated to the standard profile.

I may try telling BenQ about this, but somehow I know, just know, it will be even harder than explaining to you lot!

[TheDigitalDog]

richardj21724418  wrote

I'm sorry to bore you further with this but hopefully I'm nearing the bottom of the 'rabbit hole'.

I 'calibrated' the monitor to sRGB using PME.  Remember, there's no meaningful ICC profile output file produced by PME when calibrating to a standard colour space. 

Sure there is. The calibration may be conducted in the panel like my SpectraView but an ICC profile still exists. It has to exist as all ICC aware applications still need that to conduct Display Using Monitor Compensation! The profile is meaningful. It's not loading a LUT itself to adjust the behavior to the display but none the less, it exists, it is used.

Now do you realize that sRGB is a synthetic construct? It's based on a number of constructs outlined above and based on, among other items, P22 phosphors. It isn't just three primaries and a gamma value. Your display is rather unlikely to produce sRGB as defined. The sRGB working space is yet another beast here. And as we've tried to tell you, the behavior of your display, set to some mimic of sRGB or otherwise, is separate from this and all other RGB working spaces, equally synthetic in construct.

IT doesn't matter a lick what the TRC or gamma of your display is. It's described by the display profile. It can be a mile away from sRGB just as it can be nothing like Adobe RGB (1998) or ProPhoto RGB yet you can still use all of those working spaces in a color managed application and produce 'correct' previews (if everything is working as it should, your software may not), DUE to Display Using Monitor Compensation. Hence the rabbit hole comment.

Yeah, perhaps it's a shame BenQ hasn't got this right. They certainly are not Eizo or NEC but want people to think they are. I have zero experience with them nor intend to but I have lots of experience with SpectraView and to a lesser degree Eizo and they do get this all right.

You get what you pay for.

[richardj21724418]

thedigitaldog  wrote

richardj21724418   wrote

I'm sorry to bore you further with this but hopefully I'm nearing the bottom of the 'rabbit hole'.

I 'calibrated' the monitor to sRGB using PME.  Remember, there's no meaningful ICC profile output file produced by PME when calibrating to a standard colour space. 

Sure there is. The calibration may be conducted in the panel like my SpectraView but an ICC profile still exists. It has to exist as all ICC aware applications still need that to conduct Display Using Monitor Compensation! The profile is meaningful. It's not loading a LUT itself to adjust the behavior to the display but none the less, it exists, it is used.

After calibrating to sRGB PME does output an ICC profile, but it's useless.  Regardless of the calibration colour space selected, the profile is always written for the native gamut.  This means colours look way undersaturated, as you'd expect for a profile that's been designed for a wide gamut.

Last year I had lengthy exchanges with BenQ about this (lengthy exhanges? Me?).  I could not get any sensible response and it didn't help that it was in garbled English. The order PME does things doesn't feel entirely right.  I tried to tell them that the profile was being created at the wrong stage, but they were having none of it!

Then it dawned on me that if the monitor is properly calibrated to a standard colour space, you simply use the standard ICC profile for that colour space.  Why not?

[TheDigitalDog]

richardj21724418  wrote

thedigitaldog   wrote

richardj21724418    wrote

I'm sorry to bore you further with this but hopefully I'm nearing the bottom of the 'rabbit hole'.

I 'calibrated' the monitor to sRGB using PME.  Remember, there's no meaningful ICC profile output file produced by PME when calibrating to a standard colour space. 

Sure there is. The calibration may be conducted in the panel like my SpectraView but an ICC profile still exists. It has to exist as all ICC aware applications still need that to conduct Display Using Monitor Compensation! The profile is meaningful. It's not loading a LUT itself to adjust the behavior to the display but none the less, it exists, it is used.

After calibrating to sRGB PME does output an ICC profile, but it's useless.  Regardless of the calibration colour space selected, the profile is always written for the native gamut.  This means colours look way undersaturated, as you'd expect for a profile that's been designed for a wide gamut.

Last year I had lengthy exchanges with BenQ about this (lengthy exhanges? Me?).  I could not get any sensible response and it didn't help that it was in garbled English. The order PME does things doesn't feel entirely right.  I tried to tell them that the profile was being created at the wrong stage, but they were having none of it!

Then it dawned on me that if the monitor is properly calibrated to a standard colour space, you simply use the standard ICC profile for that colour space.  Why not?

No, the profile is not useless. No, your display isn't properly calibrated to a standard color space. You were told how and why.

[richardj21724418]

thedigitaldog  wrote

No, the profile is not useless. No, your display isn't properly calibrated to a standard color space. You were told how and why.

I'm sorry. I guess you must find me incredibly stupid and tedious, but please bear with me on this a bit longer.

If I use the monitor in its native mode then, of course, I understand the need of a custom ICC profile to describe the monitor input response and to set the TRCs in the GPU.

However, if I switch to the sRGB emulation mode the input response obviously changes completely.  (e.g. in native mode an 8-bit RGB input value of 216/64/34 produces the same colour as 255/0/0 in sRGB mode - i.e. fully saturated sRGB red).  How can an ICC profile describing native mode be of use in sRGB hardware emulation mode?

I know the display isn't properly calibrated to standard sRGB colour space (that's where we came in!).Even leaving aside your issue with the P22 phosphors etc I know the monitor calibrates with a single 2.2 gamma curve.  If it calibrated with the proper sRGB TRC I think I'd be perfectly satisfied with using it with the standard sRGB profile.  I doubt 'soft' calibration of the PC to the monitor would improve on it.  Does soft calibration (putting the responsibility on the PC side rather than the monitor side) really give better results?  Why should it? (Apart from when monitor manufacturers get it wrong of course!).

[TheDigitalDog]

Again, I've told you, the display ICC profile is always used with ICC aware applications for previews using Display Using Monitor Compensation. It doesn't matter the conditions of the calibration inside the panel in terms of this NOT being used. The profile does what the name suggest; profiles the device behavior. It either does or it doesn't but either way, it's always being used in ICC aware applications. It doesn't matter the TRC or gamma of the display as you've been told repeatedly. The profile knows this (unless there's a bug in it's creation which is possible in your case). It doesn't matter whatsoever if the display is calibrated to sRGB as other's have told you. It might be IF you were NOT using color managed software but you should be and I assume are using color managed software. The gamma can be virtually anything for the display including native (which could be different than sRGB's 2.2 TRC) and you can use sRGB working space or any other working space and Display Using Monitor Compensation will as the name suggests, do it's job; compensate for the preview. FORGET the gamma curve of either sRGB's working space (it is fixed and what it is and should be). FORGET the TRC or gamma of the display. It's a rabbit hole.

The 'best' results come from calibrating a display for a desired condition for a desired goal; like matching a print and display as one example. I have no idea what your goal is. I have no idea why you think it's even necessary to 'target' sRGB even when the aim points don't match what sRGB is defined for (hence my question about cd/m^2 for both white and black).

You're making this far more complicated than necessary. And maybe that's due to bugs or weakness in the product you're using. But that doesn't change the facts of how this all works.

[TheDigitalDog]

richardj21724418  wrote

To verify this I calibrated the computer to the (calibrated) display using i1Profiler.  This uses the same hardware and is based on similar software to PME, so you'd expect similar results...

No, it absolutely isn't.