Pages: [1]   Go Down

Author Topic: various topics/PS bug/UP2414Q vs PA241W/CMS in different programs and BPC/etc.  (Read 6871 times)

WombatHorror

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 299

This might be a bit hard to follow in that it's being dropped into this forum without prior context (it was part of some long threads on other forums) but there still may be some useful/interesting info here, in particular about the bug (and feel free to offer suggested corrections if you think anything below is incorrect, it's a complicated business):



sRGB emulation modes:

Actually, after some better testing, I think the Dell UP2414Q sRGB mode can be programmed better than I thought. Originally I thought it might not manage to measure out quite as linearly as on the NEC PA241W, but after getting some calibration files for my i1D3 to get it to measure this display well using some software that makes it easy to examine how well sRGB is emulated, it actually seems to do very well. I still need to run the test back on the PA241W again using this probe, but I think the results are going to be pretty close between the two and nothing in it at all really. The Dell actually nails the primary luminance and saturation curves and gamma ultra well too.
********************************************
Native gamut modes:

the Dell has a bit larger color gamut than the NEC (the new xx2 series of PA from NEC probably match the Dell though, to be fair, I'm comparing an old NEC to a new Dell here).

The linearity of 3 curve+matrix profiles after argyll profiling seems to measure out to be about the same, a little better for the NEC in some areas and a little worse in others.

Oddly, the 3 curve + matrix profiles without BPC that measure very well on both, visually look a bit better on the Dell. For some reason 3 curve profiles by Argyll on the NEC leave a few bits more off-color tints on grayscale and didn't quite work out for me, not sure why. The difference is less with BPC profiles, but still there. Using the NEC SV II generated 3 curves profile however instead of the Argyll ones and the tints are totally gone and perhaps even just a hint better than Argyll + Dell.
***************************************
Differences in calibration software and so on:

One nice thing is that the NEC lets you define any number of calibrated modes and then you can load them into the calibration slot. The Dell only allows you to calibrate straight into calibration slots and it only has two which is really not enough. They do load instantly though (takes a few seconds on the NEC). I think I found a cheat of sorts to go from 2 to 4 if you use DisplayPort though. I didn't verify yet, but a few things hint that using the miniDP vs the DP connector means using two different sets of CAL1 and CAL2. So if you get a DP/miniDP adapter you can probably use that two swap and thus get 4 internally calibrated modes to pick from (just barely enough to sort of get by with) instead of just two.

SV II from NEC runs much faster, apparently the PA screens are pre-calibrated to have the 14 bit 3D LUT so utterly linear that they don't even need to measure to change the tone response or just about anything else other than overall brightness and white balance while the Dell calibration software seems to need to run through a whole ton of patterns to gets things set to a very nice linear calibration so it takes MUCH longer to run a calibration on the Dell.

For whatever reason, the Dell software seems to try to slightly overshoot the x coordindate of the xyY system for the red primary when you make an sRGB emulation, it tends to want to make it 0.004-0.005 higher than you ask it to dial in. So you need to enter like 0.636 instead of 0.640 for other programs to end up measuring 0.640 afterwards. I'm not sure yet but it might be there is a slight saturation/luminance non-linearity with my copy of the Dell at 75% saturation for red, so maybe it is using a slightly high x 100% red to avg out the best value for both of those together? Not sure yet, I will measure more and measure the NEC too.

The NEC can be set to use factory measured primary locations. I'm starting to think those actually might be more accurate than even i1 Pro or corrected i1 Display Pro 3 measurements. So maybe for realt true to life primaries that lets you get a bit closer. I don't think the Dell allows that. Although if you chose to let the probes set the values then you get basically the same out of both (and the Dell makes it easier to do that, since you have little playing around to figure what values to enter in to fake it to give sRGB standards as measured by probe).
*************************************
Calibration, BPC, absolute, relative, PS vs other programs:

Earlier I had suggested that two monitors were hardware calibrating gamma 2.2 TRCs to absolute black, but I'm pretty sure I was wrong. They both seem to be calibrating to some modified form of relative black so as to not dump away like 12+ shades of tones or something. If you apply profiles with no BPC to either you will see a ton of black shades drop away as the image programs correct to true gamma 2.2 (which IPS screens can't come remotely close to hitting at the low end since their blacks are way too faded out).

