- This topic has 34 replies, 4 voices, and was last updated 1 year, 3 months ago by
.
-
Posts
-
Hello Vincent,
I did some more research and tinkering, and unfortunately, there is no solution to this issue.
On macOS, the black levels in Photoshop being too bright is unacceptable (except in situations without BPM).Therefore, I’ve decided to switch back to Windows.
From what I’ve gathered from your previous posts, I am prioritizing a system with an AMD iGPU (laptop) for my Windows setup.
Then, I plan to profile the display with the classic SpyderX software using the gamma 2.2 setting, and start using Photoshop and color-managed programs.Do you agree with what I’ve written here?
SpyderX Pro on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.By the way..
I hadn’t included Lightroom in the tests at all.
There are also differences between Lightroom and Photoshop.
In fact, even between Library and Develop in Lightroom.When BPC is turned off, the differences decrease but still exist.
On Windows side, there are no issues at all; everything works well together and they are same.
Hello Vincent,
I did some more research and tinkering, and unfortunately, there is no solution to this issue.
On macOS, the black levels in Photoshop being too bright is unacceptable (except in situations without BPM).I did not understand what you did in macOS. Did you mean that PS behaved DIFFERENTLY with and without ideal black in display profile? it should not if using ACE engine. MacOS desktop will behave differently due to macOS limitations.
Therefore, I’ve decided to switch back to Windows.
From what I’ve gathered from your previous posts, I am prioritizing a system with an AMD iGPU (laptop) for my Windows setup.
Use DWMLUT your your current gear. Source colorspace an idealized matrix profile with ypur display primaries, destination an accurate 3dmesh profile (but if display is well behaved your current matrix single curve profile works too). Embed VCGT in LUT3D. set as dsiplay profile in os the idealized one, load LUT3D.
DWMLUT will handle the calibration with ditheirng, running on GPU shaders. Visually no difference with HW cal.maybe your handicap is in “unrealistic bright low light readings” due to SpyderX… but ypu’ll need another device to make comparisons.
Anyway, if you are suffereing banding caused by VCGT calibration on your windows machine, try DWMLUT first before buying another GPU, or try to use novideosrgb dithering (but i’ve not used it).
In fact, even between Library and Develop in Lightroom.
The accurate view is develop, with dithering and such.
Hi Vincent,
I did not understand what you did in macOS. Did you mean that PS behaved DIFFERENTLY with and without ideal black in display profile? it should not if using ACE engine. MacOS desktop will behave differently due to macOS limitations.
Photoshop in ACE engine mode, always.
- DisplayCAL profile with BPC ON = Blacks are washed out.
- DisplayCAL profile with BPC OFF = Blacks are correct.
So, there are differences when ACE engine is on.
What I see in Lightroom:
Applied profile = BPC ON
- Library module: Blacks are washed out (like Photoshop with BPC ON)
- Develop module: Blacks are correct.
So, in Lightroom, the “Develop” module behaves exactly the same as macOS (Apple CMM) when using a profile with BPC ON.
From this stand point, it is better to set photoshop color engine mode to Apple CMM. Because, when I edit in Lightroom, result are same when I transfer to Photoshop, with good blacks. Maybe this argue is wrong, but I looked at so many laptop today at store, with good panels / monitors and black ware always a little darker then my edits. So photoshop blacks with ACE is never, never acceptable.
You’re on an Apple M1 with a Retina display on Mac OS 14.1.2, so the original color profile assigned by default was compatible with LR. While it’s conceivable the file got corrupted, it’s very unlikely.
LR is compatible with the graphics drivers in Mac OS 14. It’s unlikely you’re tripping over a bug in the graphics driver itself, since otherwise there would have been a ton more reports about the issue.
However, you’re on LR 12.0.1, which is over a year old. Is there a reason you’re not running on the latest version, 13.1? It’s very possible that there’s some issue in previous versions of LR that were later corrected.
I don’t need to do anything fancy on the Windows side. With DisplayCAL and SpyderX software, I get the same results. Photoshop, Lightroom, and Photo Viewer all look exactly the same, with OK blacks.
Hi Vincent,
I did not understand what you did in macOS. Did you mean that PS behaved DIFFERENTLY with and without ideal black in display profile? it should not if using ACE engine. MacOS desktop will behave differently due to macOS limitations.
Photoshop in ACE engine mode, always.
- DisplayCAL profile with BPC ON = Blacks are washed out.
- DisplayCAL profile with BPC OFF = Blacks are correct.
So, there are differences when ACE engine is on.
Then you have an issue due to TRC, likely caused by SpyderX. Or you are softproofing.
On a well behaved 1000:1 IPS with an accurate TRC measured with i1d3, then stored in profile as ideal (RGB 0 -> L*0) or as real black, while not softproofing should have little difference.
“Fake contrast” scenario will map sRGB TRC in an image to display TRC. RGB 0 in image RGB 0 in display. For RGB 1, 2.. till actual black in display it depends on stored TRC.(*)
“real black” with ACE and black point compensation in ACE will map RGB 0 in image to RGB 0 in display, then up to a few greys above when TRC in display (actual, the accurate one) is able to show greys with ist actual brightness, it will make some perceptual match to avoid crushing OoG. Hence lifting near blacks.If you see noticeable changes WHILE NOT SOFTPROOFING, seems to be caused by near black TRC values in idelaized TRC, hence likely to be caused by Spyder
What I see in Lightroom:
Applied profile = BPC ON
- Library module: Blacks are washed out (like Photoshop with BPC ON)
- Develop module: Blacks are correct.
So, in Lightroom, the “Develop” module behaves exactly the same as macOS (Apple CMM) when using a profile with BPC ON.
From this stand point, it is better to set photoshop color engine mode to Apple CMM. Because, when I edit in Lightroom, result are same when I transfer to Photoshop, with good blacks. Maybe this argue is wrong, but I looked at so many laptop today at store, with good panels / monitors and black ware always a little darker then my edits. So photoshop blacks with ACE is never, never acceptable.
You’re on an Apple M1 with a Retina display on Mac OS 14.1.2, so the original color profile assigned by default was compatible with LR. While it’s conceivable the file got corrupted, it’s very unlikely.
LR is compatible with the graphics drivers in Mac OS 14. It’s unlikely you’re tripping over a bug in the graphics driver itself, since otherwise there would have been a ton more reports about the issue.
However, you’re on LR 12.0.1, which is over a year old. Is there a reason you’re not running on the latest version, 13.1? It’s very possible that there’s some issue in previous versions of LR that were later corrected.
I don’t need to do anything fancy on the Windows side. With DisplayCAL and SpyderX software, I get the same results. Photoshop, Lightroom, and Photo Viewer all look exactly the same, with OK blacks.
then it seems to be related to acelerated GPU calculations. Try to test again with GPU set to basic…. but my bet is that your issues are caused by innacurate TRC readings in spyder near black.
Check TRC on both porfiles.…although Windows version with same TRC and same profile should behave like taht, which points to GPU CM oversimplifiaction in calculations fro Apple new GPUs, so try “basic” GPU accel
Vincent,
Please ignore the last “blockquote.” That was from another forum where I read about someone else’s experience. I always use the latest version of the programs. I accidentally pasted it into my post.
- What do you recommend with the result above?
- Should I just use Photoshop with the Apple CMM engine? Because Lightroom Develop, macOS desktop, and Photoshop all act the same (good blacks)?
- Should I move to a Windows operating system, profile it, and be happy?
- Should I just set my monitor to the factory-calibrated sRGB ‘OSD’, set my macOS to the sRGB color space for that external monitor, and use it? (Almost no noticeable color shifting, but gamma shift is significant compared to Spyder’s profile.)
Please advise.
I’ve attached the following files, (I need to learn how to reed the .icc files):
- MacOS_Spyder: Spyder software on macOS. = Wrong gamma in Photoshop.
- MacOS_With_BPC: DisplayCAL software with BPC checkbox on. = Wrong gamma in Photoshop.
- MacOS_Without_BPC: DisplayCAL software with BPC checkbox off. = Good gamma in Photoshop, wrong desktop colors.
- Windows_Spyder: Spyder software on Windows. = Good gamma everywhere.
PS: If you ask me, I would say that the standard IDED data or sRGB profile provides the best gamma, because I can barely see any difference between RGB 1 and RGB 2, etc. With BPC ON, RGB 1 acts like RGB 5 on ACE photoshop.
-test if related to GPU accel with M1
-test (if possible) witrh a more accurate device that TRC for RGB > 0 is accurate near blacksif not possible choose number 1 or 2 from your options.
Hello Vincent,
Unfortunately, the GPU test did not change the results.
For now, I will continue with the first (1) option and keep an eye on laptops for the second (2) option. The newly released CPUs have started to catch my interest. I’ll wait for their prices to drop since I’m not in a hurry.
Unfortunately, I couldn’t find a second-hand i1Display Pro. What are your thoughts on devices like the Calibrite Display HL, at least to make black measurements more stable then Spyder’s?
I think they’re on sale right now due to Black Friday:
Calibrite Display Plus HL = €200
Calibrite Display Pro HL = €180In other forums, I’ve seen that this problem has occurred for other people as well. Some used SpyderX and then purchased an X-Rite product to solve the issue, but they reported no improvement in Photoshop ACE. I’m adding those links below for anyone who wants to read them later.
https://www.reddit.com/r/photoshop/comments/1ccav9l/crushed_gray_blacks_in_photoshop_but_not_in/ https://community.adobe.com/t5/photoshop-ecosystem-discussions/clipped-blacks-and-difference-in-color-in-photoshop-compared-to-camera-raw-and-lightroom/m-p/14581330 https://www.reddit.com/r/postprocessing/comments/ujgjni/contrastlevels_shift_from_adobe_camera_raw_to/ https://community.adobe.com/t5/photoshop-ecosystem-discussions/photoshop-not-properly-displaying-blacks-after-monitor-calibration/m-p/14776652
AND i found this one now:
https://www.marktplaats.nl/v/audio-tv-en-foto/fotografie-professionele-apparatuur/m2168990293-i1-display-pro-calibrate-van-xriteI also found this, but if you confirm, it will be my new hardware choice (Calibrite Display Pro HL)
Testing Calibration Differences: Windows vs. macOS with i1 Display Pro
During this test, I calibrated and profiled displays using the i1 Display Pro hardware with the correct correction settings on both Windows and macOS.Setup:
Windows:
Connected to the display via DisplayPort.macOS:
Connected using USB-C DisplayPort Alt Mode.
This setup allowed me to quickly switch between the two systems to compare behavior in the low tones and blacks after calibration.Observations After Calibration and Profiling to Gamma 2.2
Windows:
After profiling, 1,1,1 blacks are slightly lifted.Application-Specific Behavior:
Lightroom Library:
Blacks (1,1,1) are good.Lightroom Develop:
Blacks appear slightly brighter but are not noticeably off.Photoshop ACE:
Blacks (1,1,1) are lifted more than in Lightroom Develop, but still in fine in tolerances.ICC-aware photo viewer:
Similar to Lightroom Develop.Conclusion:
The differences are marginal and usable. Only Photoshop ACE lifts the blacks slightly more, but it’s not significant.macOS:
After calibration, 1,1,1 blacks are also slightly lifted, similar to Windows.Lightroom Library:
Blacks are too lifted, making them unusable, with poor contrast in dark areas.Lightroom Develop:
Blacks (1,1,1) are good and comparable to Windows.Photoshop ACE:
Blacks are too lifted, making it unusable, similar to Lightroom Library.Photoshop (Apple CMM):
Blacks (1,1,1) are good and match Windows and Lightroom Develop.ICC-aware photo viewer:
Similar behavior to Lightroom Develop or Photoshop with Apple CMM.Conclusion:
There are significant differences. For macOS, Lightroom Develop, Photoshop (Apple CMM), and ICC-aware photo viewers are reliable. Lightroom Library and Photoshop ACE produce lifted blacks, making them unsuitable.Comparison: Windows vs. macOS
Switching between the two operating systems, I observed the following:Windows: Provides consistent results across most applications, making it a reliable reference.
macOS: Only Lightroom Develop, Photoshop (with Apple CMM), and ICC-aware photo viewers closely matched Windows. These are the applications I would trust when working on macOS.Question: Why Are Blacks Lifted After Calibration?
After calibration, both Windows and macOS exhibit slightly lifted low tones and blacks, even though the screen is capable of displaying 1,1,1 blacks.I’ve done a lot of research, but there’s one thing I still don’t understand: after calibration, the low tones and blacks appear lifted. Why is this happening? The screen is capable of displaying proper 1,1,1 blacks.
sRGB has higher black levels compared to gamma 2.2, which is darker in the low tones, as shown in the graphics I’ve reviewed. When a reverse sRGB curve is applied to a gamma 2.2 target, shouldn’t it lift the dark areas instead?
Any insights or suggestions would be greatly appreciated!
TRC says 2.2, but actual display behavior “bends” to lower values near black because of finite contrast
LR & PS will believe whatever TRC says. So if profile says 2.2 and they render an sRGB gradient black to white it means “lift me near black” just because 2.2 vs sRGB.As I explained above (my mistake) I though “single curve” will store actual L* for black untill it was very close to actual black where ot stores RGB 0 -> 0 L*.
So as an example for RGB grey 14 it will store “TRC is gamma 2.0” (instead of 2.20)
3xCurves + matrix + BPC ON, AFAIK stores this way, but you cannot use in some apps because even the slightly TRC mismatch between channels will cause some color tint in greys if app has no dithering.The issue here may be that you are opening an untagged image (an image without an embeded profile) so you are forcing the behavior of whatever default working space you have and this may be different for every app. On a tagged TIFF it’s likey that all apps will behave the same way.
You may try to force an “assign” profile in PS and save lagom PNG as a copy WITH embebed profile, but there was a thread long ago about tricky non tagged images.
It may be easier to test if you had an actual RAW image in LR with gradients or shadows, export it to sRGB TIFF and open that tiff again on every app.Maybe you should ask in Argyll Maillist about this, so colprof app (https://www.argyllcms.com/doc/colprof.html) so as an addition to -aS (cretae a profile single cuve), there is an additional option to preserve fake contrast (RGB 0 -> L*0) but store a more realistic TRC near black, like RGB 14 g2.0, RGB 8 g1.8.
But I think that your PS issue comes from untagged Lagom LCD Test image being forced to some RGB colorspace TRC. An actual photo exported from LR with some profile and openend again as TIFF should have the same behavior on every app.Hi Vincent,
Thanks for your support.
The issue here may be that you are opening an untagged image (an image without an embeded profile) so you are forcing the behavior of whatever default working space you have and this may be different for every app. On a tagged TIFF it’s likey that all apps will behave the same way.
Lagom had a profile in it, sRGB. I also testen with my own .RAW photos, exported to .TIFF file with sRGB color space. Same results. Actually, I don’t care any the differences between apps. Just want to know which one is accurate and use it.
TRC says 2.2, but actual display behavior “bends” to lower values near black because of finite contrast
LR & PS will believe whatever TRC says. So if profile says 2.2 and they render an sRGB gradient black to white it means “lift me near black” just because 2.2 vs sRGB.I added two measurement reports of the tone curve: ‘measured gamma’ and ‘sRGB gamma.’
I’m curious to see if you’ll notice anything significant.
I’m considering using the Tone Curve: Native-gamma-sRGB-curve.htmlSince my display performs better with the sRGB gamma curve (with bends in the low-end tones), I think it’s better to calibrate it for the sRGB tone curve. Am I correct?
Benefits of profiling the tone curve to sRGB:
– Achieving deeper blacks, resulting in better contrast.
– Compared to other uncalibrated screens (such as phones, tablets, Apple products, Windows laptops, and other monitors), the results are more consistent (grey low end contrast).
– Most people view my photos on monitors and cell phones, they have a deeper blacks (not lifted, mostly! On high end models).
– When editing landscape photos, I often feel that I can’t achieve enough contrast, so I usually end up darkening the blacks more (gamma 2.2). However, this results in photos appearing much darker than intended on uncalibrated screens that use the sRGB curve.
– For years, I’ve always edited with this issue in mind (gamma 2.2). Now, I’ll be able to approach dark tones more freely when editing. (All other photos that I edited is darker on all other displays unfortunately because of this)
– Bonus: All programs acts same.Wouldn’t it be better to stick with the monitor’s native gamut sRGB?
If you recommend using the sRGB curve, I’ll go back and re-edit my last 1,500 vacation photos because they’re too dark (as they appear on all other screens).Hi Vincent,
Thanks for your support.
The issue here may be that you are opening an untagged image (an image without an embeded profile) so you are forcing the behavior of whatever default working space you have and this may be different for every app. On a tagged TIFF it’s likey that all apps will behave the same way.
Lagom had a profile in it, sRGB. I also testen with my own .RAW photos, exported to .TIFF file with sRGB color space. Same results. Actually, I don’t care any the differences between apps. Just want to know which one is accurate and use it.
It has no profile. It has been added by you or by deffaukt settings in PS.
I just downloaded it, it has no profile. All lagom images test are meant for testing on a non color managed browser, altough with proper manipulation you can use its gardient or other test color managed.
Actually my 2024 PS says that blacktest PNG admits no embebed profiles. It is not that it’s missing.TRC says 2.2, but actual display behavior “bends” to lower values near black because of finite contrast
LR & PS will believe whatever TRC says. So if profile says 2.2 and they render an sRGB gradient black to white it means “lift me near black” just because 2.2 vs sRGB.I added two measurement reports of the tone curve: ‘measured gamma’ and ‘sRGB gamma.’
I’m curious to see if you’ll notice anything significant.
I’m considering using the Tone Curve: Native-gamma-sRGB-curve.htmlSince my display performs better with the sRGB gamma curve (with bends in the low-end tones), I think it’s better to calibrate it for the sRGB tone curve. Am I correct?
Benefits of profiling the tone curve to sRGB:
– Achieving deeper blacks, resulting in better contrast.
– Compared to other uncalibrated screens (such as phones, tablets, Apple products, Windows laptops, and other monitors), the results are more consistent (grey low end contrast).
– Most people view my photos on monitors and cell phones, they have a deeper blacks (not lifted, mostly! On high end models).
– When editing landscape photos, I often feel that I can’t achieve enough contrast, so I usually end up darkening the blacks more (gamma 2.2). However, this results in photos appearing much darker than intended on uncalibrated screens that use the sRGB curve.
– For years, I’ve always edited with this issue in mind (gamma 2.2). Now, I’ll be able to approach dark tones more freely when editing. (All other photos that I edited is darker on all other displays unfortunately because of this)
– Bonus: All programs acts same.Wouldn’t it be better to stick with the monitor’s native gamut sRGB?
If you recommend using the sRGB curve, I’ll go back and re-edit my last 1,500 vacation photos because they’re too dark (as they appear on all other screens).This has nothing to do with monitor calibration but with tracking actual TRC after calibration in profile ICC. Since you are OS limited to certain types of profile and idealizations, *IF* targeting sRGB TRC calibration makes that after calibration profile TRC matches “better” to monitor behavior, its better, but as I’ve explained in the past all gamma calibration will be undone by color management engine.
Actually it does not depend on profile TRC vs actual TRC, the source of error seems related to blacktest.png lacking profile and your PS setup messing with assign default profile and assuming some things.
For example if I open it in PS, my PS setup & config ask me what is this?
If I say : it’s sRGB with a display profile “g2.2 infnite contrast” it believes it. So sRGB’s RGB 1 needs to be mapped to L ~0.29 which it’s about RGB ~6 in display colrospace described as g2.2 infinite contrast. It is a legit shadow lift.
If I said: it’s AdobeRGB there will be almost 1:1 direct transaltion to display colorspace since PS believes it to be true 2.2.You issues seems related to improper profile tagging on images.
I added my own colorspace in the Lagom: sRGB.
Also i created my own Lagom chart, sRGB 16bits.
But that chart is not so important for me. I’m not testing it with Lagom.png,I test with my raw photos. When exporting raw to jpg or tiff i select sRGB as colorspace.
Also on Windows rgb1 lifted up to rgb -/+ rgb 3. So the rgb 1 and 2 will be newer used on my monitor if profiled to gamma 2.2.
