|
From: Stephan A. <sup...@gm...> - 2011-02-18 08:57:14
|
Am 18.02.2011 09:49, schrieb Stephan Assmus: > Am 18.02.2011 03:07, schrieb Josiah Bryan: >> Vinnie wrote: >>>> Date: Thu, 17 Feb 2011 20:40:38 -0500 >>>> From: Josiah Bryan<jb...@pr...> >>>> >>>> would it be theoretically feasible for me to write >>>> my own agg::pixfmt_yuv422 pixel format..? >>>> >>> >>> Why not just pretend that it is rgb and use that? If you're drawing simple, solid shapes then it should work fine. You would just have to express your color values as YUV values (but in an rgb agg color). >> The only reason I can see NOT to pretend it's just RGB is because it's >> not a "repeatable" format -e.g., it's: >> >> UYVYUYVY... >> >> E.g. the order changes ever three bytes - It's not the same triplet each >> time. And that's with the packed format (UYVY) - Planar formats (where >> all the Y comes first, then 1/4th the size of Y is the U and the V) >> would be easier - but still, unable to pretend its RGB because one byte >> of the color would have to be at X, then the second byte of the color >> would have to be thrown several thousand bytes further down into the >> buffer and so on and so forth... >> >> Sorry, but good thought though. :-/ > > I had written such a pixel format once for a video editor I was working > on. The editor is open source now: > > http://dev.osdrawer.net/projects/clockwerk > > The pixel format stuff may well be MIT licensed, don't remember, but I > can give you permission to use that with AGG 2.4 license. I am > absolutely _not_ sure that you really need a special YCbCr format, > pretending RGB might work. And you don't need to convert to RGB because > the buffer has the packed layout. You could just expand it to YCbCr444 > with a fast loop, and then save the time in the rendering where you > don't have to handle the different offsets of the components anymore. > The video editor code actually does that, IIRC. I don't have the code > ready to look at right now, but I am happy to answer any questions if > you can't find your way around the code base. Just saw that there is an online code browser at the project hosting: http://dev.osdrawer.net/projects/clockwerk/repository/show/src/shared/painter I see there is YCbCr422 as well, but I don't remember if it really worked, it seemed to be faster to expand the buffer to YCbCr444 and back to 422 after rendering. Best regards, -Stephan |