Earlier I had mentioned that images don't look the same using most programs as they do in PS even when all are color-managed. The tone responses seem to be different with most types of monitor profiles. With most other programs tending to show a bit more crushed shadows, more contrast.

The difference seems to arise from the fact that most monitor profiles directly profile the monitor and don't write idealized curves out.

NEC SV II writes out idealized curves for everything it can (it can't if you chose to calibrate to native gamut). If you tell SV II to say calibrate to Gamma 2.2. It simple stores and EXACT mini gamma 2.2 entry into the monitor profile and the profiling is not based on any measured response from the monitor at all. The monitor isn't truly gamma 2.2 since the blacks don't go dark enough and the calibration is done relative to monitor not absolute black. So this basically cooks in a form of BPC (black point compensation) so even programs that don't do much, if any, BPC tend to show things looking closer to Adobe PS which does a ton of BPC. The difference is particularly apparent when viewing images stored as gamma 2.2.

Most other software actually profiles the monitor's tone response and stores whatever it measures into the profile. So the profiles generally tell programs to much darken up the deepest shadows, especially for gamma 2.2 files. If the programs apply BPC they don't darken it up as much since they start the tone curve from monitor black instead of ideal pitch black. Most programs seem to apply relatively little BPC. Adobe PS, however, always applies complete BPC though so you barely get any crushed blacks at the bottom end at all and the files tend to show brighter shadows and a touch less contrast than they do in many other programs.

Not applying a ton of BPC gives a truer sense of just how dark you trying to set your shadows and you won't be shocked so much if you move to OLED one day. OTOH, not being able to see the bottom 8-15 shades or whatnot isn't too pleasant and doesn't let you get a great look at your images. Plus the eye tends to work in a partly relative fashion. And going to extreme DR of OLED you might need to tweak things a bit anyway. So in practicaly reality, in some ways, the forced extreme complete BPC that Adobe uses actually might be the best way to go. For sure for editing, where not being able to see what you are editing wouldn't be so hot at all.

By SV II writing out idealized curves, all programs think the monitor needs no correction so even if they don't do BPC, this effectively forces them too so results in other programs become a bit more similar to PS than with true monitor tone responses being written out. The NEC is super linear so even without measuring it produces darn close to ideal black point relative gamma 2.2 or whatnot so it all works out well.

If you calibrate NEC to native gamut then it has to measure and write a full profile out and then you get bigger differences between PS and many other programs.

If you have a monitor that happens to be quite linear, like say UP2414Q from Dell, you could decide to toss out the Dell profile and create a cooked in idealized BPC profile with it and get the same behavior. Some profiling software can be set to truly cook in a full level of BPC too. Although for some reason I have trouble making curves profiles from argyll even with BPC set to cook in to make other programs act like they are using full-on BPC. I thought long agao using COlorEyes software that asking it to cook in BPC cooked it in a lot more for some reason.

Cooking BPC into argyll profiles makes them measure out somewhat less linearly (although oddly, to the eye, sometimes the gray tones look more neutral, especially with the NEC, not quite sure the mismatch there).

Anyway, whatever. The internal calibrations of both the NEC and Dell are actually pretty similar. Any differences I noted in how software showed images on them was SOLELY due to the type of monitor profiling I had been using (each brand defaulted to a different type).

It would be possible write image viewing software that behaved more like photoshop. I'm having trouble finding such software though. It's odd Adobe hasn't released their own image viewer using the PS engine. I may try to write one (don't expect it next week :D:D:D).

Firefox/Chrome/Irfanview tend to behave pretty similarly when it comes to BPC and tone response mapping. FasttPicViewer under WCS mode tends to be a bit different. FPV under it's native CMS tends to be radically different and makes most images shadows look much darker and gives more contrast and pop to most images than any other software (even in WCS mode it does a little often). FPV under WCS overall looks a bit more like FF/C/I although not quite the same, sometimes less black crush than anything other than PS and yet still often tends toward more contrast and it seems to have a weird bug under some (not most) monitor profiles where it uses some tone much brighter than 0,0,0 for 0,0,0 under WCS though.
********************************
Photoshop bug:

