[FFmpeg-devel] [Bulk] Re: [PATCH] smptebars filter
Stefano Sabatini
stefasab at gmail.com
Fri Aug 3 16:02:53 CEST 2012
On date Friday 2012-08-03 08:59:56 +0100, Tim Nicholson encoded:
> On 02/08/12 22:48, Stefano Sabatini wrote:
> > On date Thursday 2012-08-02 17:39:19 +0100, Tim Nicholson encoded:
>
> > [...]
>
> >
> > Drawutils convert the color specified in the RGB colorspace to
> > a color in the YUV CCIR colorspace.
> >
>
> Which is the primary source of the problem, it is not actually possible
> to create bars to the SMPTE spec (ECR 1-1978) in anything other than YUV
> colourspace. This is because the two colour blocks (i_pixel and q_pixel
> in your code) are not real colours, but phase shifted (rotated) segments
> of the colour burst signal designed to check alignment of the quadrature
> chroma decoder. They therefore have UV values but no Y value, and if
> converted to RGB colourspace produce negative values. (I presume this is
> what Paul was referring to)
>
> In a digital environment pure SMPTE bars are of limited value, but in
> case anyone would want to use the signal for the purposes intended
> (which they might if they believe them to be a genuine implementation) a
> common fudge, and it is a fudge, which means the signal pattern is *not*
> to the SMPTE standard but may be used in the same manner, is to add a Y
> offset so that the signal is not clipped in the RGB domain. Since the UV
> values are correct the signal will look in the right place on a
> vectorscope that ignores luma values.
>
> I believe the revised SMPTE RP 219-2002 standard which is suitable for
> HD and SD does not suffer fromm these issues, but I do not currently
> have a spec for it.
>
>
> > I don't know where these values come from (I just readapted the code
> > to the updated framework), but if you can provide a link to specs and
> > a rationale for your proposed values (in RGB or YUV CCIR colorspace)
> > that should be enough.
>
> I am not aware of the SMPTE spec being published online, they tend to
> charge for copies of their docs. However the following provides a good
> general description:-
>
> http://en.wikipedia.org/wiki/SMPTE_color_bars
>
> For more rigorous maths see:-
>
> http://avisynth.org/mediawiki/ColorBars_theory
>
> For a description of how the bars signal is supposed to be used:-
>
> http://spareroommedia.com/video/monitor_setup.html
>
> and for heavy bedtime reading there is a wealth of material at:-
>
> http://www.poynton.com/
>
>
> My values are based upon:-
> 0 IRE units= 0; 100 IRE units= 255; RGB
>
> For the pluge section this gives
>
> black= 255*7.5/100 = 19.125 => 19
> black-4= 255*3.5/100 = 8.925 => 9
> black+4= 255*11.5/100 = 29.325 => 29
>
> For the Q,-I sections
>
> Using the Rec 601 coefficients (ffmpegs default RGB to YUV matrix)
>
> Q:/ RGB 67, 0, 130 => YUV 46, 175, 148 (after rounding)
> -I:/ RGB 0, 68, 114 => YUV 61. 158. 95 (after rounding)
>
> The "correct" values being (see the avisynth page or poynton for
> detailed maths)
>
> Q:/ YUV 16, 175,148
> -I:/ YUV 16, 158, 95
>
> Which leads to my submission:-
>
>
> static const uint8_t white[4] = { 255, 255, 255, 255 };
> static const uint8_t black[4] = { 19, 19, 19, 255 };
>
> /* pluge pulses */
> static const uint8_t neg4ire[4] = { 9, 9, 9, 255 };
> static const uint8_t pos4ire[4] = { 29, 29, 29, 255 };
>
> +/* fudged Q/-I */
> static const uint8_t i_pixel[4] = { 0, 68, 130, 255 };
> static const uint8_t q_pixel[4] = { 67, 0, 130, 255 };
>
>
>
> >
> > (And I agree if we call it "SMPTE bars" I'd expect the pattern refers
> > to some standard).
> ...and as we are fudging some values I think we should say so as per my
> inline comment above...
Patch updated against the proposed values. In order to avoid the Q/-I
color "fudge" we could find some hack to tell ff_draw_color() to
accept YUV values and convert them to RGB colorspace, but I'm not sure
I'm willing to do the work...
--
FFmpeg = Friendly and Forgiving Martial Puristic Elfic Gem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-lavfi-add-smptebars-source.patch
Type: text/x-diff
Size: 7578 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120803/f8f0edcb/attachment.bin>
More information about the ffmpeg-devel
mailing list