Colors Inconsistent between applications, Adobe apps vs Chrome, Photos, Etc…

Home Forums Help and Support Colors Inconsistent between applications, Adobe apps vs Chrome, Photos, Etc…

Viewing 4 posts - 16 through 19 (of 19 total)
  • Author
    Posts
  • #21160

    Vincent
    Participant
    • Offline

     

    I re-calibrated using the old Sypder 2 and DisplayCAL but this time I set Tone Curve to “sRGB” in the Calibration tab (it was previously set to Gamma 2.2). I don’t know if this was the “right” thing to do or even exactly why it worked but now the Adobe applications more closely match what I see in non-color managed apps.

    So I THINK my issue was the profile created when I originally calibrated. The color managed apps were referencing that profile and showing me the “badly” color-managed version. Once I re-calibrated with the new tone curve, the profile that loaded in those apps is now accurate and reliable. Am I correct in this assumption? Because I can also imagine that what I did was essentially the same as limiting the color range to sRGB. If someone who understands this better would like to elaborate I’d love to satisfy my curiosity!

    I have to be honest, even if my solution isn’t technically perfect I’m okay with that. Because now I can edit in those programs and what most people see is closer to what I want them to see.

    Let’s make a guess. Let’s say that your Syncmaster colorspace, RGB primaries location, are exactly the same as RGB primaries from sRGB. It’s a common sRGB-like monitor after all.

    If you put as calibration target sRGB TRC and it calibrates to it, and after calibration TRC is measured and stored like perfectly neutral (single curve+matrix), if all these requirements are met, then a sRGB JPG shown in Paint (no color management at all) will match to a certain degree the same sRGB tagged image in Photoshop (PS).
    Why? If monitor gamut and TRC matches sRGB (to som degree)… Photoshop do nothing. The same RGB values stored in image are going to be sent to screen.

    Let’s say that you calibrate to 2.2 or 2.4. DisplayCAL does its job and measures display aftyer calibration to make a profile. Such post calibration measurement results in a “single curve + matrix” ICC profile (because you chose that).
    Your sRGB JPG if opened in paint will send RGB values in image to your screen without any transformation… but your screen is 2.4 (for example), hence it will look darker that it should be. The image you see in Paint for that 2.4 gamma display is wrong (wrong= not as intended)
    Now yo go to PS, open same sRGB JPG. PS knows image profile (because itis -should be- tagged, profile  is embebed in image). PS knows your display profile too (it asks your OS about it). Hence PS make a color transformation from RGB values stored in your JPG image to OTHER DIFFERENT RGB values that in YOUR display represent the same color.
    That’s why even in sRGB images there is a difefrence between non color managed and color managed apps.

    A “no color transformation” is an identity maping from 256 values per channel to the same 256 values per channel. But *if* PS need to color manage between diferent gammas you won’t hace a 256 to 256 mapping, some “unique” values are going to be lost. Gradients reveal this issue.
    Same will happen if you choose a profile type with 3 different TRC instead of that “single curve + matrix” profile.
    To solve that issue there are some ways, like dithering in calibration (GPU) or in the final transformation made by color managed application, or to use more that 256 vales per channel in calculations.
    It is possible that as a result you see banding (steps, even colored steps in grey) in gradients in color managed apps but you do not see it in MS Paint. It is possibe that you see banding on both, and that is usually a calibration issue caused by GPU (or a bad measurement device).

    Another source of mismatch is monitor’s colorspace. Let’s say that you buy a new monitor, not a widegamut but a good cheap sRGB-like LED monitor. For example an U2415: cheap, good, functional.  Let’s say that this display colorspace when you intersect it with sRGB (“intersection” like set theory in school) it covers 100% sRGB. That DOES NOT mean that display colorspace is EXACTLY sRGB… it’s actually a little bigger. RGB primaries are a bit more saturated than sRGB.
    That means that your sRGB image in MS paint will look MORE saturated (by a little amount but maybe noticeable, like in your sample screenshot) in MS paint than what actually is.
    Using PS softproof you can test it too, google it. Even simulate how it will look on other screens if your display gamut is big enough to cover those otehr screens colrospaces.

    So we have seen 3 different types of mismatch between color managed and not color managed apps.
    If you “MUST” use non color managed apps because of reasons, an sRGB TRC as calibration target like you did is OK with a display with a colorspace  that is “exactly” sRGB  (not common in new ones) or that has some OSD mode limited in gamut to sRGB (not cheap). If you buy a new monitor, even an sRGB-like one, you may experience that saturation issue (because gamut is a little bigger… or smaller) and there is little you can do as a general rule other than use sRGB OSD mode.

    I would choose another way: force yourself to use color managed apps. Firefox is color managed (but you need to configure some things). You have GIMP/PS/Lr.. etc that are color managed too. There are some free video players that are colot managed (for spare time / home use). Etc…

    • This reply was modified 4 years, 4 months ago by Vincent.
    #21162

    Wire
    Participant
    • Offline

    Vincent, can a display profile restrict display gamut that exceeds sRGB to bring it in line with sRGB? I’m not talking about soft-proofing, but same idea.  Say I have a wide gamut display that completely covers sRGB and I choose sRGB preset in DisplayCal, once the profile is installed, will my display be restricted to sRGB?

    #21164

    Wire
    Participant
    • Offline

    Brittany, it’s great to hear from you because you began the convo in terms of problems and uncertainties experienced from perspective of a straight-forward imaging use-case without rushing into the dweeby aspects.

    The difficulty you experience defines this tech.

    And don’t get me wrong, DisplayCal / Argyll software is supercool and it really works within scope and limits of its design. My ravings are about the industry context into which these tools fit, and about how because of, and in spite of, excellent but very nerdy tools, this tech has not lived up to its promises as articulated back in day of founding of ICC and what some guy who started a little company said about creating a “computer for the rest of us.” (Ah well, it was prolly just marketing BS.) My point is this stuff has become a sort of mania.

    You shouldn’t get new displays. Your 10 year old gear is now the mature state of the industry and its capabilities agree with your goals. So yes take contentment and get on with your work.

    I want to add a bit of a clarification about expectations that is a recurring source of confusion: It’s the profile you assign to your images that define what we can hope to expect others will see, not your display calibration. If your displays have a bias—do something non-standard—your edits will tend to produce the inverse of that bias. If your display is too dark, your edits will tend to cause lightening on a standard display. If your hue is too green, you edits will lead others to see magenta. This is because your local compensations for the bias have you pull in the opposite direction.

    The point of a good calibration it to give you access to the full range of capability of your gear. And to provide confidence that others taking similar care will receive a predictable result of your work. I may seem to be splitting hairs here, but it’s vitally important to grasp that getting your alignment right does not ensure that anybody else sees what you want them too. It only increases the likelihood of fidelity. And when there’s a discrepancy you have some way of coordinating collaboration.

    What’s interesting to me about all this imaging tech is the conflict between the overt principles and claims of the utility of diligent alignment to standards and ever increasing struggle to inderstand why things are going wrong.

    We all know how much fun it is to swill in the complexity. But we also have to face how  it seems the uncertainty and “error” expands to forever exceed the know-how. For me, and many people I know, the perseveration over technical details is a compelling distraction from the truer problem of not knowing what else to do with the insanely great power of the new medium, and being thwarted in the use of the medium by crazy behavior of the tech.  Industry tends to not care about my conundrum because everything is self justifying to the churn of growth: Find a spot in the school and swim. This seemed fine 50 years ago in an infinite world. Now its time to question more about the intentions of design, and this brings us to use-cases.

    I would love to get started on the debacle called BT.1886 in video.

    (As I am typing this, the text is spontaneously disappearing and reappearing into the form background—the cursor has the right position tho!—and I’m using the most popular OS for web access in the world.)

    #21166

    Vincent
    Participant
    • Offline

    A profile is a DESCRIPTION of some device color bahevior. It does nothing. You need some color management engine to do those things using profile information.

    As an addition, ICC profiles for displays contain a VCGT tag, 3 x 1DLUT tha onde loaded into graphics card can correct white, grey and gamma. Just that. No gamut restriction (“gamut emulation” as it’s usually called).

    Some GPUs have HW lut-matrix-lut structures to perform a simple gamut emulation. ATIs (AMDs) do have them since 15 years ago, but AFAIK it is not exposed in a common structure so ArgyllCMS or other programs can use it in a vendor agnostic way. Maybe Florian knows more about that, or ArgyllCMS maillist.
    At least AMDs do have it and their driver allow some kind of sRGB gamut emulation based on EDID data. Hence it is not user measurements driven and cannot be considered accurate. I mean, AMD driver compute a Lut-matrix-lut that transforms RGB numbers encoded as sRGB (input)  to RGB numbers encoded as EDID says this display “should behave”.
    Also it’s a little hiden option under weird name of “color temperature = disabled” ¿??¿?¿?¿? Old ATI drivers say a more informative name “EDID data”.
    Right now is under Display > Color >”color temperature = disabled” (names may vary, non english UI)
    Also it seems compatible with 1D LUT from profile, so de-gamma or reencode of gamma in those 2 LUTs in HW should be composed of their calculated data (2.2 or 2.2 inverse) and VCGT info loaded into GPU in 1 of them. For more information look for AMD/ATI AVIVO engine papers on google.

    For example let’s say that an HP LP2475 do not have sRGB mode in OSD. It’s an old Widegamut CCFL, green almost AdobeRGB, red more saturated than sRGB/AdobeRGB.
    IF, and it’s a BIG if, EDID data regarding primaries is more or less accurate, if you enable this option on MS windows AMD driver, it emulates “something close to sRGB” on the fly on GPU. At least visually it looks sRGB.

    • This reply was modified 4 years, 4 months ago by Vincent.
Viewing 4 posts - 16 through 19 (of 19 total)

You must be logged in to reply to this topic.

Log in or Register

Display Calibration and Characterization powered by ArgyllCMS