0

This is a follow up question to this thread. I have now managed to just rotate the UV components (chroma) without touching luma... sort of.

I convert from RGB to YUV using this solution, change the UV values and convert back to RGB.

However, the luma still seems to be affected - not sure why though. It doesn't seem to be limited to my code either - there's probably something that goes on that I don't understand about - as I see this happening in other VirtualDub plugins (such as Donald Graft's hue plugin).

To give you an example, I have rotated chroma randomly with different values on each line. The image here shows this.

YUV image

The top left corner is the original image. The two images on the right are U and V and bottom left is the Y component (luma). As you can see, in this section, the brightly coloured luma parts are affected by the chroma change. Any ideas why this is? Is this to do with clipping in the RGB colour space or something else? And is there a way to overcome this?

Captain Jack
  • 144
  • 13
  • Try doing calculation with float numbers. If you do not rotate, do you get the same values of original RGB? – Giacomo Catenazzi Apr 24 '18 at 08:03
  • Which calculation - the conversion or rotation? If I don't rotate, yes, same colours (as far as I can see). The rotation is done like this: `int Ut = ((U-128) * cos(hue[H]) + (V-128) * sin(hue[H])) + 128; int Vt = ((V-128) * cos(hue[H]) - (U-128) * sin(hue[H])) + 128;` – Captain Jack Apr 24 '18 at 09:31
  • If you did rotation correctly, you modify just U and V, so you do not touch Y and this should be constant. To me, the problem seems to be a stupid error (wrong sign, wrong constant, off-by-one, etc.) and not the complex part (colour space conversion). You must find yourself or publish the code, so that we can check. Or it is just an approximation error (the errors appear on dark (small value) colours). – Giacomo Catenazzi Apr 24 '18 at 09:41
  • I don't understand how do you infer that "luma is affected". What do you see in the picture? I see nothing. Note that you can work in YUV 4:4:4 mode where you can leave Luma channel alone and thus it will be strictly unaffected. – shekh Apr 24 '18 at 09:45
  • So maybe I\m looking the wrong problem. On the figure bottom left, I see some banding (originally red and purple). Small but still noticeable on yellows. I was caring just this part, where luma should be preserved but it is in fact not preserved. – Giacomo Catenazzi Apr 24 '18 at 09:50
  • Now I noticed a lot of vertical noise. Normally you should get equal outputs for equal inputs if your formula is per-pixel. – shekh Apr 24 '18 at 09:59
  • @shekh Yes, it's per-pixel. – Captain Jack Apr 24 '18 at 13:14
  • @GiacomoCatenazzi Yes, that's the part that I am talking about. I am not sure why it's not preserved. The conversion between RGB and YUV is taken from the link in my original post. – Captain Jack Apr 24 '18 at 13:16
  • @CaptainJackI must say that I do not like the formula in that link: it uses "tricks" to be able to do calculation with integer, but than one should be extra carefully about integer size and precision. But because you use `cos` and `sin`, which are slow and floating instruction, I would use normal formulas, with floating points.See e.g. https://en.wikipedia.org/wiki/YUV#Conversion_to/from_RGB I would use Rec.BT.709 – Giacomo Catenazzi Apr 24 '18 at 13:23
  • @GiacomoCatenazzi The cos/sin is for rotation rather than conversion. You're right - it's very slow. I want to see if I can create a matrix and do rotation that way. Will investigate ways to convert between RGB and YUV without losing precision, though it will be slower with floats. – Captain Jack Apr 24 '18 at 16:43
  • 1
    Yes, but rotation it is in the middle of calculation. Try with float, and only later try to optimize, and check how to do with integers (and with what precision) – Giacomo Catenazzi Apr 24 '18 at 17:28

0 Answers0