Skip to main content

⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

possible layer-related color space bug

Jakub Ostrowski
Hi,

I've just reported a possible layer-related bug in Capture One Pro 11 on Windows. Below I'm mostly pasting what I wrote to the tech support but I'm really curious if anyone else can replicate the problem.

I'm providing a sample catalog with one adjusted image to illustrate the issue: https://www.dropbox.com/s/hwk3whpf4m0y2 ... g.zip?dl=0

It looks like using Color Editor on a layer sets the color space to sRGB or some other space with reds' coverage similar to those of sRGB. The problem does not occur when using Color Editor on the background layer.

To reproduce the issue and understand what I mean consider following the steps below. Of course you need a display that covers much broader range of reds than sRGB.

1. Find the single highly-saturated red brick roughly in the middle of BB-8's body 😉
2. Enable Recipe Proofing on sRGB profile should illustrate that this brick is indeed far beyond sRGB.
3. Disable proofing.
4. Enable 'base' layer. The brick should appear less saturated - similar to what it looks like during sRGB proofing.
5. Take and look at a layer mask - it covers only the bottom area of the image and the adjustment doesn't even target reds.

I was able to reproduce the problem with various other images taken with Canon 6D and Canon 50D.

I use Capture One Pro 11.0 on Windows 10 Pro, version 1709, build 16299.25. GPU: MSI Geforce GTX 1080 Gaming X, display: EIZO CS240 profiled to native color space using the latest version of ColorNavigator.

Two additional remarks:

1. I exported tiff files with prophoto rgb and dci-p3 color spaces and opened them in Photoshop. They retain proper colors despite the wrong look in C1Pro.
2. I've just checked and the issue does not occur on macOS.

Best regards,
Jakub
0

Comments

10 comments

