BenQ PD2720U Not reaching advertised colour gamut coverage?

Home Forums Help and Support BenQ PD2720U Not reaching advertised colour gamut coverage?

Viewing 6 posts - 61 through 66 (of 66 total)
  • Author
  • #28844

    Philipp Mochine
    • Offline


    Check which color format is output through HDMI, try to match it in input format in display.

    Can you elaborate on how to do this?  I’m on a Mac and I’m not really sure what you mean. How can I check which color format is output through HDMI? Over the monitor itself or the OS? And where? 😅

    Thank you!


    PD2700U is sRGB.  ONLY sRGB. A very good one for its price I must add. All seems fine in your calibrated display (through DisplayPort)

    PD2720U is the low cost AdobeRGB version (PG > SW > PD > BL …). It’s a different model with different price.

    Omg! Didn’t notice the 2720U! I thought this would be also my monitor! Thank you for telling me the difference.

    I just have switched back to HDMI, but I still get bad ΔE 🙁


    • Offline

    As Vincent said, PD2700U is only advertised as covering 100% SRGB/Rec. 709. So 83% P3 is actually pretty good for a SRGB display. My SRGB displays only reach p3 percents in the mid 70’s.

    Display port at 30hz isn’t the worst. If your only editing/viewing 24-30fps footage that’s all you really need.

    I wonder if a new DP 2.0 cable would make a difference?

    You said your HDMI isn’t a regular HDMI its a HDMI to usb c. Maybe there’s something weird happening in that conversion process. Guessing macs don’t have a regular HDMI port anymore you could test?

    Or might just be SOL and have to settle for lower refresh rate or poor calibration until apple fixes what they broke. 😛


    • Offline

    • Offline

    Check the monitor’s config for RGB vs YCbCr (aka YPbPr in analog HDTV, or sometimes YCC)

    It comes down to whether the Mac sees the display as “HDTV” or a graphics display. In TV mode (YCbCr), there are several concerns due to compatibility with analog TV:

    A) Limited signal range — the signal is conveyed as luminance and color difference not R G B. The data values for each of Y (luminance, diff green) Cb (diff blue) Cr (diff reg) are computed as weighted sums of the RGB. Further, it’s very common for the signaling levels to be restricted to from 0.255 (assuming 8-bit) to leave headroom and toe-room for analog TV signaling effects.

    B) Color pixel subsampling — Motion video signals typically send color detail  data a fraction of the luminance detail. This is where the designation 4:x:x come from. For every square block of 4 luminance pixels (grey), the color is sent in a fractional amount, so 4:4:4 is color at same resolution as luminance,  4:2:2 is 2 pixels of BR-diff spread across 4. The most common by far is 4:2:0 which further reduces color info. JPEG Image compression starts with this idea as a baseline. You can see that pixel level graphics such as text rendering and line art might not render will when color data are cast out, but in motion video (classic TV and film) you also never miss it, and this in baked into the earliest deployments of TV dating to origins in 1950s. Modern systems and SW may translates back and forth so it’s always very media / format / program specific which signaling applies — there’s no One Right Way. Safe to say PC graphics are traditionally RGB, but the PC display was always a re-purposed TV set, and today’s, devices fully marry PC and TV technology.

    And for completeness..

    C) In HDTV there is the trait of “overscan” which dated back to imprecision of pixel addressing on face of analog CRT: the TV set always overshot the raster past the edge of the tube face a little to fill it. So like the safe zone a cinematographer users when framing shots to ensure mics and other set artifacts are out of the finished frame, overscan dealt with ensuring that picture content fit on TV. In print pre-press it’s called “bleed” when an image is marginally oversized to be sure than when paper is cut into the finished product, ink goes edge-to-edge.

    When connecting a display with HDMI, all these concerns come into play because of what the format owes to analog TV.

    A PC / Mac / game console tries to hide these details because they are inscrutable to end-users, but the price is that they can’t get it right for every situation.

    So content data, the viewer app, the OS, the graphics adapter, the ports, the cable, and the display all can affect what happens!

    Check your display config to see if you can force RGB vs YCC mode when connecting by HDMI.


    Philipp Mochine
    • Offline

    Yeeeeeeeeeeeeah 😍

    Thank you for the link @wire! I managed to get it to work! (See the attachment)

    But it wasn’t easy! Because macOS Big Sur had big changes so the link by @wire didn’t work completely.

    If someone is reading this in future, here are the steps:

    1. Connect the problematic display.
    2. Download and run this script in Terminal by: “ruby patch-edid.rb”
    3. This creates a folder like DisplayVendorID-10ac/DisplayProductID-4080
    4. Now it gets different, because Big Sur doesn’t allow you to write into critical folders, you have to copy the whole display folder like this: sudo cp -R /System/Library/Displays /Library/
    5. Now go to /Library/Displays/Contents/Resources ( and not to /System/Library) and create a copy of the folder Overrides. Just to be safe
    6. Now drag and drop the created folder by the patch into Overrides
    7. restart

    Since with this change, my HDMI cable works.

    You must be logged in to view attached files.

    • Offline

    Holy cow, It worked?!
    I have not used that myself. I expected offer of only clues for find way out of config quagmire.
    Happy  it helped.
    Pls pay forward, thk u

Viewing 6 posts - 61 through 66 (of 66 total)

You must be logged in to reply to this topic.

Log in or Register

Display Calibration and Characterization powered by ArgyllCMS