- This topic has 61 replies, 6 voices, and was last updated 1 year, 1 month ago by
.
-
Posts
-
I think I finally figured out what you were referring to, which is the “Custom RGB” option in Photoshop (?), that lets you create a new colorspace. It took me some googling to realize that option even existed. For others interested, I attached screenshots of where it can be found. If I select sRGB primaries with 2.2 gamma it behaves exactly as you described. That was a big part of my confusion.
You can create a synth profile with DisplayCAL (see its folder), then install it into your OS (copy to OS profile folder). When you open PS or other tool it should be available as image colorspace (amogst all other profiles in your system).
Ah, so that’s how one usually makes the synth profiles. Cool!
After re-calibrating both my monitors, the results are much nicer. I tried both the simple curve and the XYZ + matrix settings, but I didn’t see a big difference in the amount of banding. After reading about how it works (http://www.gamutvision.com/docs/blackpoint.html) I wonder if it’s actually the Black Point Compensation that made the biggest difference? The deep darks are now behaving much smoother. The overall result is still brighter than I would have expected, but there is not the same sense that something is clearly wrong.
…
I’ve also tried to verify the uncalibrated performance of my office monitors. All the artists use Dell U2718Q’s which we have been told not to mess with since they are already “perfectly calibrated from the factory”. However, it’s also 4 years since they left the factory.
I reset them both to factory settings and ran a Verification. According to one review, this display should match the sRGB Gamma curve at default settings, but the results don’t look super promising.
I attached the reports and the settings I used in DisplayCAL. Did I do it correctly?
I’ve also tried to verify the uncalibrated performance of my office monitors. All the artists use Dell U2718Q’s which we have been told not to mess with since they are already “perfectly calibrated from the factory”.
They are not.
However, it’s also 4 years since they left the factory.
They were not and now they are oof from that starting point.
I reset them both to factory settings and ran a Verification. According to one review, this display should match the sRGB Gamma curve at default settings, but the results don’t look super promising.
No, they look like 2.2-2.1 gamma with a bending near black due to limited contrast.
I attached the reports and the settings I used in DisplayCAL. Did I do it correctly?
For verificating only applies instrument tab (CCSS correction) and verification tab. If you wish to test if factory calibration (or HW calibration) matches some colorspace like SRGB is your example it is done that way
The most confusing part is the “Assumed target whitepoint” of 7600K in the report. I’m confused if the settings in the “Calibration” tab also affect the “Verification”?
No. Only instument tab (CCSS) and verification.
It means that white is in isotherm 7600K (bluer than D65) and with an additional pink-green error (tint) about 5dE.
7600K with <1dE means ehite is cooler than D65 but “white”, 5500K with <1dE means warmer than D65 but “white”. With “white” meaning natural whites from cool to warm but no pink or green tint on them.Grey calibration (grey color, ignoring gamma) is very bad on both with a progresive color tint shift from neutral to green in the 1st one and to yellow in 2nd. Measured values on grey ramp, L*a*b*. Google about a* b* coordinates if you do not know them (pink.-green, yellow-blue axis).
I would lower brightness on both unless you are using it outdoors or with extremely high ambient light. Value? whatever you find conformtable. 100-160cd/m2 works for many people, YMMV.
Great – I feel like I’m beginning to understand things.
The screens were way too bright for sure, I just wanted to test it when everything was “pure factory settings”. I did an additional test after setting both monitors to 160cm/m2. The gamma charts were more consistent between them, but besides that everything was still out of whack.
Having worked at multiple game companies and knowing many digital artists (Illustrators, Concept Artist, 3D Artists), I have never met anybody else who have cared about color management. The most common reasons are “I don’t know how it works and don’t want to mess up my colors” or “My monitor is already factory calibrated so it’s not necessary.”
I guess it’s just reality that most of the type of art I work with, in other words most of the stuff uploaded to sites like ArtStation is likely to look slightly worse on a calibrated display since they were not created properly in the first place. (for some reason a lot of these images aren’t automatically adjusted in Chrome after profiling either). And the same applies to the art in many if not most games. I guess the only solution is to try to get as many apps and games color managed as possible.
Thanks for all your help, Vincent. I’m curious, do you work this this kind of stuff professionally?
…
One remaining question I have is why you suggest the 2.2 Tone curve setting for unmanaged apps instead of sRGB. Doesn’t most unmanaged content assume the screen is sRGB, meaning sRGB images would then look better in an unmanaged image viewer, for example?
I guess the only solution is to try to get as many apps and games color managed as possible.
Just encode content in the “common” colorspace. CAD/CAM software may ask them how to render (gamma to encode, even if CAD/CAM software won’t care about colorspace boundaries assuming sRGB’s).
One remaining question I have is why you suggest the 2.2 Tone curve setting for unmanaged apps instead of sRGB. Doesn’t most unmanaged content assume the screen is sRGB, meaning sRGB images would then look better in an unmanaged image viewer, for example?
unmanaged apps won’t care… hence encode your conent for the common target.. They do not assume sRGB, they just dont care, direct RGB output to screen 1 to 1 translation. As you see from your monitors that common ground is likely to be 2.2 than sRGB TRC (dark grey behavior before the “bend” of the gamma curve due to limited IPS contrast, see gamma plot in reports)
Color managed apps MAY be forced to read unmanaged content as sRGB, like HTML colors in Firefox/Edge… etc but actual TRC may vary. IDNK what does Chrome. Firefox with full color management assigns sRGB (colrospace & TRC) to untagged according to lagom gradient image (it looks like sRGB, with brigher near black greys)
Ok, I guess I am confused about exactly which changes affect the unmanaged apps/windows desktop compared to managed apps like Photoshop.
Because clearly even the windows desktop is affected somewhat when I turn off calibration (“reset video card gamma table”). The tone curve of everything is affected. Which makes me think “if this capability exists, why can’t the curve be adjusted to match the sRGB curve such that content encoded that way will at least have correct brightness values in all apps (but not colors)?”
…
They do not assume sRGB, they just dont care, direct RGB output to screen 1 to 1 translation.
Double-checking my understanding: IF it was the case that the monitor was a perfect sRGB monitor, this wouldn’t be a problem right? In other words, IF the sRGB factory calibration on a monitor was actually exactly correct, color management for sRGB encoded content would not be needed?
To clarify, when you say “encode your content for the common target”, I assume you refer to what you suggested before, which is essentially making an educated guess about the monitor characteristics of the audience and trying to compensate for that?
Ok, I guess I am confused about exactly which changes affect the unmanaged apps/windows desktop compared to managed apps like Photoshop.
Because clearly even the windows desktop is affected somewhat when I turn off calibration (“reset video card gamma table”). The tone curve of everything is affected. Which makes me think “if this capability exists, why can’t the curve be adjusted to match the sRGB curve such that content encoded that way will at least have correct brightness values in all apps (but not colors)?”
…
That is grey calibration (VCGT) applied system wide. It is done on GPU 1D LUTs.
If you apply sRGB TRC to VCGT your very dark greys will be brighter (and tehy will be OK), and you said do not want it.They do not assume sRGB, they just dont care, direct RGB output to screen 1 to 1 translation.
Double-checking my understanding: IF it was the case that the monitor was a perfect sRGB monitor, this wouldn’t be a problem right? In other words, IF the sRGB factory calibration on a monitor was actually exactly correct, color management for sRGB encoded content would not be needed?
Correct. And very dark grey “numbers” will be OK but brigther that you expect.
Same for video if that monitor have Rec709 primaries and typical 2.4 gamma. Video will look ok, dektop a little dark
To clarify, when you say “encode your content for the common target”, I assume you refer to what you suggested before, which is essentially making an educated guess about the monitor characteristics of the audience and trying to compensate for that?
No, it is not about “compensate”. Colorspace of your content will be that synth profile with sRGB primaries and 2.2g.
Ask your CAD/CAM modelers about the exporting/rendering options in their apps… maybe they are doing it right now and you just need to “assign” that synth profile (sRGB primaries , 2.2g) as you open the untagged images in PS.That is grey calibration (VCGT) applied system wide. It is done on GPU 1D LUTs.
If you apply sRGB TRC to VCGT your very dark greys will be brighter (and tehy will be OK), and you said do not want it.I think the reason I reacted badly to it at first was partly because of the terrible banding and other issues I experienced in the darks, but that seems to have been fixed with the new calibration settings (possibly the BPC?). I was probably also accustomed to the incorrect output, as you previously suggested.
At this point I am more concerned with things looking as correct as possible. It sounds like using a sRGB curve for the VCGT adjustment will make unmanaged sRGB content look more correct? How can I do this?
My understanding: VCGT does most of the grey correction, works on all apps. Color Profile fixes colors and works on managed apps.
Calibration tab, set tone curve to sRGB instead of 2.2… but your uncalibrated dells track aprox 2.2(dark greys)-2.1(bright greys), not sRGB. Once calibrated to sRGB these dells will show a little brighter near black greys.
Color managed software should handle whatever TRC calibration you use and make things look consistent. The idea behind the DisplayCAL defaults is letting the color management engine do more of the leg work instead of the GPU IIRC. Outside of color managed apps most content is in reality created for gamma 2.2 with sRGB primaries because that how displays are natively.
I think you will be ok my original dose is 7.5 i quit remron after two years and it was very rough i took 10mg v for 10 days then 8 mg for 3 weeks now i am back on my original dose 4 days is nothing
This is all going really well, except I’m experiencing some strange behaviors with embedding profiles. I thought it was a Photoshop issue at first, but I’m wondering if I have created the synthetic profile wrong. I used the sRGB preset but changed the TRC to 2.2 Gamma, as seen in the screenshot.
My understanding was that the Working Space in Photoshop only takes effect when a file is lacking an embedded profile: that it’s the default space. I’m comparing the standard sRGB IEC61966-2.1 profile with my synthetic sRGB 2.2 Gamma profile. In all cases I make sure to select “Profile:” under Assign Profile, instead of “Working RGB”, and made sure “Preserve Embedded Profiles” is set under Color Settings.
Scenario A: Working Space: sRGB, Embedded Profile: sRGB 2.2 Gamma – darks are lighter, indicating sRGB TRC
Scenario B: Working Space: sRGB, Embedded Profile: sRGB – image looks identical to Scenario A.
Scenario C: Working Space: sRGB 2.2 Gamma, Embedded Profile: sRGB – image looks good with proper blacks, as expected.
Scenario D: Working Space: sRGB, Embedded Profile: sRGB 2.0 Gamma – image shows up too bright. I created this profile just to see if I can make a difference with an embedded profile.
In cases A and B, the Working Space takes precedence, which is the opposite of what I would expect to happen. I would have expected B and C to be identical, instead of A and B. For some reason the Working Space is only overridden in Scenario D.
Scenario E: An image with sRGB 2.2 Gamma embedded shows up even darker than Scenario C in a color managed browser (Edge/Chrome). The blacks are even more crunched.
I definitely trust Photoshop more, but seeing how I’m getting inconsistent results even there leads me to believe there is some other piece of the puzzle I don’t understand yet. Does any of this make sense? What am I missing?
