Re: BGR->RGB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



> Hm, this isn't that bad. ;). You're just doing byte-by-byte. You could
> try grabbing 32-bit frames, so you can work with 32-bit variables
> (glib's guint32, you can use sys/types.h's __u32 too). If so, here's my
> try:
>
> static void
> bgr32_to_rgb32 (unsigned char *bgrSrc,
>                 unsigned char *rgbDest,
>                 unsigned int   size)
> {
>   while (size > 0) {
>     (guint32)(*bgrDest) = (((guint32)(*bgrSrc))&0xff000000)>>24 |
>                           (((guint32)(*bgrSrc))&0x00ff0000)>>8  |
>                           (((guint32)(*bgrSrc))&0x0000ff00)<<8  |
>                           (((guint32)(*bgrSrc))&0x000000ff)<<24;
>     size -=4; bgrSrc += 4; rgbDest += 4;
>   }
> }

[snip]

> This is (supposed to be) faster because you don't do (expensive)
> mathematical operations, but you simply do bit-operations (&, >>, << and
> |). Of course, assembler would make this faster too, but I'm not a
> genius there.

Well, that's impressive. :)

However, all I get is a black picture, no data. This way, it produces around
19fps (compared to my crappy 13fps), so it is a darn fast procedure.
Probably some of the hex values need tweaking in order to produce the actual
image, and not black. I'll have a look, but I have to say I am a bit lost...
I've never been good with bits...

Cagdas mantioned an analog way of seeing things, but I can't do that here
because it's a work machine, and I don't want to mess with it too much
(also, I have no idea how to do what he said) :)

Also, Billy mentioned XVideo, but this is faaaar too advanced for me. In my
app, I only get the swapped RGB buffer and place it in the drawing area
widget of a gtk+ window, nothing fancy with XVideo, framebuffers, etc. I
don't even understand that stuff...

Finally, if I don't do the swapping, Mark, I get constant 25fps, with
precision to the millisecond, so the system can cope with the throughput
quite well. True, uncompressed rgb24 image is around 1.3MB, but it works so
far. I'm hoping eventually to move to the 16bit colourdepth, which will
halve that image size.

In the end, this particular program is just a test thingy, but it shows the
way forward for the real app. And having such a fast conversion procedure,
such as Ronald's, is something spectacular. After all, this is its purpose,
to test things as I go along, so I can get the best for the real app.

/G





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux