Hi ! > i thought about the yuyv-topic again. a packed yuv422 buffer can be > transformed into a planar yuv422 buffer. this way you get 3 buffers. one for > Y (size is T), one for U (size T/2) and one for V (T/2). can't this buffer > be accessed like those vga 4-bit plane-buffers ?? No. VGA-4-plane was handled in a somehat weird way, right. We used a planar read configuration and a color-switched write configuration. However the assumption, that each single pixel can be controlled individually still held. The YUVU setup is different. It basically doesn't really fit the GGI picture of a "normal" graphics mode. For the operations covered by LibGGI I would suggest to handle it like a mode that has the "Y" resolution. Thus if you set a pixel, the neighbouring pixel will get the same color values u/v as well. This is IMHO the only consistent way out. It isn't too bad, as the reason for subsampling u/v is, that the eye has not as much resolution for color than for greyscale. It has some strange implications for read/modify/write stuff, though. Well - on colormapped modes we have similar problems. For the DirectBuffer we might want to define a new possible entry for the bitmeaning field that would mean "u on even pixel numbers v on odd ones" or similar. The other alternative would be to allow some new kind of directbuffer that can hold multiple entries, one for each "plane" (the planes happen to be stored in an interleaved fashion in our case). This would more generically allow for such subsampled formats. There is also a double-subsampled format, where a pixel-quad (2x2) shares u,v but has 4 y values. My hardware doesn't have that - do you know, how it is stored ? > i really this a ggi-support for this topic and need your opinions and > suggestions to set something up that take care of colorspaces != RGB. Yes. I have an application for that as well. Well, we have hardware devices that export those formats - TV-out cards. So we somehow have to cover them. And I'd really like to be able to run LibGGI apps on _anything_, so ... CU, ANdy -- = Andreas Beck | Email : <[EMAIL PROTECTED]> =
