EBU R103 and limited/full RGB scope and data

Hello,

Do you guys know why premiere dosent offer the option to have the RGB parade in the actual and used "limited range" 16-235 vs the full range 0-255 that its displaying now. File is 8bit limited, project is limited, export will be YUV/YCBCR limited ... the corresponding RGB scope should be on the limited 16-235 range ?

Scope side by side same signal YUV/YCBCR is limited, RGB should be limited too ?

Why premiere seems to convert YCBCR limited>full RGB 0-255 ?

Im asking because the the EBU R103 https://tech.ebu.ch/docs/r/r103.pdf states that RGB from YUV/YCBCR should be limited to 5-246 on the limited 16-235 scale.

Then premiere, for their EBU R103 limiter setting.
105 = IRE -5 to 105, RGB -13 to 268, Y 5 to 246. EBU R103 "Preferred".

As we can see they took the 0-255 RGB full range and calculated the 5% tolerance from there that is -13 to 268.

Why premiere dosent stick with limited RGB in scope monitoring and limiting ? 

At first my guess was that maybe because premiere is PC display based it does limited YUV> Full RGB conversion to display level correctly on the PC monitor ... but that should be transparent to the user ? Visible RGB scope should reflect level on the file and display limited YUV and limited RGB ... also ... the r103 limiter should also use those limited value ?

Now side by side on adobe lumetri scope you have limited and full data ... I think it can cause confusion .... on what you are working with.

It should not be more YUV to RGB from BT.709-6:

The BT.709-6 standard specifies the equations for RGB to YUV conversion:

Y = R * 0.2126 + G * 0.7152 + B * 0.0722
Cb = (R * -0.2126/1.8556 + G * -0.7152/1.8556 + B * 0.9278/1.8556) * 224/219 + 128
Cr = (R * 0.7874/1.5748 + G * -0.7152/1.5748 + B *-0.0722/1.5748) * 224/219 + 128

The reverse takes a bit of rearranging. The equations here show this reversal using the original numbers from the BT.709-6 standard so as not to introduce rounding errors.

R = Y + (Cr – 128) * 219/224 * 1.5748
G = Y + (Cb – 128) * 219/224 * -0.0722*1.8556/0.7152 + (Cr – 128) * 219/224 * -0.2126*1.5748/0.7152
B = Y + (Cb – 128) * 219/224 * 1.8556

Note that these RGB values have a valid range of 16 to 235.

These equations can be self tested by converting back and forth between RGB and YCrCb.

But it seems that its more

PCs use full range values (0,0,0 for black and 255,255,255 for white) so the RGB values need to be rescaled to full range:

Rfull = (R – 16) * 255/219
Gfull = (G – 16) * 255/219
Bfull = (B – 16) * 255/219

The fullrange rescale can be rolled into the conversion equations to get:

Rfull = Y * 1.1643835616 + Cr * 1.7927410714 + -248.100994
Gfull = Y * 1.1643835616 + Cb * -0.2132486143 + Cr * -0.5329093286 + 76.878080
Bfull = Y * 1.1643835616 + Cb * 2.1124017857 + -289.017566

Clamp the resulting RGB values to min 0 max 255. To convert to integer add 0.5 and truncate (cast to int). Some possible values are critically close to the 0.5 rounding point – if calculated using float precision some integer values will be off by 1 compared to the double precision reference.

This won’t matter for most applications. The numbers shown have the minimum required precision to ensure an exact integer match to the reference when using double precision floats.

Does someone know why there is no limited RGB scope available, and why the EBU R103 limit in RGB full range instead of RGB limited like recommended in EBU R103 ?