Menu
▾
▴
libvisual-devel
|
From: salsaman <sal...@xs...> - 2004-09-16 10:14:05
|
Hi all, as you know I have been testing libvisual in LiVES, and it is reasonably fast. However, there might be a problem with some plugins, as I believe that they work in the RGB colourspace whilst LiVES works in BGR (default for GTK+ on x86). Fortunately for the plugins I've seen so far there is not a problem because the red/blue channels can be swapped without problem, so they can support both RGB and BGR. However, for some plugins, they might require a strict interpretation of red and blue. Would it be possible to mark such plugins with a flag somehow ? Regards, Salsaman. |
|
From: Burkhard P. <pl...@ip...> - 2004-09-16 14:11:42
|
> Fortunately for the plugins I've seen so far there is > not a problem because the red/blue channels can be swapped without > problem, so they can support both RGB and BGR. Maybe the plugins might still look "cool" when B and R are swapped, but the plugin authors won't like this. Adjusting the colors for a visualization can involve many hours of fine-tuning. There need to be a bullet-proof definition of RGB and BGR, so that all plugins are displayed with the right colors on all architectures. You should also take care, that there is no "standard" about RGB and BGR, especially for 15/16 bpp. The same format might be called differently in different software packages. Colorspace issues can become really complicated. I wrote a library (gavl), which handles all these. The main header is here: http://cvs.sourceforge.net/viewcvs.py/gmerlin/gavl/include/gavl/gavl.h?view=markup The libavcodec source (ffmpeg.org) also gives an idea how to handle pixel formats properly. -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
|
From: salsaman <sal...@xs...> - 2004-09-16 16:56:19
|
Burkhard Plaum wrote: >> Fortunately for the plugins I've seen so far there is not a problem >> because the red/blue channels can be swapped without problem, so they >> can support both RGB and BGR. > > > Maybe the plugins might still look "cool" when B and R are swapped, > but the plugin authors won't like this. > Adjusting the colors for a visualization can involve many hours > of fine-tuning. Well true, but in this case it could be marked somehow. > > > There need to be a bullet-proof definition of RGB and BGR, so that > all plugins are displayed with the right colors on all architectures. See below. > > You should also take care, that there is no "standard" about RGB and BGR, > especially for 15/16 bpp. The same format might be called differently > in different software packages. Sorry, I was talking about 24bit colours, so in this case the definition is obvious, blue pixel byte comes before green pixel byte which comes before red pixel byte. > > Colorspace issues can become really complicated. I wrote a library > (gavl), > which handles all these. The main header is here: > > http://cvs.sourceforge.net/viewcvs.py/gmerlin/gavl/include/gavl/gavl.h?view=markup > > > The libavcodec source (ffmpeg.org) also gives an idea how to handle > pixel formats properly. > Swapping the red and blue is not hard, it's just time consuming when it has to be done for each frame. I've not heard of gavl before, but it looks interesting. Do you have conversions for all those palettes ? I am looking for a high quality YUV420 <---> UYVY converter. Livido will also have palette conversions. Salsaman. |
|
From: Burkhard P. <pl...@ip...> - 2004-09-17 10:08:07
|
>> Maybe the plugins might still look "cool" when B and R are swapped, >> but the plugin authors won't like this. >> Adjusting the colors for a visualization can involve many hours >> of fine-tuning. > > Well true, but in this case it could be marked somehow. Not only in this case. The colors should always be right. If users want to play with swapping colors, it can be provided as an option. > Sorry, I was talking about 24bit colours, so in this case the definition > is obvious, blue pixel byte comes before green pixel byte which comes > before red pixel byte. And then it's bgr? > I've not heard of gavl before, but it looks interesting. Do you have > conversions for all those palettes ? All conversions are present in C, some also in mmx. > I am looking for a high quality > YUV420 <---> UYVY converter. What do you mean with high quality? With interpolating for chroma up/down sampling? The gavl yuv420 <-> uvuy converter is pretty srtaightforward. -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
|
From: salsaman <sal...@xs...> - 2004-09-17 10:30:00
|
Burkhard Plaum wrote: >>> Maybe the plugins might still look "cool" when B and R are swapped, >>> but the plugin authors won't like this. >>> Adjusting the colors for a visualization can involve many hours >>> of fine-tuning. >> >> >> Well true, but in this case it could be marked somehow. > > > Not only in this case. The colors should always be right. > If users want to play with swapping colors, it can be provided > as an option. Then I may have to swap the channels in LiVES. Unfortunately this will probably halve the frame rate for libvisual. But first a teest is needed. Can you or somebody provide a plugin which simply produces a blue image for output ? > >> Sorry, I was talking about 24bit colours, so in this case the definition >> is obvious, blue pixel byte comes before green pixel byte which comes >> before red pixel byte. > > And then it's bgr? In LiVES it is, at least on x86. > >> I've not heard of gavl before, but it looks interesting. Do you have >> conversions for all those palettes ? > > > All conversions are present in C, some also in mmx. MMX is no good for me, LiVES is cross platform. However, the livido writers might be interested, since liblivido will be platform specific. > >> I am looking for a high quality >> YUV420 <---> UYVY converter. > > > What do you mean with high quality? > With interpolating for chroma up/down sampling? Yes. I have horizontal subsampling for BGR->UYVY I need a vertical subsample for UYVY->YUV420. Oh well, I will ask Niels sometime. > > The gavl yuv420 <-> uvuy converter is pretty srtaightforward. > Unless you want vertical chroma sub/supersampling. Salsaman. |
|
From: Jeroen <dys...@xs...> - 2004-09-17 14:06:22
|
In message #5 on Fri, Sep 17, 2004 at 12:45:18PM +0100, salsaman mumbled: > MMX is no good for me, LiVES is cross platform. However, the livido > writers might be interested, since liblivido will be platform specific. MPlayer has MMX optimalisations yet i'm able to compile and run it on MIPS/IRIX. Because its excluded during compile time. MPlayer also has an option to chose optimalisations on the fly (CPU detection or something) but that slows it a bit down ofcourse. If Libvisual, Libivido, LiVES could use something similar (2 options) both cross-platform and x86-specific get the best out of it. Kind regards / met vriendelijke groet, Jeroen |
|
From: Burkhard P. <pl...@ip...> - 2004-09-17 14:30:09
|
> Then I may have to swap the channels in LiVES. Unfortunately this will > probably halve the frame rate for libvisual. I think libvisual should handle this. Many X11 installations also have 32 bit BGR XImages by default. This colorspace thing will show up everywhere. > MMX is no good for me, LiVES is cross platform. However, the livido > writers might be interested, since liblivido will be platform specific. gavl does runtime autodetection, and on non mmx platforms, it won't try to compile the mmx stuff at all. The accelleration modi can be selected using individual flags (like in libvisual) or with simple speed<->quality sliders. > Yes. I have horizontal subsampling for BGR->UYVY > > I need a vertical subsample for UYVY->YUV420. Oh well, I will ask Niels > sometime. In principle, gavl can also support (slow) high quality conversions. Up to now, I could not find any visible errors due to the lack of interpolating, so I didn't write them yet. -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
|
From: salsaman <sal...@xs...> - 2004-09-17 14:38:41
|
Burkhard Plaum wrote: > >> Then I may have to swap the channels in LiVES. Unfortunately this >> will probably halve the frame rate for libvisual. > > > I think libvisual should handle this. Many X11 installations also > have 32 bit BGR XImages by default. This colorspace thing will > show up everywhere. OK. I've tested GBR --> RGB conversion in LiVES, and it doesn't really slow things down too much. But still, for some hosts it might be nice to have the option to let libvisual handle the conversion as well. > >> MMX is no good for me, LiVES is cross platform. However, the livido >> writers might be interested, since liblivido will be platform specific. > > > gavl does runtime autodetection, and on non mmx platforms, it won't > try to > compile the mmx stuff at all. The accelleration modi can be selected > using individual flags (like in libvisual) or with > simple speed<->quality sliders. I've suggested to the other livido authors that we have a standard #define for processor type. This value could also be passed to libvisual via the wrapper (though obviously not at compile time). > >> Yes. I have horizontal subsampling for BGR->UYVY >> >> I need a vertical subsample for UYVY->YUV420. Oh well, I will ask >> Niels sometime. > > > In principle, gavl can also support (slow) high quality conversions. > Up to now, I could not find any visible errors due to the lack of > interpolating, so I didn't write them yet. > I found without the horizontal subsampling there was a visible "striping" on the screen, but then there were probably other sources of error at the time. Cheers, Salsaman/Gabriel. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X