[jingai]

I have 3 displays that are calibrated to sRGB (roughly 2.2 gamma). I'm working with some low-key (dark background) photos I took recently in the studio. The images have all been adjusted so the backdrop shows as solid black on all 3 of my displays -- outside of XBMC (in Aperture, iPhoto, and in web browsers), that is.

In XBMC, on all 3 displays, it appears the gamma/brightness is incorrect (too bright). Does XBMC perhaps expect 2.0 gamma or something? I pulled them up side-by-side and adjusted the exposure in Aperture by two stops, which matches what I see in XBMC.

I am not sure if this only affects the picture viewer -- I suspect it doesn't, but I don't have the equipment to verify it. It likely also affects the GUI itself, and maybe video playback.

This is all tested on a 2012/12/14 Frodo nightly build (64-bit) on MacOS X 10.8.2 on a 2011 MacBook Air and a 2011 Mac mini, both with Intel HD 3000 chipsets.

[jmarshall]

Hi there,

XBMC assumes a linear colour space regardless of texture source. I believe this *should* basically cause no issues (sRGB will be interpreted incorrectly as linear ARGB, but on output this will be "fixed" though the blending might not be 100% correct).

However, to investigate this further, I'm doing up a build for you to test.

It will be available here: http://mirrors.xbmc.org/test-builds/osx/ in an hour or so. Look for the one with srgb_test in the name.

You configure it using <srgbtest> in advancedsettings.xml. By default there'll be no change. Set it to 3 for full sRGB (textures + framebuffer). Set to 1 for sRGB -> linear conversion of textures, 2 for sRGB framebuffer support only. Note that font colours will likely look odd.

Cheers,
Jonathan

[jingai]

Will test it tomorrow morning. Thanks for looking at the issue.

[jmarshall]

Here's the link in case you missed it:

http://mirrors.xbmc.org/test-builds/osx/...t-i386.dmg

Cheers,
Jonathan

[jingai]

Ok, had a chance to check this out (sorry, had family stuff to do last night). I have some screenshots to illustrate the issue. I am not sure you'll be able to see the problem though as it does require a monitor calibrated to sRGB (unless your display is brighter than it should be). And I guess different web browsers might do different things too, but.. maybe it will help.

If you look just above the tallest leaf of the poinsettias in the center and to the right of the right-most tree, you'll see small chunks of "contamination" (what photographers call light pollution on the backdrop). The smudges are what I burned out because the light was visible there --- but you can see my smudges here because the surrounding light is also visible, when it shouldn't be.

srgbtest=0 (for reference):



3 - Very close to srgbtest=0, but actually a bit brighter, when it should be a bit darker actually:



1 - Way darker than it should be:



2 - Way brighter than it should be:



Basically, 0 is best, but as noted it's about 2 stops brighter than it should be.

BTW, the fonts didn't really look odd at srgbtest=3, just a bit brighter than they are normally.

[jmarshall]

My guess is that whatever is happening after the window manager gets hold of it may not be assuming a "correct" gamma amount. Not really sure though to be honest.

I'll try and get hold of some calibration images and do some comparisons - do you happen to know of any good ones? I presume OSX's preview correctly displays things?

Cheers,
Jonathan

[jingai]

Yes, Preview displays my images correctly.

I calibrate my displays with a colorimeter and dispcal (hardware + software), but here is a decent image for at least brightness/gamma:



It's incredibly difficult to eyeball it though.. especially with LCDs that are so sensitive to viewing angle.

I kind of forget how to use that exactly.. but iirc, while squinting, for the gamma bars, 2.2 should be the transition mid-point from where it appears white to where it appears dark grey -- that is, neutral gray. Still squinting, the black level A column should be solid black by 1.8, and B column will be solid black by 1.6. It's far from scientific, but it gets you into the ballpark anyway.

Again, thank you for looking at this. I know this seems so minuscule but it makes it really hard to proof low-key photos otherwise -- I like to display the photos via XBMC for family members for them to choose which ones to send to the printer.

Just had a thought though.. if you pit XBMC vs Preview with this image (the gamme/black level one) on the same display, I'd think it should be pretty obvious when it's off. Might make a decent test case at least, without having to actually calibrate your own display. Unless it's so far off that you're missing details in the middle anyway.

