"Nemosoft Unv." wrote: > On 30-May-01 Mark McClelland wrote: > > > >> Im assuming the library is something like > >> > >> convert_fromfmt_tofmt(from, to > >> > > Not to nitpick, but wouldn't this be better: > > > > convert(src, srcformat, dest, destformat) > > > > That way, new formats could be added without changing the apps' code (or > > even without recompiling it if we use a shared lib) > > In case you´re interested... I´ve written up my idea on how an (expandable) > shared library should look like. The URL is http://www.smcc.demon.nl/ccvt/ > This is a draft, not fully completed yet, and open for debate. It contains > documentation from both the programmers point of view (us!), and the > library maintainers/writers (ehm, us? :)) POV. Actually I've already implemented such a beast. I have no objection to GPLing it (that was my general intent), other than the fact that I'm too lazy to create a web page or put much effort into support. You've shamed me - I'll release it. ;-) What I have does pretty much all RGB<->YUV conversions, but all in C at this point. I define an "Image Descriptor" data structure which defines the representation (packed/planar YUV or packed RGB with appropriate paramaters such as chroma subsampling and r/g/b bpp and component masks) and includes pointers to the data (with row stride for flexibility). This data structure can for example describe all V4L and AVI RGB/YUV formats as well as a TrueColor XImage (packed RGB). The way I've structured it is to allow for individual optimized conversions, so any of my C implementations could be individually replaced with MMX/whatever implementations). Since this is intended for use with repeated (video) conversions, you first request a converter function (converter = GetConverter(imageDesc1, imageDesc2), which internally does a table lookup for a corresponding converter), and then use it to perform conversions (converter(imageDescIn, imageDescOut). Gimme a week to procastinate, and I'll release the thing. Ben
