why do my hacks get different numbers that yours?
and what to you get for Ubuntu Orange?
221 72 20
110 76 206
ubuntu orange: 4c6ece6e
ubuntu orange: 536fc56f
debian red: 8154d454
def rgb2ycbcr(r, g, b):
y = int(0.299*r + 0.587*g + 0.114*b)
cb = int(-0.1687*r - 0.3313*g + 0.5*b + 128)
cr = int(0.5*r - 0.4187*g - 0.0813*b + 128)
return y, cb, cr
def ycbcr_pack(y, cb, cr):
value = y
value |= cr << 8
value |= y << 16
value |= cb << 24
return value
"""
color_bars_rgb = [
[255, 255, 255],
[255, 255, 0],
[0, 255, 255],
[0, 255, 0],
[255, 0, 255],
[255, 0, 0],
[0, 0, 255],
[0, 0, 0],
]
color_bars_ycbcr = []
for color_bar_rgb in color_bars_rgb:
r, g, b = color_bar_rgb
y, cb, cr = rgb2ycbcr(r, g, b)
color_bars_ycbcr.append([y, cb, cr])
for color_bar_ycbcr in color_bars_ycbcr:
value = ycbcr_pack(*color_bar_ycbcr)
print("%08x" %value)
"""
r,g,b = (int(h,16) for h in ['dd','48','14'])
print(r,g,b)
y, cb, cr = rgb2ycbcr(r, g, b)
print(y, cb, cr)
value = ycbcr_pack(y, cb, cr)
print("ubuntu orange: %08x" %value)
# https://encycolorpedia.com/dd4814
# Y: 111.045, Cb: 83.120, Cr: 197.103
y, cb, cr = 111, 83, 197
value = ycbcr_pack(y, cb, cr)
print("ubuntu orange: %08x" %value)
# https://encycolorpedia.com/d70a53
# Y: 84.429, Cb: 129.707, Cr: 212.812
y, cb, cr = 84, 129, 212
value = ycbcr_pack(y, cb, cr)
print(" debian red: %08x" %value)
On Tue, Jun 18, 2019 at 8:44 PM Ewen McNeill
<hdmi2...@ewen.mcneill.gen.nz> wrote:
>
> On 2019-06-19 11:12, Carl Karsten wrote:
> > I'm stuck on what constant to use.
> > framebuffer[i] = 0x80108010; /* black in YCbCr 4:2:2*/
>
> Ah, magic constants.
>
> That particular magic constant matches the YCBCR422_BLACK define in:
>
> https://github.com/timvideos/HDMI2USB-litex-firmware/blob/eaab51fd65f2c7276c32e6973ca2c86beb188fb0/firmware/pattern.h#L6-L14
>
> so at least the constant is consistent with the comment....
>
> > I'm trying to do this:
> > YCbCr (84, 130, 213) = debian red https://encycolorpedia.com/d70a53
> > hex: 54 82 d5
>
> Debian red isn't exactly purple :-)
>
> The pattern.h magic values (above) refer to:
>
> https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/firmware/pattern.py
>
> as how the values were calculated, and in particular:
>
> https://github.com/timvideos/HDMI2USB-litex-firmware/blob/eaab51fd65f2c7276c32e6973ca2c86beb188fb0/firmware/pattern.py#L1-L12
>
> seems to be the RGB -> Y Cb Cr -> packed Y Cb Cr calculations.
>
> Hacking that script to put in the Debian Red RGB values, and some extra
> print statements gives:
>
> -=- cut here -=-
> ewen@ashram:~$ python3 /tmp/pattern.py
> 215 10 83 RGB is 79 129 224 Y Cb Cr is 814fe04f
> ewen@ashram:~$
> -=- cut here -=-
>
> So in theory something like:
>
> framebuffer[i] = 0x814fe04f; // Debian Red
>
> will get fairly close.
>
> It looks like it's floor()ing the values in the RGB -> Y Cb Cr
> conversion, rather than round()ing them, and assigning less to the Y
> value than the online conversion, so you might want to finesse that a
> bit more if the *exact* red matters to you as the colour model used
> seems lightly different. But I suspect "colour temperature of the
> projector" and "colour temperature of the room lighting" will probably
> make more perceived difference.... :-)
>
> From a glance at the code it looks like the pattern is:
>
> Cb Y Cr Y
>
> (in big endian format). Which means:
>
> framebuffer[i] = 0x8254d554;
>
> I think corresponds to the Y Cb Cr values you came up with.
>
> Ewen
>
> PS: I'm dubious about the accuracy of just repeating the 8-bit Y
> component twice to give it 16 bits, as that seems like something that's
> only really accurate at the extremes (Y = 0 / Y = 255). But off the top
> of my head it's probably "close enough" to be recognisably like what you
> were going for anyway.
>
> --
> You received this message because you are subscribed to the Google Groups
> "hdmi2usb - A HDMI capture solution" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hdmi2usb+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/hdmi2usb/7acc66c4-34ee-cd6a-fea3-03da40f62bf6%40mcneill.gen.nz.
--
Carl K
--
You received this message because you are subscribed to the Google Groups
"hdmi2usb - A HDMI capture solution" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to hdmi2usb+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/hdmi2usb/CADmzSSi_zgJH-mgbkZujcWRQ3fwmp%3DYZj1fF7BfFNfk9oHnphw%40mail.gmail.com.