[bossanova808]

@jingai - what brightness are you calibrating your screen to?

There's a BIG difference in the output path between XBMC and your other imaging apps, all of which will do a full transform of the image colours through the monitor profile. Depending on what you are calibrating, and how, it may well be that your monitor profile is doing some significant correction, and/or has vgct (LUT) tags. XBMC is not ICC aware so it will not be reading incoming tags (although one presumes it assumes sRGB) and will not be transforming based on the profile....so one should expect the two to be noticeably apart...

(NB Preview has a chequered history for colour management - e.g. it was (still is?) broken for multi monitor setups for some time - definitely best to use PhotoShop if you really want to check all this out)

(Also - one doesn't 'calibrate to sRGB' but I presume you know that and are short-handing for clarity... )

(And from a photography perspective - 1. get some real velvet for your back drop - every photog. should have a large piece of this in their studio kit, and 2, put the background way further back! and 3, in post if you have overlit it somehow - clip it out to RGB 000 for pure black)

As a professional photographer I can't say I have noticed a significant issue of the level of two stops when using XBMC as a slideshower on my (calibrated) Pana Plasma. But until now I hadn't really thought about it.

Can you provide more technical detail on what, and how, you are calibrating?

I have here a ColorMunki, i1Pro, i1 Display Pro, Spyder 4 and more to experiment with....so far though I have only used the i1 Display Pro on the plasma, and haven't looked at XBMC on the desktop....I might try that now....but Windows here, not Mac.

[bossanova808]

Ok so I have done some testing.

My desktop is an NEC PA271W (and I cross checked on an Eizo CG243W just to be sure). Basically these are two benchmark reference monitors for imaging work....

Direct Hardware calibrated using SpectraView 2 and an i1Display Pro (ColorNavigator on the Eizo).

Images displayed are the standard PDI test image and Getty's Test image (both readily available - e.g. PDI http://www.gballard.net/dl/PDI_TargetFolderONLY.zip ).

There is definitely NOT an order of two stops difference between XBMC and Photoshop (or a difference even of gamma 2.0 to 2.2).

There IS a minor difference between the display, though, precisely what I would have expected really - it's clear the PS image is going through the monitor profile (correctly) and the XBMC one isn't. This leads to minor differences in saturation (XBMC is slightly undersaturated) and XBMC has *slightly* elevated shadows....

I don't think XBMC has any issue here, really - it's behaviour is precisely as one would expect a non ICC aware slideshow app to be (on Windows, at least).

On Openelec( ie linux) - and various setups - there can be issues with the whole full/limited RGB range that play into this also.....I don't have a clear understanding of that, though, as by receiver/tv/and desktop monitors are all cool with 0 to 255....

[jmarshall]

Ok, I found a better image (the above one is not sRGB) to use, and produced 3 test images:

1. Screenshot using OSX screenshot of XBMC displaying the image.
2. Screenshot using OSX screenshot of Preview displaying the image.
3. Screenshot using XBMC of XBMC displaying the image, loaded into Preview (telling it to interpret the PNG as sRGB), then screenshot using OSX.

I then cut out the relevant sections and did a subtraction, producing new PNGs for each of the pair-wise differences.

Results were:

1. There was no difference at all between grays between any of the pairs.
2. There was a difference between the colour however between the pairs 1 and 2 and 1 and 3.
3. There was no difference at all (subtraction 0 except for the occasional pixel which was at most 1 bit different per colour channel, less than 1% of pixels affected - i.e. what you might expect from rounding) between pairs 2 and 3.

This says to me that Preview is applying colour correction for the display (i.e. mapping from sRGB to whatever the display colorspace is) but is not altering the brightness of the image overall. i.e. in my case it's adding blue to the pure-green colour bars as the backlight in the MBP display is likely a little bit yellow. It's adding a little bit of blue to the red channel as well, and is adding a touch of red to the blue channel. I suspect on your display the same thing is happening, but it's resulting in a difference in brightness.

Clearly this isn't being applied to the GL output. The trick now is whether we can get this information and, if so, whether it's easy to apply it... Initial research seems to indicate that the APIs that OSX provides for these things have the habit of going deprecated...

In addition, it's not clear to me that we should need to. We essentially output sRGB (though it's not technically sRGB in terms of blending, so crossfades will be ever-so-slightly off, as will fades to black) so the display (if the display itself has calibration potential) could apply any calibration. The issue here is that you have individual apps required to apply the calibration.