Photoshop actually seems to have some nasty bugs if you set GPU drawing mode to Normal or Advanced (default!). Setting it down to Basic makes the bug go away. Sometimes it will shift tone response slightly or add weird tints to certain ranges of an image. With some monitor profiles it's hard to notice, with some quite easy. It seems to be more noticeable the wider the gamut the image is stored in. So for an image stored as sRGB you might barely notice the main bug at all, but for an AdobeRGB stored image you might notice it a trace to a decent bit and for an image stored as ProphotoRGB you might notice it a decent bit to a lot. Note taht it doesn't matter if the image has few saturated colors, even with a pure gray tone you might notice these issues. All that matters is what gamut the image is stored in.

I would suggest turning it down to Basic. You never know when the bug might be slightly altering how it renders images to the screen and never know that you might be correcting in tone and tint for this bug and not for things in your actual image!

Now you might not notice it much, for some monitor profile types and corrections stored in profiles it will barely show up no matter what, but for others quite a lot (at least given non-sRGB images).

Supposedly there are also some color tint bugs in Normal/Advanced modes were doing certain types of profiling previewing and such.

The bug seems to be in both PS CS6 as well as the most recent CC version and it seems to affect both Windows and Mac versions as well as computers running Nvidia or AMD/ATI or Intel GPUs(which probably means ANY type of GPU at all, i.e. a pure Adobe issue).
Logged

D Fosse

  • Guest

I didn't have time to read and digest all this, but the last part about a Photoshop OpenGL bug is absolutely correct. It affects the Normal and Advanced settings, where the color management logic is shifted from the CPU to the GPU. The Basic setting operates in the traditional way and is bug-free.

Cyan shadow banding in ProPhoto files was first reported in the Adobe Photoshop forum a couple of years back. PS engineers said they'd look into it, but it's still there.

Then only a couple of weeks ago I noticed some more weirdness - a black crush at levels 3 or 4 in an sRGB file; whereas I could see all the way down to 1 with OpenGL disabled (the Basic setting). I reported it here: http://forums.adobe.com/message/6241730

It seems the OpenGL engine simply lacks the required precision. Aside from the black crush and the cyan ProPhoto banding, there is also general banding in all color spaces. I simply stopped using the Normal/Advanced setting and have kept both my machines at Basic ever since.
Logged

Czornyj

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1948
    • zarzadzaniebarwa.pl

Can you tell how to replicate the PS issue in GPU Advanced mode? I've never noticed it before ???

