[FFmpeg-devel] [PATCH] smptebars filter

[Stefano Sabatini]

On date Thursday 2012-08-02 17:39:19 +0100, Tim Nicholson encoded:
> On 02/08/12 17:04, Paul B Mahol wrote:
[...]
> >> Not sure about the PLUGE values though...
> >> I am used to working 16-235 YUV so may have got some maths wrong but by
> >> my understanding:-
> >>
> >>> +static uint8_t white[4] = { 255, 255, 255, 255 };
> >>> +static uint8_t black[4] = {   0,   0,   0, 255 };
> >>
> >> Whilst, in SMPTE bars, white is 100% black is 7.5%, with blanking at 0%,
> >> which would give:-
> >>
> >>    static uint8_t black[4] = { 19,  19,  19, 255 };
> >>
> >>> +
> >>> +/* made up values */
> >>> +static const uint8_t neg4ire[4] = {   7,   7,   7, 255 };
> >>> +static const uint8_t pos4ire[4] = {  17,  17,  17, 255 };
> >>
> >> These values would both be brighter than the original "black" above
> >> (0,0,0) surely?
> > 
> > They are not part of RGB/YUV, they can not be showed in such colorspace
> > they are completly made up values, and your values will not make them
> > any better.
> > 
> 
> Why are they "completly made up values"? How can a standard test pattern
> contain values that cannot be represented in at least one of the
> colourspaces?
> 
> SMPTE bars are supposed to contain a pluge pulse with sections that are
> supposed to be 4 IRE units above and below the standard NTSC black level
> of 7.5 IRE units which it is perfectly possible to represent in both RGB
> and YUV colourspace.
> 
> The naming, and placing in the drawn image suggests these constants are
> meant to represent these sections and I have suggested RGB values to
> match the required +/-4 values.
> 
> If we really cannot generate the correct values for these parts of the
> test signal we really should not refer to them as SMPTE bars.
> 
> Sorry if I have completely misunderstood, but I can't at the moment see
> what I am missing.
> 
> >>
> >> Based on my figures I would reckon:-
> >>
> >>   static const uint8_t neg4ire[4] = {   9,   9,   9, 255 };
> >>   static const uint8_t pos4ire[4] = {  29,  29,  29, 255 };
> >>
> >>
> >>> +static const uint8_t i_pixel[4] = { 224,   0,   0, 255 };
> >>> +static const uint8_t q_pixel[4] = {   0,   0, 176, 255 };
> >>
> >> Again these look a little curious to me, the "pure" values only exist in
> >> YUV land and are often "fudged" by bumping up the Y to avoid negative
> >> values in RGB land but preserve the phase so it looks correct on a
> >> vectorscope.
> >>
> >> My values are:-
> >>
> >>    static const uint8_t i_pixel[4] = {   0,  68, 114, 255 };
> >>    static const uint8_t q_pixel[4] = {  67,   0, 130, 255 };
> >>
> >> Which give the converted CbCr values of  158,95 and 175,148.

Drawutils convert the color specified in the RGB colorspace to 
a color in the YUV CCIR colorspace.

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.

(And I agree if we call it "SMPTE bars" I'd expect the pattern refers
to some standard).

Patch updated with misc minor fixes.
-- 
FFmpeg = Furious & Fantastic Mythic Perennial Eretic God
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-lavfi-add-smptebars-source.patch
Type: text/x-diff
Size: 6951 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120802/7a142460/attachment.bin>