[FFmpeg-devel] [RFC] Scalar color conversion utils (colorutils.[hc])?
Sat May 2 00:48:11 CEST 2009
On date Tuesday 2009-04-28 23:41:15 +0200, Michael Niedermayer encoded:
> On Tue, Apr 28, 2009 at 10:28:56PM +0200, Stefano Sabatini wrote:
> > Hi all,
> > the need for such a facility mainly arises for libavfilter filters.
> > For example we may need something to work like this:
> > pad=padcolor=COLOR
> > or
> > drawbox=X:Y:COLOR
> > and many other filters as well may need to take in input a textual
> > representation of a color and convert it to a given colorspace.
> > libavcodec/colorspace.h defines some useful macros for converting from
> > RGB to YUV, but I think what we need here is a convenient API of the form:
> > int av_parse_color(uint16_t color, enum PixelFormat dst_pix_fmt, const char *color_string, void *log_ctx)
> > and
> > int av_convert_color_to(uint16_t *dst_color, enum PixelFormat dst_pix_fmt,
> > (uint16_t *src_color, enum PixelFormat src_pix_fmt,
> > void *log_ctx);
> > Support for HSV colorspace could be provided defining an HSV pixel format.
> > Some of the questions which need a response:
> > * We may need a table containing all the colornames <-> color. In
> > which colorspace should be specified the color? (An RGB32 variant
> > could be the ideal solution.)
> doesnt matter ...
> > * Where it should be implemented? lavfi or lsws seem the better
> > candidates.
> probably lavfi
> > * How should be done the color-spec string? It may contains a simple
> > name but also a color specifications. Variants which come to mind:
> > rgb=RR:GG::BB, hsv=HH:SS:VV, yuv=YY:UU:VV.
> html 0xRRGGBB must be supported
> so must
> i see no need for further variants in the near future.
Attached stub, result of the test is:
Cannot find color 'foo'
Cannot find color 'red'
Cannot find color 'Red '
Cannot find color 'RED'
Red -> R(255) G(0) B(0)
0x000000 -> R(0) G(0) B(0)
0x3e34ff -> R(62) G(52) B(255)
Invalid RGB color string: '0xfoobar'
Invalid RGB color string: '0xffffeeeeeeee'
Conversion has to be implemented yet.
I wonder if the case-insensitive matching of the name is a feature
worth to be implemented, but as far as I understood it would require a
linear search as opposed to a binary search as currently implemented.
FFmpeg = Faboulous Free Multipurpose Purposeless Extravagant Governor
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 14654 bytes
Desc: not available
More information about the ffmpeg-devel