BTW - You were right WombatHorror, this little 4k bastard is really awesome! I just hope Apple will release 10.9.4 update really soon ;)
Logged
Marcin Kałuża | [URL=http://zarzadzaniebarwa

D Fosse

  • Guest

The easiest way is simply to grab the title bar (of a floating image window) and drag/hold the image. That suspends the whole OpenGL engine. When you drop it, it snaps back on.

It's most clearly demonstrated on a ProPhoto file with a simple 0-128 radial gradient.

You'll see subtle cyan banding, more irregular steps, and a slight but noticeable black crush. See screenshots I posted in the adobe forum thread I linked to.

Yes, it's easily missed until you look for it. But the cyan shadow banding used to drive me crazy before I was told what it was. I was convinced my profile was bad and just couldn't figure it out.
Logged

fdisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1852
    • Frank Disilvestro

Thanks for pointing out this issue. It took me a while but finally noticed it with the gradient as described by D Fosse.

WombatHorror

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 299

The easiest way is simply to grab the title bar (of a floating image window) and drag/hold the image. That suspends the whole OpenGL engine. When you drop it, it snaps back on.

It's most clearly demonstrated on a ProPhoto file with a simple 0-128 radial gradient.

You'll see subtle cyan banding, more irregular steps, and a slight but noticeable black crush. See screenshots I posted in the adobe forum thread I linked to.

Yes, it's easily missed until you look for it. But the cyan shadow banding used to drive me crazy before I was told what it was. I was convinced my profile was bad and just couldn't figure it out.

Yeah a simple gray test band pattern (especially if has dark to mid-tone steps) stored as ProphotoRGB is a very good method.

The particular monitor profile matters a bit too though. It seems to be more often pronounced if you use a profile using Curves and not a simple Gamma idealized table in the profile.

And to make it really apparent (only if running Windows OS though), as you say, just unhook the window the image is in so you can move it and then drag it around, while dragging it looks normal, as soon as you let go it pops back to the wrong tints and tone responses. (Interestingly though the drag test seems to only work on Windows. On my Mac Mini I found that it maintained bad colors even while dragging.)

It's honestly quite a major bug (even though it's a sneaky sort that might take many a long time to realize had even been occurring all along, I only discovered it myself just the other weeks, was going crazy trying to figure out what was going wrong, I got the new Dell and was testing all sorts of stuff and it's profiler uses curves so this is what got me to figure it out, my NEC PA241W just happened to use a profile variety that made it much harder to notice the weird bug) considering that color accuracy is the name of the game for this product. It's very puzzling that not only have they not fixed it for such a long time (not even with CC and all their talk of the magical cloud and non-stop bug fixes.... of course we all knew the magical CC was really just a fancy and entirely phony name for a rental model of software distribution), but that they continue to ship it with GPU->Drawing set to Advanced as default.
« Last Edit: April 11, 2014, 11:22:48 pm by WombatHorror »
Logged

WombatHorror

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 299

BTW - You were right WombatHorror, this little 4k bastard is really awesome![/img]

Yup, UHD is as bad-ass as a honey badger!
Maybe even as much as a honey wombat.
Logged

D Fosse

  • Guest

drag/hold the image

Ah, sorry, didn't  realize this particular behavior was Windows only. So on Mac you'll have to actually do the change in preferences and relaunch.

The bug does appear slightly different on my two machines (both with the same AMD video driver version) - but one with NEC Spectraview II and the other with Eizo EasyPix. So type of profile apparently matters. They're equally bad, but in different ways.

The original Adobe forum discussion had engineers Chris Cox, and I think also Jeff Tranberry involved. So they're well aware of it, but they may not be able to do anything about it on Adobe's side of the APIs.
Logged

WombatHorror

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 299

Ah, sorry, didn't  realize this particular behavior was Windows only. So on Mac you'll have to actually do the change in preferences and relaunch.

Sometimes you can sort of tell by loading the same image in sRGB format (obviously make sure to use one that doesn't have more than sRGB colors so it doesn't end up being just an sRGB clipping thing, the good old grayscale stuff is good) and comparing between the ProphotRGB and sRGB version. The bug probably affects the sRGB too, but it never seems to effect it anywhere wildly near as much as the wide gamut versions.

Quote
The bug does appear slightly different on my two machines (both with the same AMD video driver version) - but one with NEC Spectraview II and the other with Eizo EasyPix. So type of profile apparently matters. They're equally bad, but in different ways.

The original Adobe forum discussion had engineers Chris Cox, and I think also Jeff Tranberry involved. So they're well aware of it, but they may not be able to do anything about it on Adobe's side of the APIs.

Interesting that they were involved and it's still not fixed.
What I don't get is that if it really is true that it can't be fixed (and personally the alterations the bug makes at times seems well, well beyond any talk of GPU precision to me, so I'm dubious) then why do they not only still continue to offer it, but ship the product with it set by default to this buggy and broken mode and put out no general warnings to users???
Something is not adding up.
Logged

fdisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1852
    • Frank Disilvestro

Hi,

I have tested for this bug (Photoshop/OpenGL - cyan shadow banding) and it is still present in the latest version of PS CC and PS CC 2014. The only difference though, is that in Windows the appearance of the issue does not change when you drag the picture as it did before. Result: keep using basic mode (OpenGL disabled)

Regards,

samueljohnchia

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 498

I can replicate this problem on my laptop but my desktop is fine. Dell U2711 display, AMD FirePro 4900, 10 bit display enabled in driver and PS. Windows 7 Pro 64 bit. No idea why?
Logged

Pictus

  • Full Member
  • ***
  • Offline Offline
  • Posts: 216
    • Retouching

I can replicate this problem on my laptop but my desktop is fine. Dell U2711 display, AMD FirePro 4900, 10 bit display enabled in driver and PS. Windows 7 Pro 64 bit. No idea why?

Convert this gradient to ProPhoto RGB, here the preview does not show any change, but the final result... :(
Logged
Pages: [1]   Go Up