| Forums | Search | Statistics | Polls | File Bank | 
 ∅ ?  
You must be logged in to post content on this forum.
PGenerator & DeviceControl Light Illusion Forums / PGenerator & DeviceControl /  
 

ColourSpace ZRO + PGenerator 1.6: HDR10 100-nit patch measuring ~70–80 nits on Hisense U7SG

 
Author apowers00
ZRO

#1 | Posted: Yesterday 14:28 
I'm hoping someone can help me troubleshoot an HDR10 calibration problem using ColourSpace ZRO and PGenerator 1.6. I've spent considerable time investigating it without identifying the cause, and I'm wondering whether I've misunderstood or incorrectly configured something in the HDR workflow.

**The main issue is that HDR10 grayscale patterns consistently measure approximately 20–30% below their expected PQ luminance, accompanied by unusually large chromaticity errors.** This occurs even though the TV correctly enters HDR Filmmaker mode and the meter readings are highly repeatable. And in comparison, Rtings found that the TV follows the PQ EOTF curve very well out of the box. https://www.rtings.com/tv/reviews/hisense/u7sg#test_29341

Interestingly, SDR calibration using the same equipment works extremely well.

## Equipment

**Display**
- Hisense U7SG, 55-inch, 2026 model
- Mini-LED LCD with quantum-dot color technology
- HDMI 2.1 input
- HDR10 supported
- HDR Filmmaker picture mode

**Pattern generator**
- Raspberry Pi 4 running official PGenerator 1.6
- Updated from an older PGenerator installation
- HDMI connected directly to the television
- Ethernet connected directly to my Windows laptop, using Windows Internet Connection Sharing
- Controlled through ColourSpace ZRO

**Measurement equipment**
- Calibrite ColorChecker Display Plus (i1Display Pro-family colorimeter)
- ColourSpace ZRO
- Spectral correction: Hisense U7Q QD-Mini LED correction from Ted's spectral correction collection, measured using a JETI 1501 HiRes spectroradiometer (2 nm)
- No U7SG-specific spectroradiometer profile is available to me

## Hisense HDR10 settings

I started from the HDR Filmmaker settings recommended by RTINGS:

- Picture Mode: HDR Filmmaker
- Color Temperature: Warm 1
- Peak Brightness: High
- Local Dimming: High
- Contrast: 50
- Black Level: 0
- Dynamic Tone Mapping: Off
- Dark Detail: Off
- RGB Gain: 0/0/0
- RGB Offset: 0/0/0
- HDMI Dynamic Range: Limited

I confirmed that the television actually switches into HDR Filmmaker when PGenerator enables HDR output.

No HDR white-balance or multipoint adjustments have been made.

## ColourSpace ZRO settings

- Target Gamut/EOTF: ST2084 Rec2020
- Patch Scale: Legal
- Bit Depth: 10-bit
- Limit Range: Disabled
- Patch Window: L20, approximately 20% of screen diagonal (4% screen area)
- Patch Position: Center (PosX 50, PosY 50)
- Background Color: Black
- Probe Extra Delay: Initially 2 seconds, subsequently tested at 4 seconds
- PGenerator Calibration Patches: Auto

I used a custom CSV of 10-bit Legal HDR10 grayscale and color patches, but also tested by entering the relevant RGB values directly in Manual Measure.

## PGenerator settings

Under PGenerator Hardware Options:

- TPG Mode: HDR
- Color Format: RGB (Full)
- Colorimetry: Rec2020
- Output Resolution: 3840 × 2160 at 60 Hz
- Scaling Type: Performance
- Patch Area: 100.00
- HDR EOTF: ST2084
- HDR Primaries/White Point metadata: P3/D65

HDR metadata:

- MinDML: 0.0005 nits
- MaxDML: 1,000 nits
- MaxCLL: 1,000 nits
- MaxFALL: 250 nits

I also tried manually clicking "Upload HDR Info Frame" without any improvement.

I understand that Rec2020 colorimetry with P3/D65 mastering-display metadata is a normal HDR10 configuration, but please let me know if any of these settings are inappropriate.

## Actual HDR measurements

Using 10-bit Legal grayscale patches, with the TV menu closed:

| Target PQ luminance | Actual luminance | Approximate error |
|---|---|---|
| 100 nits | 82.0 nits | -18% |
| 200 nits | 159.7 nits | -20% |
| 400 nits | 321.6 nits | -20% |

The errors are surprisingly consistent across these PQ levels.

For example, the nominal 100-nit patch uses RGB 509/509/509 and produces a ColourSpace target of 99.913 nits.

Its measured chromaticity was approximately:

- Target: x = 0.3127, y = 0.3290
- Actual: x = 0.3086, y = 0.3053
- ΔE2000: 6.61

Subsequent repeated measurements were typically around 70–82 nits, with similarly large chromaticity deviations. The exact results varied with pattern area and background configuration.

At the higher end, a maximum white HDR stimulus produced approximately 1,485 nits with a 20% diagonal window, so the display is clearly capable of substantial HDR peak brightness.

