On 2019-06-19 16:41, Carl Karsten wrote:
why do my hacks get different numbers that yours?
and what to you get for Ubuntu Orange?
As far as I can tell you get identical values if you convert from RGB
using the script, and then pack the values. But different values if you
start with your own Y Cb Cr values and just pack those values.
That says to me the two R G B to Y Cb Cr conversions are using different
colour models.
Starting with the R G B values you gave, I get:
-=- cut here -=-
ewen@ashram:~$ python /tmp/pattern.py
221 72 20 RGB is 110 76 206 Y Cb Cr is 4c6ece6e
ewen@ashram:~$
-=- cut here -=-
which exactly matches your first results. I'm sure if I were just to
pack your Y Cb Cr values I'd get the same results as your second answer.
As I noted in my previous message the colour model used for RGB to Y Cb
Cr conversion in:
https://github.com/timvideos/HDMI2USB-litex-firmware/blob/eaab51fd65f2c7276c32e6973ca2c86beb188fb0/firmware/pattern.py#L1-L12
is apparently *different* from the colour model you're using for RGB to
Y Cb Cr (eg https://encycolorpedia.com/dd4814).
Y Cb Cr system is a *family* of colour models (depending on the primary
reference colours chosen, and the ratios used):
https://en.wikipedia.org/wiki/YCbCr
The HDMI2USB pattern.py script is... under commented, so I'm guessing
which precise colour model it is trying to implement (there are several
of them depending on the precise choice of reference R / G / B used, and
the ratios used for calculating luma, ie Y). But it seems like, eg, the
colour model used for your conversion / https://encycolorpedia.com/
conversion is a different one (also... under documented).
Eyeballing it, it looks like pattern.py implements a close approximation
to ITU-R BT.601 (aka CCIR 601) which is a SD digital component video
television colour model:
https://en.wikipedia.org/wiki/YCbCr#ITU-R_BT.601_conversion
But, eg, the ITU-R BT.709 colour model (HDTV):
https://en.wikipedia.org/wiki/YCbCr#ITU-R_BT.709_conversion
is different ratios *and* different reference R / G / B, resulting in
different values. (Off the top of my head I think BT.709 was intended
to standardise across the world the reference colours used for the
model, whereas ISTR that BT.601 used different reference colours in NTSC
/ PAL / SECAM countries...)
If you want *precisely* a specific reference colour (eg, for client sign
off of "this is *exactly* Debian Red"), you'll want known colour
balanced (eg, precise Kelvin colour temperature) lighting in the room,
allowed to warm up and stablise (and all other light sources
eliminated), a printed guaranteed stable reference colour swatch to
compare with (eg, Pantone), and even then you'll probably have to tweak
it, eg per projector, display, screen, etc you're displaying on, and
perhaps per day. You'll probably also And possibly use need a colour
meter to measure the deviation.
If "yeah, that looks about right" is good enough, pick whichever values
of Y Cb Cr make you happiest :-)
At least now you know how to turn the Y Cb Cr values you choose into the
packed values that HDMI2USB's firmware / gateware expects.
Ewen
PS: Like most things, colour is as complicated as you want to make it!
PPS: Most television standards have a reference black / reference white,
which are actually greys, because of complicated television transmission
standards reasons. I suspect both the BT.601 and BT.709 colour models
are also taking that into account....
--
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/28e2ff5f-3994-4794-7125-8c86d3aae9bc%40mcneill.gen.nz.