If we wanted to do colour calibration in the app then that would have to be done via an additional shader (doable for the slideshow - not sure if it's doable across the board).

Cheers,
Jonathan

[bossanova808]

That's all as expected (and yes, derr on the image being in AdobeRGB and therefore the saturation diffs - re-doing with an sRGB version it of course results in expected behaviour - which is what you get for trying to work and play at the same time!!)

[jingai]

XBMC is not ICC aware so it will not be reading incoming tags (although one presumes it assumes sRGB) and will not be transforming based on the profile....so one should expect the two to be noticeably apart...

Yeah, this is probably what's going on. I guess I just hadn't expected the brightness to be quite as corrected as it is.

(NB Preview has a chequered history for colour management - e.g. it was (still is?) broken for multi monitor setups for some time - definitely best to use PhotoShop if you really want to check all this out)

I appears to work on my displays here. MacOS X 10.8.2.

(Also - one doesn't 'calibrate to sRGB' but I presume you know that and are short-handing for clarity... )

Yup, just trying to keep it simpler. But my targets don't really matter for the sake of this discussion anyway really, just that there is a difference between XBMC and color-corrected apps. Which is expected, as you pointed out.

(And from a photography perspective - 1. get some real velvet for your back drop - every photog. should have a large piece of this in their studio kit

I'm not a pro -- this is just for fun/hobby. I understand cloth would be better, but paper was cheap and easy to deal with is all.

and 2, put the background way further back! and 3, in post if you have overlit it somehow - clip it out to RGB 000 for pure black)

It's in my garage.. that was as far back as I could put it comfortably. It's not quite a professional setup

As a professional photographer I can't say I have noticed a significant issue of the level of two stops when using XBMC as a slideshower on my (calibrated) Pana Plasma. But until now I hadn't really thought about it.

Can you provide more technical detail on what, and how, you are calibrating?

I used a Spyder Pro 3 with Argyll CMS/dispcalGUI/dispcal. The brightness target was 90cd/m2; whitepoint to 6500K; white and black levels as measured; and sRGB tone curve.

---

On Openelec( ie linux) - and various setups - there can be issues with the whole full/limited RGB range that play into this also.....I don't have a clear understanding of that, though, as by receiver/tv/and desktop monitors are all cool with 0 to 255....

FYI, this isn't an issue here either -- my displays all accept full RGB.

---

If we wanted to do colour calibration in the app then that would have to be done via an additional shader (doable for the slideshow - not sure if it's doable across the board).

If it could be done easily enough for at least the slideshow that would be fantastic. Since I'm the author of the material I view there it's really obvious when it's not 'right'. For movies and shows, I don't know what it should look like, so it bothers me a lot less.

If it's really difficult to utilize the display profile in the slideshow, maybe just allow the brightness to be adjusted? It'd be better than nothing in this case.

[jmarshall]

Nope - you'd need it to be color corrected. As I said earlier, my display (MBP) is actually fine in terms of brightness (i.e. grayscale output from XBMC is exactly the same as any color-corrected app - just the color isn't quite right.

It's a relatively simple operation (essentially you construct a 3D texture lookup table and apply it in a shader) - the tricky bit is getting the 3D lookup table. On OS X, the APIs to use aren't documented.

I'd certainly support work in this area - it would mean switching the GL chain there to use shaders for OpenGL, though we should really do that throughout.

Cheers,
Jonathan

[bossanova808]

Wouldn't it be simpler just to apply a transform to the image data before the rendering pipeline? I.e. do a convert to profile first... Then the RGB numbers are already converted to the monitor space. http://www.littlecms.com/ is a c based open source library for doing this sort of thing....

---

@jingaii Can you pm me a copy of your Icc profile and a decent sized jpg of the original image for a bit of testing? I am away today but can give the profile a good look tomorrow.

[jmarshall]

bossanova808: We could, but that would apply only to pictures - further, the blending would be further wrong (though that probably isn't an issue, as alpha should still be linear). It'd be nicer to have a general solution, however, as then we can apply it across the board.