Copy link to clipboard
Copied
Dear Adobe:
I have been working with the engineers at Eizo for the past year in trying to get the Eizo CG 243w monitor to work at 10-bits per color plane via mini displayport to displayport connection while using the 4870 graphics card on a Mac Pro.
Eizo re-wrote the firmware for the CG 243w to be compatible with the mini displayport standard released by Apple. As of this past summer, the CG 243w now interconnects with the 4870 graphics card to the monitor, while hosted on a Mac Pro under 10.6.
BUT in using Adobe's on test image, it is obvious that the display is still not working at 10-bits per color plane, as banding is showing.
Would you please clearly state whether Adobe Photoshop CS5 in the current version is capable of driving the 4870 graphics card and displaying 10-bits per color plane images using the MacPro and current OS? We need to know where the bottleneck is coming from---Adobe, Apple, AMD.
It is frustrating that Windows users have successfully been able to use Photoshop CS5 with a handful of different graphics cards and a large number of Eizo 10-bit monitors for a long time and it still appears that Mac users, known for being graphic intensive, cannot. We really need help getting to the bottom of this. Adobe Labs might be cranking out some fun new product, but functionality of a key issue for Photoshop would seem to be higher priority---and 10-bits per color plane seems like it would be one such issue.
cheers,
Pete
Copy link to clipboard
Copied
Just to add to the conversation. The NEC Wide Gamut LCD monitors holds a 10 bit LUT internally in the monitor to return a solid 8 bit video data to the video card. You will not see banding.
I’ve got a NEC PA271W hooked up as I believe you describe and still see banding using the ‘test file’ provided here: http://www.amd.com/us/products/workstation/graphics/software/Pages/adobe-photoshop.aspx (ramp.psd).
I’d sure like to know what the solution is, if any to use this file to prove (if it does indeed prove) I have a full 10-bit path.
Copy link to clipboard
Copied
A 10 bit LUT does not mean a 10 bit display path. A 10 bit LUT just improves (slightly) the 8 bit display path if you had any gamma corrections applied in the display.
And that is not relevant to the 10 bit display path being discussed in this topic -- which would require 10 bit/channel framebuffers in the video card and drivers (Apple's drivers being the missing component at this time).
Copy link to clipboard
Copied
What is the current situation?
Does Photoshop supports 10-bit output in OSX?
If still not, looks like there is some misleading articles(from 2010? CS4?) around...
http://nativedigital.co.uk/site/2010/11/10-bit-graphics-on-apple-mac/
Copy link to clipboard
Copied
Please read the existing posts in this topic.
Photoshop supports 10bit/channel framebuffers. But MacOS X does not suport 10bit/channel framebuffers, so Photoshop can't use it on MacOS.
Apple still has 10 bit/channel framebuffer support on their "Nice to have, eventually" list.
Copy link to clipboard
Copied
Banding? are you using Spectraview II software? I will try that file on my system to confirm.
Chris is correct that there is no way to create the 10-bit path at his time. The clean 8-bits from the monitor (NEC only with Spectraview software and puck) should give 255 levels per channel.
The Spectraview software does alllow other devices to connect but I can not say if that is a factor. We use the OEM X-rite puck with this setup.
Copy link to clipboard
Copied
Opened the file "ramp.psd" and see the individual "bars" of different densities but I do not believe I see banding.
The file appears to be bands of different neutral densities.
Copy link to clipboard
Copied
Well, those “bars" are what is referred to as banding here.
The bars show that only 256 levels are displayed while the 16-bit file actually has a multiple of that. You can verify this by moving in the minimum and maximum slider in the Photoshop curves so that you get a much steeper linear gradient (say, from in 32/out 0 to in 159/out 255). Then you will notice that the bars shrink in width (half as wide in the numerical example above) but the tonal difference between adjacent bars does not increase. In an 8-bit file the bars would stay the same width as before, and the tonal difference would become more apparent.
If you had true 10-bit output on your display, the bars would still be there, but only at a quarter of the width, and the tonal difference between them would be only a quarter of what you see now and thus hardly perceivable to the human eye.
Copy link to clipboard
Copied
Barry Rudick wrote:
Opened the file "ramp.psd" and see the individual "bars" of different densities but I do not believe I see banding.
That’s the banding! And I see it too on the SpectraView II using all the setup steps you describe. So no, while the NEC Wide Gamut LCD monitors holds a 10 bit LUT internally in the monitor You will see banding on a Mac until presumably Apple fixes the bottleneck here (some say drivers for specific video cards if I’m reading them correctly).
Copy link to clipboard
Copied
Andrew wrote:
"That’s the banding!"
I see. If I make a black to white gradient I see no banding. Is that different than the ramp.psd? I guess so but I can not explain the diff.
Copy link to clipboard
Copied
Correction:
Dragging the gradient tool past the edge of the window shows definite banding. I would guess that the monitor profile throws some bits out?
Copy link to clipboard
Copied
Interesting test.
Create 32 bit new file. Drag gradient. Change mode to 16 bit using "Exposure, Gamma" default, add 0.5 monochromatic, gaussian noise and no banding.
This is very similar to how Live Picture rendered the built-out tiffs. All files rendered had 0.5% noise added. Similar to the 16 bit to 8 bit mode change in Photoshop.
Copy link to clipboard
Copied
Barry, none of this solves the big issue and questions in the posts; a full high bit path for all images in Photoshop (and hopefully other products like Lightroom). What appears to be the issue is Apple needing to further support something in the path. We have high bit panels. That’s helpful but not the same as having an entire high bit path. We have high bit cards (presumably the drivers are the issues or something to do with Apple, that isn’t clear to me). We have applications that can access the data (not the same as a high bit file support although that’s necessary too). The ramp.psd file supplied is one that attempts to empirically prove when the entire path is high bit due to no visible banding.
Copy link to clipboard
Copied
Banding in 8-bit rendering is most obvious if the gradient is soft enough for the threshold from one tonal level to the next to stretch across several pixels because you then get those bands of pixels with identical values and an abrupt edge at the threshold. Of course, you can cover up banding with dithering or by adding noise. But that is not the point of the ramp.psd test picture cited earlier or having 10-bit video. 10-bit video can help you tell apart banding inherent in an image file from banding that is just introduced due to limiting output to 8 bits per channel (or less, as in a profiled monitor where tonal steps may be lost unless a higher bit-depth LUT is available and accessible for hardware calibration of the monitor).
Copy link to clipboard
Copied
The reason why I suspect so many want a full 10-bit path on wide gamut displays dates back to a 2004 post by Karl Lang, the fellow who designed PressView and Sony Artisan.
1) A wide gamut LCD display is not a good thing for most (95%) of high
end users. The data that leaves your graphic card and travels over the
DVI cable is 8 bit per component. You can't change this. The OS, ICC
CMMs, the graphic card, the DVI spec, and Photoshop will all have to be
upgraded before this will change and that's going to take a while. What
does this mean to you? It means that when you send RGB data to a wide
gamut display the colorimetric distance between any two colors is much
larger. As an example, lets say you have two adjacent color patches one
is 230,240,200 and the patch next to it is 230,241,200. On a standard
LCD or CRT those two colors may be around .8 Delta E apart. On an Adobe
RGB display those colors might be 2 Delta E apart on an ECI RGB display
this could be as high as 4 delta E.
It's very nice to be able to display all kinds of saturated colors you
may never use in your photographs, however if the smallest visible
adjustment you can make to a skin tone is 4 delta E you will become
very frustrated very quickly.
2) More bits in the display does not fix this problem. 10 bit LUTs, 14
Bit 3D LUTs, 10 bit column drivers, time-domain bits, none of these
technologies will solve problem 1. Until the path from photoshop to the
pixel is at least 10 bits the whole way, I advise sticking to a display
with something close to ColorMatch or sRGB.
3) Unless the display has "TRUE 10 bit or greater 1D LUTs that are
8-10-10" user front panel controls for color temp, blacklevel and gamma
are useless for calibration and can in fact make things worse. An
8-10-8 3D LUT will not hurt things and can help achieve a fixed
contrast ratio which is a good thing.
Only Mitsubishi/NEC displays with "GammaComp" have 8-10-8 3D LUTs at
this time. Some Samsung displays may have this I don't test many of
their panels as the performance in other areas has been lacking.
Only the Eizo 210, 220 and NEC2180WG have 8-10-10 paths. If you really
want to know... the path in the Eizo is "8-14bit3D-8-10bit1D-10" go
figure that one out 😉 The 2180WG has an actual 10 bit DVI interface
with a 10-10-10 path but nothing supports it so you can't use it yet -
but for $6500 your ready when it does 😉