Date Votes
  • Dave R
    The effect is extreemly subtle, 1 or 2 decimal place in the (new) LAB readout. I had great difficulty seeing it on my wide gamut NEC PA241W monitor.
    One thing to note is that you no longer have to set a particular output recipe in the output tool tab, you can select it directly in view/proof profile.
    0
  • Jakub Ostrowski
    Visually the effect is not subtle - the display I use substantially exceed aRGB and sRGB in the red part and actually I find the difference striking. I can't see what I'm doing so what's the point of fancy displays or fancy new layers in Capture One 11? 😜
    0
  • Jakub Ostrowski
    [quote="David532" wrote:
    The effect is extreemly subtle, 1 or 2 decimal place in the (new) LAB readout. I had great difficulty seeing it on my wide gamut NEC PA241W monitor.


    I've just tested a few images with prominent blues and greens and I suspect that the wrong color space might be aRGB instead of sRGB. Blues almost do not change, reds are changed terribly and greens somehow. It makes a lot of sense because new displays try to cover DCI-P3 and aRGB and this is exactly the difference between these two spaces. Your old NEC most likely covers only aRGB so the effect on the reds may not be visible.

    Anyway, aRGB or sRGB - the problem still exists. Colour space changes due to using Color Editor on a layer and that's not good.
    0
  • Dave R
    I withdraw all I said above 🤭 I have now looked at your example again with proof profile set to none and with base not selected the red tile reads R105 G15 B7 Brightness 41. When I select base the reading changes drasticly to R133 G0 B0 Brighness 40 which is exactly the reading I get for the base background picture if I select AdobeRGB as the proof profile.
    0
  • SFA
    Jakub,

    Given that the exports look OK and there is no problem in Mac world I thought I wouodl experiment briefly with this interesting observations - especially as you have been generous enough to provide all of the working data in advance!

    So I'm working on a decent quality laptop screen but it's not especially colour calibrated. However in theory I should still see some changes in the values of colour pins following your instructions, right? maybe not as obvious but at least something.

    And I do ... but very small differences and extremely localised on the red square. (Where does that come from by the way? It seems to be somewhat transparent.)

    Viewing the red square at 400% I can place several colour pins on it and I manages to find 2 points, more or less just around the centre of the square, where the blue readout value changes.

    For the two spots in question the readouts are (sRGB active)

    Red : 165 or 164
    Green: 0
    Blue: 1
    Lum: 49

    If I activate you base layer the blue value changes to 0. All other values stay the same.

    If I change to AdobeRGB the values change on most pins but the Blue value on those points goes to 0 and changing to base layer makes no difference.

    However another pin in the upper right corner, a darker area, does then report Blue = 1 and changes to 0 when the base layer is active.

    However 6 surrounding points do not change at all.

    Setting NO Proof Profile of curse gives different starting values.

    If I turn on your "background" layer (Not "Background") nothing happens. The readouts stay the same as No Profile.

    When I activate your "base" layer the readout change to be the same as the AdobeRGB values.

    As it happens the aRGB profile was the last profile I had set MANUALLY and directly - i.e. NOT through the Proof Profile or the Process Profile.

    I MANUALLY set the profile back to sRGB and now the sRGB numbers appear rather than the aRGB numbers.

    So for some reason the "base" layer is always using the last set "manual" profile and ignoring the Proof Profile and Process Profile settings. Or so it seems.

    But why not the "background" layer too?

    I though I would report what I have found so far to see if it prompts any ideas about what might be happening.

    It looks quite obscure at this point.


    Grant

    ETA:

    There were a couple of adjustments set at the Background layer - a slight change to the RGB setting in Levels and the Clarity tool set to use "Punch".

    Creating a cloned variant I removed those two adjustments and see different readings on the colour pins (as expected).

    Still the "background" layer has no effect but the "base" layer now changes more numbers in more colour pins and by larger (though still small) amounts.

    I can only see two logical cues at the moment.

    1. The second layer (and above?) in the stack is a problem althogh the first is not.

    2. Something to do with the way the Colour Editor tool is working as part of the stack.

    So I cloned another variant, deleted the "background" layer to make "base" the only layer in the stack and the effects were the same.

    Thus right now I would conclude that something to do with the way the Colour Editor is working with Proof Profiling is the most likely route to investigate.

    But, software being software, it could be something else.
    0
  • Jakub Ostrowski
    [quote="SFA" wrote:

    So for some reason the "base" layer is always using the last set "manual" profile and ignoring the Proof Profile and Process Profile settings. Or so it seems.

    But why not the "background" layer too?

    ...

    I can only see two logical cues at the moment.

    1. The second layer (and above?) in the stack is a problem althogh the first is not.

    2. Something to do with the way the Colour Editor tool is working as part of the stack.


    Thank you for your detailed investigation! I'm glad I'm not the isolated case and I can see we got very similar conclusions. Your observations confirm mine - for this and other images I checked - Color Editor works fine on the background layer but it causes problems on any additional layers. For me it looks like a bug, a small oversight in color management when implementing layers in C1 11? Certainly it doesn't seem to be any intentional behavior because the mac version is not affected.
    0
  • SFA
    [quote="cespenar" wrote:
    [quote="SFA" wrote:

    So for some reason the "base" layer is always using the last set "manual" profile and ignoring the Proof Profile and Process Profile settings. Or so it seems.

    But why not the "background" layer too?

    ...

    I can only see two logical cues at the moment.

    1. The second layer (and above?) in the stack is a problem althogh the first is not.

    2. Something to do with the way the Colour Editor tool is working as part of the stack.


    Thank you for your detailed investigation! I'm glad I'm not the isolated case and I can see we got very similar conclusions. Your observations confirm mine - for this and other images I checked - Color Editor works fine on the background layer but it causes problems on any additional layers. For me it looks like a bug, a small oversight in color management when implementing layers in C1 11? Certainly it doesn't seem to be any intentional behavior because the mac version is not affected.


    Possibly a bug but from what I saw the change is so minor (on my screen) that is would not be noticeable - even at 400% It's a value on a single "colour" (only ever one colour as far as I have observed in my setup) that changes by 1.

    Moreover this could be more of a rounding discrepancy in the display more than an observable colour shift (other than on extremely colour sensitive screens for certain colours).

    Bear in mind also that in that entire patch of redness I have only found 2 small sections that seem to shift at all. There may be more but most of the area - notably the darker parts - show no change at all in my tests.

    It will be interesting to hear what the Support Team come up with.

    Have you created a Support Case?


    Grant
    0
  • Dave R
    [quote="SFA" wrote:
    [quote="cespenar" wrote:
    [quote="SFA" wrote:

    So for some reason the "base" layer is always using the last set "manual" profile and ignoring the Proof Profile and Process Profile settings. Or so it seems.

    But why not the "background" layer too?

    ...

    I can only see two logical cues at the moment.

    1. The second layer (and above?) in the stack is a problem althogh the first is not.

    2. Something to do with the way the Colour Editor tool is working as part of the stack.


    Thank you for your detailed investigation! I'm glad I'm not the isolated case and I can see we got very similar conclusions. Your observations confirm mine - for this and other images I checked - Color Editor works fine on the background layer but it causes problems on any additional layers. For me it looks like a bug, a small oversight in color management when implementing layers in C1 11? Certainly it doesn't seem to be any intentional behavior because the mac version is not affected.


    Possibly a bug but from what I saw the change is so minor (on my screen) that is would not be noticeable - even at 400% It's a value on a single "colour" (only ever one colour as far as I have observed in my setup) that changes by 1.

    Moreover this could be more of a rounding discrepancy in the display more than an observable colour shift (other than on extremely colour sensitive screens for certain colours).

    Bear in mind also that in that entire patch of redness I have only found 2 small sections that seem to shift at all. There may be more but most of the area - notably the darker parts - show no change at all in my tests.

    It will be interesting to hear what the Support Team come up with.

    Have you created a Support Case?


    Grant

    Not minor at all and quite visible; see my reply in viewtopic.php?f=72&t=27465#p130133

    Pre requisits are a wide gamut monitor and to make sure you have enable recipe proofing turned off and none or Pro-photo selected for proof profile then switch the top "background" layer on and off.
    The interesting thing is the RGB reading for the red tile when the "background" layer is on is the same as if the proof profile for the Background (the very bottom below the layers) was set to Adobe RGB rather than none or ProPhoto RGB.
    0
  • Jakub Ostrowski
    Exactly as David532 wrote - it's a striking effect, even on a small brick. Now put there a flashy red car or bright red clothes and you get very different and wrong perception of your image. I don't know what display you use but in order to see it you need a wide-gamut panel with reds exceeding aRGB coverage. On displays that pretend to be DCI-P3 compliant this problem should be perfectly visible.

    I created a Support Case but so far I'm very disappointed with the confusing answer I got. I'll keep you in loop if things would clarify.
    0
  • SFA
    I can only report what I can see on my Laptop screen.

    I have in the past on other computers with not very impressive monitor specifications seen some quite dramatic reds, oranges and yellows responses for very slight adjustments even when editing jpgs. The applications I was using at the time were not Capture One - might have been an early LightRoom. Could have been something else.

    Whether the effect appears to be dramatic or not is not really the issue. The change in the calculation that creates the appearance of the dramatic result can be quite tiny - or at least that is what I found back then.

    I would guess that the steps involved require multiple conversion tables and no doubt some aggregation of values during the calculation pipeline. For your high end screens the differences in the results of the changes sound like they are more dramatic than I can force on my lower end screen.

    I would guess that what I am seeing is more representative of a typical output capability that you also see when exporting tiffs and on your Mac.



    Grant
    0

Post is closed for comments.