NPP nv12->bgr incorrect coefficients

Accelerated Computing GPU-Accelerated Libraries
1

Hi,

I am seeing a peculiar issue with nppiNV12ToBGR_709HDTV_8u_P2C3R.

I have created a bt709 test file using gstreamer:

gst-launch-1.0 videotestsrc num-buffers=100 ! “video/x-raw, height=1080, width=1920, colorimetry=(string)bt709” ! x264enc bitrate=10000000 ! qtmux ! filesink location=bt709.mp4

I then decoded the same file using the codec sdk and converted NV12->BGR using nppiNV12ToBGR_709HDTV_8u_P2C3R. This resulted in poor colour conversion. Dynamic range is lower than the original, ultimately the picture is dull.

nppiNV12ToBGR_709HDTV_8u_P2C3R
[url]https://pasteboard.co/IriQnNw.bmp[/url]

I created a kernel which i believe uses the correct coefficients which produces much better colours and represents the original image.

    float r = y * 1.164384 + v * 1.792741 - 248.101004;
    float g = y * 1.164384 - u * 0.213249 - v * 0.532909 + 76.878085;
    float b = y * 1.164384 + u * 2.112402 - 289.017577;

[url]https://pasteboard.co/IriRS0H.bmp[/url]

Am i doing something wrong or is there an issue with npp’s color conversion?

Thanks in advance,
Chris

2

Can you confirm whether the input is treated as full or limited range ycbcr. Also that the output is full range BGR? It looks to me like nppiNV12ToBGR_709HDTV_8u_P2C3R and nppiNV12ToBGR_8u_P2C3R output limited range BGR [16-235].

Thanks again,
Chris

3

I can confirm that both nppiNV12ToBGR_709HDTV_8u_P2C3R and nppiNV12ToBGR_8u_P2C3R assume (wrongly IMHO) ycbcr input ranges 0…255.

If the inputs are truly bt601 or bt709, the output for black and white are as follows…

void test_719_to_bgr(const uint8_t* nv12_data){

constexpr size_t input_stride = 8;
constexpr size_t output_stride = 3;
uint8_t *cu_nv12;
uint8_t *cu_bgr;
cudaMalloc(&cu_nv12, 12);
cudaMalloc(&cu_bgr, 3);
cudaMemcpy(cu_nv12, nv12_data, 12, cudaMemcpyHostToDevice);
NppiSize roi{1,1};
Npp8u *yuv_ptrs = {cu_nv12, cu_nv12 + input_stride};
nppiNV12ToBGR_709HDTV_8u_P2C3R(yuv_ptrs, input_stride, cu_bgr, output_stride, roi);
std::array<uint8_t,3> result_bgr{};
cudaMemcpy(&result_bgr[0], cu_bgr, 3, cudaMemcpyDeviceToHost);
for (auto &val : result_bgr){
std::cout << std::to_string(val) << " ";
}
std::cout << “\n”;
}

constexpr uint8_t nv12_black = {0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x80, 0x00, 0x00};
constexpr uint8_t nv12_white = {0xeb, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x80, 0x00, 0x00};

test_719_to_bgr(nv12_black);
test_719_to_bgr(nv12_white);

Actual results
16 16 16
235 235 235

Expected results
0 0 0
255 255 255

4

you might wish to file a bug. The instructions are linked to a sticky post at the top of the CUDA programming forum

5

I have raised a bug. I think the best solution here is to either add some new functions for limited colour range, or, add a parameter for colour range. At the very least, document the full range assumption.

6

https://developer.nvidia.com/nvidia_bug/2672777

7

You need to change limited range R’G’B’ that you got (235, 235, 235 is R’G’B’, not Y’Cb’Cr’, Y’Cb’Cr’ encoded with BT.709 will be 235, 128, 128) to full RGB after that. Sigh.

8

What happened to the bug?

9

As a result of the bug, these new functions were added to NPP:

nppiNV12ToBGR709CSC_8u_P2C3R_Ctx()
nppiNV12ToBGR709CSC_8u_P2C3R()
nppiNV12ToRGB709CSC_8u_P2C3R_Ctx()
nppiNV12ToRGB709CSC_8u_P2C3R()

1 Like
10

I will just point out that this is same bug you have in StretchRect because you always convert from limited to limited range, YCbCr to R’G’B’. Indeed, the fact that R = G = B means it is R’G’B’, not YCbCr and limited range R’G’B’ indeed has black at 16 and white 235. And no 16-240 thing.
Actual results
16 16 16
235 235 235

See: direct3d9: add an internal VideoProcessor to do the range conversion (a9474e0a) · Commits · VideoLAN / VLC · GitLab

assume (wrongly IMHO) ycbcr input ranges 0…255.

That is not what happens.