RGB -> YUV values are off ever so slightly

47 views
Skip to first unread message

David Pham

unread,
Apr 9, 2020, 2:20:20 PM4/9/20
to Parallel and Distributed Systems at SFU (431)
Trying to debug an issue where my GPU YUV contrast enhancement image is slightly off from my serial implementation. I've managed to track down the problem to my rgb -> yuv function. I've summed up both my serial and GPU yuv values to see if there is a difference between them. There is a slight difference and I can't seem to figure out what might be causing it. My GPU implementation is the very similar to the serial implementation. I'm not sure if its a round off error from the GPU, but I don't believe that it is a race condition because I do get the same sum every time and I believe my implementation is safe from execution reordering. 

I've posted my sumchecks below:

CPU INITIAL RGB R sum 250102155, 

CPU INITIAL RGB G sum 315281034, 

CPU INITIAL RGB B sum 350514841, 

CPU RGB -> YUV Y sum 298069482, 

CPU RGB -> YUV U sum 380262369, 

CPU RGB -> YUV V sum 317006456, 


GPU INITIAL RGB R sum 250102155, 

GPU INITIAL RGB G sum 315281034, 

GPU INITIAL RGB B sum 350514841, 

GPU RGB -> YUV Y sum 298069224, 

GPU RGB -> YUV U sum 380262366, 

GPU RGB -> YUV V sum 317006456,

Khang Bùi

unread,
Apr 9, 2020, 5:39:30 PM4/9/20
to Parallel and Distributed Systems at SFU (431)
Hi David, I think we are encountering the same issue. My gpu_rgb2yuv performs the same calculations as the CPU version, but the number are also always slightly off
Here's my output. You can see that it's always off by 1 (either lower or higher), so my guess is it's indeed a rounding difference when performing floating point calculation between CPU and GPU.

Khang Bùi

unread,
Apr 9, 2020, 5:41:08 PM4/9/20
to Parallel and Distributed Systems at SFU (431)
And to clarify, these numbers are comparing y_value computed by CPU and GPU respectively after performing rgb2yuv.

David Pham

unread,
Apr 9, 2020, 5:46:47 PM4/9/20
to parallel-s...@googlegroups.com
So our issues are slightly different. It looks like your converted Y values are consistently off by 1 for each pixel. The total difference between the sum of my Y pixels is ~ 258. So the majority of my pixels are the same, but there is a small subset that are different. It might be a similar round off error that is causing it? I'm kind of at a loss for what is causing this. 

--
You received this message because you are subscribed to the Google Groups "Parallel and Distributed Systems at SFU (431)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to parallel-systems...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/parallel-systems-sfu/296dba69-ba2b-4d26-bee4-121d611bc6a6%40googlegroups.com.

Khang Bùi

unread,
Apr 9, 2020, 6:20:39 PM4/9/20
to Parallel and Distributed Systems at SFU (431)
Most of my pixels are also correct - I think my different pixels count is around 700, which is still minimal compared to 200k number of pixels.
After investigating more, I found some results that is even more strange:

- If you compare the calculation for r g b values separatedly - (0.299*r), (0.587*g), (0.114*b), it seems that CPU and GPU calculations' result are identical.

- However, if you declare 3 int variables for each of these multiplication ,and y = (unsigned char) int 1 + int 2 + int 3; Now all the pixels' values are off.


David Pham

unread,
Apr 9, 2020, 6:41:19 PM4/9/20
to parallel-s...@googlegroups.com
I took what you did but did it with float values. So replace int 1, 2, 3 with float 1,2,3 and did that for both my serial and GPU rgb->YUV implementations for Y. I also did the same for U because my U values were also slightly off. Now that I've converted them to floats, I do get consistent values. I.E my serial and GPU implementation both yield the same image. 

However, I'm not sure if this is what was wanted in the assignment. I still fail the test script because my image does not match the reference image. 

--
You received this message because you are subscribed to the Google Groups "Parallel and Distributed Systems at SFU (431)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to parallel-systems...@googlegroups.com.

Khang Bùi

unread,
Apr 10, 2020, 3:57:53 AM4/10/20
to Parallel and Distributed Systems at SFU (431)
To Professor,

Is it ok if we just ignore the validation script in the case that we cannot fix this problem - and just show that with the same logic CPU and GPU output is identical - and not comparing to the referenced files? I have cross-checked with classmates and there is no difference in the way we implement our __global__ function, yet they passed the validation and I don't. It seems that there is a known problem regarding the accuracy of floating point calculation using cuda, and I'm not really sure if I will be able to identify and fix this early enough.    
Reply all
Reply to author
Forward
0 new messages