On Mon, 30 Jun 2003, Ottavio Campana wrote: >I'm developing an application using v4l and I'm planing to use a g4 >system for running it. G4 should be big endian, while the amd based pc >I'm using to develop it should be little endian. (Interesting but useless notice: AFAIK, PPC can be run either in little or big endian mode. But unless you're making a new OS, it hardly matters). >How does it reflect on the program? I mean, should I swap RBG to GBR >while acquiring images from the grabber? Or does the drive on big endian The trend nowadays is that a V4L device grabbing with VIDEO_PALETTE_RGB24 or VIDEO_PALETTE_RGB32 has the blue byte first in memory, ie. BGR order, not matter whether little or big endian. However, since this isn't defined anywhere, some apps/drivers do it other way around, which is a pain even on standard PCs. You can expect the same on PPC: assume BGR order if it works. With other formats, (I believe), the byte order and image format is always same no matter which endian CPU. Or at least in YUV colorspace. V4L VIDEO_PALETTE_* are poorly defined, take a look at V4L2 documents. They describe much better image formats.