## Troubleshooting already performed

**1. Verified generator output and HDMI range**

I confirmed that PGenerator is configured for RGB Full output, ColourSpace for 10-bit Legal patches, and the Hisense for Limited HDMI range.

I also tried the TV's Auto HDMI range setting, which did not improve the measurements.

Changing PGenerator to YCbCr 4:4:4 likewise produced essentially the same 100-nit luminance and white-point errors.

**2. Checked patch values and bit depth**

ColourSpace showed the expected RGB 509/509/509 values for the nominal 100-nit patch.

I entered these values manually rather than selecting the CSV patch, with essentially identical results.

I also tried the approximately equivalent 8-bit Legal patch (RGB 127/127/127), which measured around 72 nits.

**3. Investigated local dimming and patch size**

With Local Dimming High and a centered L20 patch, the 100-nit measurement was approximately 82 nits.

Disabling local dimming produced approximately 64 nits, with a significant change in chromaticity.

Changing from L20 to L10 produced approximately 50 nits, with much larger chromaticity errors. The L10 patch also appeared quite small physically.

A full-field 100-nit patch produced approximately 29 nits.

These results suggest substantial dependence on pattern size and backlight behavior.

**4. Tested different patch backgrounds**

Changing the background from black to a neutral gray (RGB 64/64/64) reduced the 100-nit measurement to approximately 52 nits.

I subsequently restored the black background.

**5. Checked probe settling and repeatability**

Increasing Extra Delay from 2 to 4 seconds made no meaningful improvement.

Three consecutive measurements of the same stationary patch were nearly identical.

The patch appears visually uniform with well-defined rectangular edges, and the colorimeter is centered over it.

**6. Tested color-temperature and spectral-correction settings**

Warm 1 was closer to the D65 target than Warm 2.

Disabling the borrowed Hisense U7Q spectral correction had only a modest effect. The large luminance deficit and chromaticity errors persisted.

I restored the correction afterward.

**7. Attempted independent verification**

I also tried using the Windows laptop's USB-C-to-HDMI output with Windows HDR enabled. ColourSpace's floating patch window measured only approximately 28 nits for the nominal 100-nit patch. However, I recognize that the Windows HDR compositor may transform ordinary SDR-rendered patch values, so I don't consider this a reliable reference either.

## Why I suspect a configuration issue

Using exactly the same Raspberry Pi, colorimeter, and ColourSpace ZRO software, I was able to complete a very successful SDR calibration:

- Rec709 Gamma 2.2
- Average grayscale ΔE2000 approximately 1.09
- Average color ΔE2000 approximately 0.72
- Maximum measured color ΔE2000 approximately 2.59

Thus, SDR pattern generation and measurement appear to work properly.

Additionally, RTINGS reports very good HDR PQ tracking for the U7SG series, whereas my measurements show large, systematic deviations.

## Questions

1. Do the ColourSpace ZRO and PGenerator 1.6 HDR settings above look correct, particularly the combination of 10-bit Legal patches, RGB Full generator output, and Limited HDMI range at the television?

2. Is there anything special required to configure PGenerator 1.6 for accurate HDR10 grayscale measurements beyond selecting TPG Mode HDR, ST2084, Rec2020, and uploading the HDR InfoFrame?

3. Is the difference between P3/D65 HDR metadata primaries and Rec2020 colorimetry relevant here?

4. Does the L20 patch size correspond to the recommended pattern geometry for HDR calibration on Mini-LED displays, or would you recommend another patch size or background strategy?

5. Could the large chromaticity changes associated with patch size be related to a generator scaling, range, or rendering issue?

6. Is there a simple built-in test or known reference patch sequence in ColourSpace ZRO that would allow me to verify that PGenerator is generating the correct HDR10 luminance levels, without relying on my custom CSV?

7. Is there a way to inspect or verify the actual HDR output signal using ColourSpace, DeviceControl, or PGenerator's diagnostic tools?

8. Are there any known limitations or issues with PGenerator 1.6 HDR output when used with the current ColourSpace ZRO version?

I'm particularly interested in determining whether I've configured something incorrectly before attempting any HDR white-balance adjustments. I would prefer not to calibrate the TV against potentially incorrect HDR patterns.

I can provide screenshots of all the hardware and software settings, as well as the patch CSV and measurement logs if that would be helpful.

Thank you very much for any guidance.

Best regards

Author Steve Male
INF

#2 | Posted: Yesterday 18:51 
Did you make a ST2084 colour space target with the correct peak value?
(I see no mention of that in your treatise...)
The default is obviously 10,000 nits.

Steve
Steve Shaw
Mob Boss at Light Illusion

PGenerator & DeviceControl Light Illusion Forums / PGenerator & DeviceControl /
 ColourSpace ZRO + PGenerator 1.6: HDR10 100-nit patch measuring ~70–80 nits on Hisense U7SG

 

 
Online now: Guests - 3
Members - 0
Max. ever online: 380 [24 Mar 2026 21:54]
Guests - 380 / Members - 0